Re:First look: adding type annotations to JavaScript
by S1ngleM4lt on Thursday March 10, 2022 @11:47AM
(#30629005)
That seems to be mostly just a matter of taste, but is definitely off putting when coming from other languages. Interestingly other recent languages like rust, zig, and go follow a similar convention to type script. Go has a brief explanation of why they went with this approach [0] so I’d be curious if other langs have documented their decisions.
Re:First look: adding type annotations to JavaScript
by Etheryte on Thursday March 10, 2022 @11:45AM
(#30628969)
My completely subjective guess is that it might be to avoid ambiguity around reserved keywords. For example, the `void` keyword [0]:
void function () { return 42; }(); // returns undefined
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re:First look: adding type annotations to JavaScript
by seniorsassycat on Thursday March 10, 2022 @11:34AM
(#30628821)
: type syntax will be more familiar to rust, kotlin, and typescript devs. Why is c relevant?
The name is usually more important than the type so I like that typescript puts it first.
Re:First look: adding type annotations to JavaScript
by jestar_jokin on Friday March 11, 2022 @01:40AM
(#30637022)
As you say, it's just a matter of familiarity. Sounds like you just need exposure to more programming languages/paradigms, as it's a pretty common convention. I believe it comes from the ML family. OCaml[0] springs to mind. As others have mentioned, Rust[1], Kotlin[2], Haxe[3], Nim[4], Swift[5], Elm[6], Dhall[7], and Scala[8] all use this convention.
The current syntax seems better for type inference and gradual typing.
[0] https://learnxinyminutes.com/docs/ocaml/
[1] https://learnxinyminutes.com/docs/rust/
[2] https://learnxinyminutes.com/docs/kotlin/
[3] https://learnxinyminutes.com/docs/haxe/
[4] https://learnxinyminutes.com/docs/nim/
[5] https://learnxinyminutes.com/docs/swift/
[6] https://learnxinyminutes.com/docs/elm/
Re:First look: adding type annotations to JavaScript
by orif on Thursday March 10, 2022 @01:53PM
(#30630850)
Actually, I would prefer a C/C++ dialect in TypeScript’s type notation. Parsing time/complexity would reduce drastically, and would allow type inference.
Re:First look: adding type annotations to JavaScript
by danielvaughn on Thursday March 10, 2022 @11:20AM
(#30628635)
Yes exactly. There must be some good reason why TS chose the syntax they did, because a lot of it feels very old-school-java.
Re:First look: adding type annotations to JavaScript
by stasm on Thursday March 10, 2022 @12:11PM
(#30629368)
Type inference is one good reason. Similar syntax exists in a few modern languages, too: e.g. Rust and Swift. In languages with type inference it can be convenient that type annotations are in the postfix position relative to variable names:
let user = new User();
let user: User = new User();
Re:First look: adding type annotations to JavaScript
by kderbyma on Thursday March 10, 2022 @11:16AM
(#30628587)
then we would have another type system....no just stick with typescript or none at all...
Re:First look: adding type annotations to JavaScript
by ravenstine on Thursday March 10, 2022 @11:30AM
(#30628766)
Well... yeah, I don't actually advocate for another type system, but more that if we have any type system at all for JavaScript then asking why we're going with one that overloads the colon token when it's already been sufficiently overloaded in the first place. Typescript already is what it is, and I think we should just stick with it, but if we are going to get yet another type annotation system then perhaps it might as well not be as novel as Typescript if there's a benefit.
---
const user: User = {
};---
Why couldn't this be more like C rather than this weird conflation with the existing colon token?
---
const User user = {
};---
That might seem not as pleasing to those familiar with Typescript, but it's much closer to other existing syntaxes (meaning less of a learning curve coming from Java or C).
Same with function definitions:
---
function foo (bar: string, baz: boolean): Qux {
}---
Versus:
---
Qux function foo (string bar, bool baz) {
}---
I find the latter much more familiar than Typescript and less confusing. It's also slightly less verbose.