Made with KolourPaint and screenshots from Kate (with the GitHub theme).
You must log in or # to comment.
Good, now invent a keyword for variables you don’t want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.
Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.
I don’t understand how not using a keyword to define a function causes the meaning to change depending on imports. I’ve never run into an issue like that before. Can you give an example?
Some declarations terminate on the name, other declarations go one requiring more tokens. In C, the only thing that differentiates them is the type.
Parenthesis in particular are completely ambiguous. But asterisks and square brackets also create problems.
I have never heard of this problem for C. Can you elaborate or point to some articles?
In C#, you can use ‘var’ to have an impilict type variable.
String name = “”
var name = “”
So, a keyword
So I think it’s still probably unclear to people why “mix of keywords and identifiers” is bad: it means any new keyword could break backwards compatibility because someone could have already named a type the same thing as that new keyword.
This syntax puts type identifiers in the very prominent position of “generic fresh statement after semicolon or newline”
…though I’ve spent like 10 minutes thinking about this and now it’s again not making sense to me. Isn’t the very common plain “already_existing_variable = 5” also causing the same problem? We’d have to go back to cobol style “SET foo = 5” for everything to actually make it not an issue
Ah I was misunderstanding the problem. And learned something new about C#, seems in order to avoid breaking existing code they introduce “contextual keywords” var being added later, it is a contextual. You can create a class ‘var’ and the compiler will prefer it.
At least in C#, you can define variables with keyword names like this:
var @struct = “abc”
I think in Kotlin you can do the same, and even include spaces with backticks like val
abstract class= “abc”I’m not sure if other languages allow that, regardless it should be rarely used.
Swift also uses backticks and Rust has a dumb one in the form of
r. Still much better than introducing aasyncas a new keyword in a minor version of a language and breaking a bunch of libraries.Python?
any new keyword could break backwards compatibility
Wouldn’t that happen anyway with variable and function names? Any type other than primitive/built in ones are usually camel case so lower case keywords are more likely to clash with single word variable and function names, unless you restrict the cases of those too or allow keyword overriding or something.
Yeah, it’s in my edit I realized the same thing. I’m thinking it doesn’t actually really make sense and the real reason is more “the specific way C does it causes a lot of problems so we’re not poking syntax like that with a 10 foot pole” + “it makes writing the parser easier” + maybe a bit of “it makes grepping easier”
One thing that annoyed me about C# as a Java guy is that it really wants you to use camel case for function and property names, even private ones. I don’t like it specifically because it’s hard to differentiate between a function/property and a type.
But C# has quite a few keywords and seem to like adding them more than Java.
Maybe that’s their way of ensuring keywords don’t clash with stuff?
Good, now invent a keyword for variables you don’t want to declare the type.
auto. Also in D, you only needconstif you don’t want to specify a type for a constant, the compiler automatically inferres it to you.Function declarations can be easily decyphered from context, no problem.
Maybe that’s what the people developing spoken languages thought, while normalising conversations overdependent on context.
But hey, now we have another comedic tool in anime.
python:
a: str = 1
And then assign an int to a string just to mess with the interpreter.
only the linter gives a hoot - the interpreter will happily leave that footgun for later
deleted by creator
Dude, even just a “FY,I, you sure about this?” would be nice. I gladly embrace python’s by-all-means-shotgun-your-leg-off philosophy, but the noobs could use the help.
That’s just a comment
Looks like a snippet of C with two labels that will be referenced by a goto instruction. Very bad code tbh.
You’re encoding more information in the typescript one. You’re saying it’s a string that will get updated.
Yeah, it’s explicitly distinct from
const a: Stringwhich says it won’t change, andvar a: String, which means this is legacy code that needs fixing.If there’s only two options you only need one keyword
Ah, but this is JS, so there are three options! And they all function entirely differently. And your assumptions don’t apply, either. :D
You aren’t though. In most languages that use the latter declaration you would prefix the declaration with final or const or the like to specify it won’t be updated.
deleted by creator
Meanwhile if it’s rust it’s the opposite. (Variables that can change must specify that they are mutable)
Because sometimes that
letcan be replaced by other things likeconst. Which can be managed statically by the machine and not by my (imperfect) ability to know if it’s mutated or notI think you can do
const thing = ... as constto lock down the mutation?So is
letin some languages. In Rust, you have to constantly opt out from immutability withlet mut, which makes writing more procedural code feel like you’re fighting with the compiler, and otherwise I don’t really see the rationale behind full functional coding. I only had a bug caused only once by unwanted mutation, the hardest part fixing it was to learn the proper use of my debugger tool.
Ok but, in the second example you typically just put final or const in front of the type to denote immutability. I still don’t see the advantage to the first declaration.
oh for sure, but I think that’s the rarer case for language implementions. Having a consistent structure with alternative keywords in static positions is just easier to develop an AST for. Personally my favorite language doesn’t even allow for const values (except by convention) so it’s really just a matter of preference
Is it rarer? I think a lot of modern languages go for the first option but pretty much all C style languages use the latter. It’s probably a wash for which is more popular I’d think.
I’m talking about quantity not the popularity of a given language. There are certainly a number of popular languages that follow that convention
The actual reason why let … in syntax tends to not use C-style “type var” like syntax is because it’s derived from the syntax type theory uses, and type theorists know about parameterised types. Generics, in C++ parlance, excuse my Haskell:
let foo :: Map Int String = memptyWe have an empty map, and it maps integers to Strings. We call it foo. Compare:
Map Int String foo = memptyIf nothing else, that’s just awkward to read and while it may be grammatically unambiguous (a token is a name if it sits directly in front of
=) parser error messages are going to suck.Map<Int,String>is also awkward but alas that’s what we’re stuck with in Rust because they reasoned that it would be cruel to put folks coming from C++ on angle bracket withdrawal. Also Rust has ML ancestry don’t get me started on their type syntax.How do you do nested parameterized types without it becoming ambiguous though? That’s IMO the biggest advantage of the bracket syntax. For example:
Map<Tuple<Int, Int, Int> Int>Map (Int, Int) Int. Kind of a bad example because tuples have special-case infix syntax, the general case would beMap Int (Either Int Bool). Follows the same exact syntax as function application just that types (by enforced convention) start upper case. Modulo technical wibbles to ensure that type inference is possible you can consider type constructors to be functions from types to types.…function application syntax is a story in itself in Haskell because
foo a b cgets desugared to(((foo a) b) c): There’s only one-argument functions. If you want to have more arguments, accept an argument and return a function that accepts yet another argument. Then hide all that under syntactic sugar so that it looks innocent. And, of course, optimise it away when compiling. Thus you can write stuff likemap (+5) xsin Haskell while other languages need the equivalent ofmap (\x -> x + 5) xs(imagine the\is a lambda symbol).Interesting. Thanks!
Until now, I looked at
letand thought, “maybe they just felt like doing it that way”.
Makes a lot more sense now.
IT'S SHOWTIME I NEED YOUR CLOTHES YOUR BOOTS AND YOUR MOTORCYCLE a GET TO THE CHOPPER a HERE IS MY INVITATION "ArnoldC is the best." ENOUGH TALK TALK TO THE HAND a YOU HAVE BEEN TERMINATEDNot to short-circuit the joke, but in this case, it’s because the valid JavaScript version is…
let a…and one of TypeScript’s main design goals is to be a superset of JavaScript, that only adds syntax, and doesn’t re-write it.
Beyond that, it’s probably a case of some new language just using what the designer is familiar with.
TypeScript […] only adds syntax, and doesn’t re-write it.
I believe
enum,const enum, and decorators would like to have a word with you.Who says this is JS? Might be Rust.
Then the second part of my statement applies.
In the case of Rust, you can also omit the type annotation in the vast majority of cases and the compiler will infer it.
STRING A WHAT, MOTHERFUCKER
Javascript gonna Javascript
JavaScript* 👍
Blame my phone’s autocorrect
Weird, my phone gave me the correct capitalization when I just used the swipe typing.
