- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
You must log in or register to comment.
The actual reason why let … in syntax tends to not use C-style “var type” 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.let a: &'static strRust 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.
deleted by creator
std::stringdoesn’t have a template type for the allocator. You are stuck using the verbosebasic_stringtype if you need a special allocator.But, of course, nobody sane would write that by hand every time. They would use a typedef, like how
std::stringis just a typedef forstd::basic_string<char, std::char_traits<char>, std::allocator<char>>. Regardless, the C++ standard library is insanely verbose when you start dropping down into template types and using features at an intermediate level. SFINAE in older versions of C++ was mindfuck on the best of days, for example.Don’t get me wrong, though. I’m not saying Rust is much better. Its saving grace is its type inference in
letexpressions. Without it, chaining functional operations on iterators would be an unfathomable hellscape ofCollect<Skip<Map<vec::Iter<Item = &'a str>>>>Yeah, I missed the custom allocator at first. I thought I deleted my comment fast enough, but I guess you were faster. :)
String a: new String()=?""most likely
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 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.
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?
The basic problem is that identifiers can be either types or variables, and without a keyword letting you know what kind of statement you’re dealing with, there’s no way of knowing without a complete identifier table. For example, what does this mean:
foo * bar;If foo is a type, that is a pointer declaration. But if it’s a variable, that’s a multiplication expression. Here’s another simple one:
foo(bar);Depending on how foo is defined, that could be a function call or a declaration of a variable bar of type foo, with some meaningless parentheses thrown in.
When you mix things together it gets even more crazy. Check this example from this article:
foo(*bar)();Is bar a pointer to a function returning foo, or is foo a function that takes a bar and returns a function pointer?
letandfnkeywords solve a lot of these ambiguity problems because they let the parser know what kind of statement it’s looking at, so it can know whether identifiers in certain positions refer to types or variables. That makes parsing easier to write and helps give nicer error messages.
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 aasyncas a new keyword in a minor version of a language and breaking a bunch of libraries.Python?
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.
C++ has
auto, which determines the type automatically.
python:
a: str = 1
That’s just a comment
And then assign an int to a string just to mess with the interpreter.
I wish the interpreter cared about assignment
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.
You’re encoding more information in the typescript one. You’re saying it’s a string that will get updated.
C# has const string a = “Hello, World”;
var in js is legacy, and default should be let, but changing that would break everything
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
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.
deleted by creator
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 aand type inference would do its thing. Which is much more ergonomic.Type inference is a pretty big thing in TypeScript as well though. In fact it’s probably the biggest thing about it, IMO.
let a = String::from(“Hello, world!”).into()I’ll see myself out.
I was thinking the same thing. who would write typescript if they could just do Rust?
I would because I know TypeScript and I don’t know Rust.
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
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.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.
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.
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”.
TIL Backronyms and cuil BASIC technicalities Much obliged all
Even older variants required both a let to declare the variable and a dim to set its size.
I remember a
REDIMcommand, but I really can’t remember what basic it’s from.The first programming language I used was Visual Basic (both VBA in Excel, and VB3 then VB6). I think it used redim to resize arrays.
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
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() {TIL PHP has statics.
Also, does PHP actually enforce the type declarations? I’d assume it would but knowing PHP…
It enforces scalar types (string, int, etc) at runtime if you enable strict mode. There’s also static analysis tools like PHPStan and Psalm that will flag issues at build time.
so, no. good catch OP!
JavaScript (Typescript for the type part) and python, the most popular scripting languages, use the same order as PHP.
It’s usually compiled languages that do the other one.
TypeScript doesn’t need the “function” keyword for a method in an object or on a class though.
const foo = { bar(): string { ... } }which I assume is doable because the syntax is unambiguous.
In PHP’s case, the method syntax should also be unambiguous.
Javascript gonna Javascript
JavaScript* 👍
First time i used let it was to inline variable declaration with assignment . Can’t remember the language.
