Made with KolourPaint and screenshots from Kate (with the GitHub theme).
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 TERMINATEDThe 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 = mempty
We have an empty map, and it maps integers to Strings. We call it foo. Compare:
Map Int String foo = mempty
If 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.
There is also the thing where the compiler might mistake your c++ style variable declaration for a function, e.g.
String myfunction():
String myvariable();
let a: &'static str
Rust is verbose, but C++ might still take the cake with its standard library templates. Especially when using fully-qualified type names...
auto a = ::std::make_shared<::std::basic_string<char, ::std::char_traits<char>, MyAllocator<char>>>();
A reference-counted shared pointer to a string of unspecified character encoding and using a non-default memory allocator.
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.
Good, now invent a keyword for variables you don't want to declare the type.
auto. Also in D, you only need const if 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.
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.
C++ has auto, which determines the type automatically.
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
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#thekeyword. Still much better than introducing a async as a new keyword in a minor version of a language and breaking a bunch of libraries.
Python?
String a: new String()
=?
"" most likely
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
That's just a comment
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: String which says it won't change, and var a: String, which means this is legacy code that needs fixing.
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.
C# has const string a = "Hello, World";
var in js is legacy, and default should be let, but changing that would break everything
Because sometimes that let can be replaced by other things like const. Which can be managed statically by the machine and not by my (imperfect) ability to know if it's mutated or not
Not 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.
I've always wondered where all this 'let' business started
It's commonly used in math to declare variables so I assume programming languages borrowed it from there.
More specifically, they're borrowing the more mathematical meaning of variables, where if you say x equals 5, you can't later say x is 6, and where a statement like "x = x + 1" is nonsense. Using "let" means you're setting the value once and that's what it's going to remain as long as it exists, while "var" variables can be changed later. Functional languages, which are usually made by very math-y people, will often protest the way programmers use operators by saying that = is strictly for equality and variable assignment is := instead of == and = in most C-style languages.
Unless you’re in JS.
More than you'd ever want to know: https://en.m.wikipedia.org/wiki/Let_expression
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.