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.
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
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.
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
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.
If there's only two options you only need one keyword
True, but var and let are not same in js, so there is three.
if(true) {
var a = "dumdum"
}
console.log(a)
Is valid and functioning javascript. With let it is not.
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.
That looks like rust ngl
It's also valid rust syntax.
But if it were rust, this meme would not make sense, since you would just type let a and type inference would do its thing. Which is much more ergonomic.
I was thinking the same thing. who would write typescript if they could just do Rust?
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
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 = 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();
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
I think you can do const thing = ... as constto lock down the mutation?
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 TERMINATEDlet 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.
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.
BASIC uses (used?) it to declare variables. (I don't know if earlier languages did.)
Not that that's a reason for other languages to copy it.
Doesn't Basic use Dim a As String?
Older variants used DIM for arrays and LET for other variables. DIM was originally called that because it was setting the dimensions of the array.
In modern BASIC variants, DIM has become a backronym: "declare in memory".
In modern BASIC variants, DIM has become a backronym: “declare in memory”.
TIL. I always thought it was a backronym for declare in (yo) momma.
More than you'd ever want to know: https://en.m.wikipedia.org/wiki/Let_expression
I doubted you until I got about halfway through this whole page. I concede tho--you are most correct lol Still a decent read and for that I thank you
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.
Can we talk about PHP functions with typehints too?
public static function foo(): string {
Practically every other language with similar syntax does this instead:
public static string foo() {
Rust and TypeScript use the return-type-at-the-end convention as well.
TIL PHP has statics.
Also, does PHP actually enforce the type declarations? I'd assume it would but knowing PHP...
STRING A WHAT, MOTHERFUCKER