Why make it complicated?
-
I don't know typescript. But if that's the case, this meme doesn't make much sense.
Who writes the types of variables in a language with type inference unless forced by the compiler?
Maybe it's a language without type interference?
Either way, it sometimes makes sense in TypeScript to help the type system out a little bit.
let array: string[] = [];In this situation, the type system can't infer that the empty array should be a
stringarray, because there are no items to go by. -
Not when taken to such an extreme so as to obfuscate the meaning and behavior of code, and make it difficult to understand how you would arrive at that code.
Sane defaults serve to reduce verbosity without obfuscating meaning, simpler syntax with different ordering and fewer tokens reduce verbosity to make the code easier to read by reducing the amount of text you have to pay attention to to understand what the result is.
I imagine there's also a distinction to be made between verbosity and redundancy - sometimes extra text might fail to carry information, or carry information that's already carried elsewhere. I'm not sure where the line should be drawn, because sometimes duplicate information can be helpful, and spacing out information with technically meaningless text has value for readability, but I feel like it's there.
wrote on last edited by [email protected]Frankly, I have way more often ended up scratching my head for some cryptic piece of syntax than the opposite. Sure I could sit down and spend the rest of my life learning each language designer's favourite syntax optimisations, but I kinda don't want to. I'm a human, not a parser.
And frankly, a good IDE editor should be able to fold/unfold verbose syntax. Better for it then to be there and folded, than for it to not be there and for someone to have to work backwards the intendrd meaning of every single line of code.
-
let a = String::from(“Hello, world!”).into()I’ll see myself out.
At least be fair and cut out the
.into() -
At least be fair and cut out the
.into()And bow to the compiler’s whims? I think not!
This shouldn’t compile, because .into needs the type from the left side and let needs the type from the right side.
-
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.Until now, I looked at
letand thought, "maybe they just felt like doing it that way".
Makes a lot more sense now. -
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.
-
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.wrote on last edited by [email protected]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> -
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
wrote on last edited by [email protected]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.
-
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). -
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).wrote on last edited by [email protected]Interesting. Thanks!
-
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.
wrote on last edited by [email protected]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"
-
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.
wrote on last edited by [email protected]Yeah, I mean Rust is only verbose if you want it to be.
let foo = "bar";is valid rust too, no need to declare the type and definitely no need to declare the lifetime.For that matter, if you ever declare something as explicitly
'staticin code that isn't embedded or super optimized, you're probably doing it wrong. -
I would because I know TypeScript and I don't know Rust.
ok but then you can't do Rust, so this does not apply.
but if you did.. !
-
ok but then you can't do Rust, so this does not apply.
but if you did.. !
Probably would still use TypeScript, because I use that for work.
️ Rust just seems like... a lot. Regarding Rust, I've seen a lot of praises and a not so insignificant amount of complaints that make me very hesitant to take the plunge. Can't remember off the top of my head what it was, specifically, but it was enough for me to write it off, that much I remember. -
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
STRING A WHAT, MOTHERFUCKER
-
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.
-
Probably would still use TypeScript, because I use that for work.
️ Rust just seems like... a lot. Regarding Rust, I've seen a lot of praises and a not so insignificant amount of complaints that make me very hesitant to take the plunge. Can't remember off the top of my head what it was, specifically, but it was enough for me to write it off, that much I remember.People really overstate it, it's not that hard. It has a reputation of being difficult because people use it for difficult, low-level tasks, OS stuff, parsers, cryptography, highly optimised serialisation, but those things would be hard in any language. For a newcomer it's, IMO, way easier than say C++, because it doesn't have a mindbogglingly huge std lib with decades of changing best practices to try to figure out. To do simpler things in it is really pretty straightforward, especially if you're already comfortable with a robust type system.
-
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.
the problem is that the language doesn't and can't support one single way to use type annotations without changing fundamental functionality. you can absolutely hook up mypy to your editor for newbies, but once you get on the intermediate level, fighting with mypy takes more code than actually solving the problem.
also there was that proposed update to mypy that was put on held when it turned out that the maintainers didn't know how annotations are used in the wild.
-
the problem is that the language doesn't and can't support one single way to use type annotations without changing fundamental functionality. you can absolutely hook up mypy to your editor for newbies, but once you get on the intermediate level, fighting with mypy takes more code than actually solving the problem.
also there was that proposed update to mypy that was put on held when it turned out that the maintainers didn't know how annotations are used in the wild.
Oh I'm well aware. Took me a solid year to appreciate type annotations for what they are and yeah I'm happy using what we have in stdlib now and not messing with mypy tyvm. The problem is that history is lost to newcomers who have very different expectations. Modern IDE's mostly solve it though, so for all my Java peeps dipping their toes into the snake waters, listen to your ide
-
Oh I'm well aware. Took me a solid year to appreciate type annotations for what they are and yeah I'm happy using what we have in stdlib now and not messing with mypy tyvm. The problem is that history is lost to newcomers who have very different expectations. Modern IDE's mostly solve it though, so for all my Java peeps dipping their toes into the snake waters, listen to your ide
i mean, i'm all for rejiggering the internals. i've personally written at least two libraries that uses type annotations in reverse to force arguments into the correct type, and i feel like that should probably be a separate mechanism to "just call the annotation"
