"TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web."
That evokes the whole 2012 "ASP.NET with C#" theme. But at the very least it does imply that TypeScript was designed to feel familiar to established C# developers.
But then "TypeScript’s type system has evolved to model code written by native JavaScripters. The resulting system is powerful, interesting and messy."
Some of the tension comes from the fact that TypeScript offers more value (as in gets less in the way) as a JavaScript type linter than as a programming language.
Rich Harris
@rich_harris
Moved some of my smaller libs to JSDoc TS; thoroughly recommend it. Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code twitter.com/swyx/status/13…
Interesting counter-trend - maintainers of large open source projects like @Sveltejs and @Deno_land are moving *AWAY* from writing their internals in TypeScript
Just at the same time when the wider dev world is falling in love with TS.
Reasons: build times and code complexity. https://t.co/a74GAoYhwp
@Rich_Harris We've been doing this with strict type checking in Preact codebases for the past year and it's been really nice.
20:03 PM - 16 Jan 2021
Being able to "Just use JavaScript" (rather than having to compile it), while being able annotate types succinctly for occasional type linting should silence most criticisms. At this point JSDoc TS is seen as verbose (though @type gets close) and not all of TypeScript's features are necessarily easy to access from JSDoc/JavaScript (though that hasn't stopped projects from adopting it (most notably Preact for performance reasons)).
FYI: Deno 2.0 will skip type checking by default to improve start up performance.
I don't believe that TypeScript would have gotten as much traction as a pure type linting tool—as a programming language it brought a sense of familiarity to those with a background in statically typed languages and who were sceptical about trusting dynamically typed code.
Related to it, it would be interesting to roughly categorize people that answered the Twitter thread in
People that only experienced JS
People that experienced JS and TS
People that experienced JS, TS, and a statically typed language like Java, not based on the Hindley–Milner type system
People that experienced JS, TS, and a sound static language like Haskell, OCaml, Elm, or F# based on the Hindley–Milner type system (where type annotations are mostly optional)
"It's usually helpful to write down the type of new functions first;"
I always thought that it is useful to actually separate the type from the implementation - as opposed to the C-style conflation of both. So something like
"It's usually helpful to write down the type of new functions first;"
Yes, it is interesting to note that devs that use languages where type annotations are optional end up with a mindset of writing type annotation first and the implementation after.
Programming languages influence the way we find solutions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The comparison with C# comes up because
"TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web."
That evokes the whole 2012 "ASP.NET with C#" theme. But at the very least it does imply that TypeScript was designed to feel familiar to established C# developers.
But then "TypeScript’s type system has evolved to model code written by native JavaScripters. The resulting system is powerful, interesting and messy."
… which lead to the value space (variable declaration space) and type space (type declaration space) divide - and lots of syntax to extract information from value space into type space.
Some of the tension comes from the fact that TypeScript offers more value (as in gets less in the way) as a JavaScript type linter than as a programming language.
Being able to "Just use JavaScript" (rather than having to compile it), while being able annotate types succinctly for occasional type linting should silence most criticisms. At this point JSDoc TS is seen as verbose (though @type gets close) and not all of TypeScript's features are necessarily easy to access from JSDoc/JavaScript (though that hasn't stopped projects from adopting it (most notably Preact for performance reasons)).
FYI: Deno 2.0 will skip type checking by default to improve start up performance.
I don't believe that TypeScript would have gotten as much traction as a pure type linting tool—as a programming language it brought a sense of familiarity to those with a background in statically typed languages and who were sceptical about trusting dynamically typed code.
Ideology 3:11
Type branding is sometimes used to approximate nominal typing:
The "Ideology" video linked is very nice.
Related to it, it would be interesting to roughly categorize people that answered the Twitter thread in
On a side note:
A Gentle Introduction to Haskell, Version 98
"It's usually helpful to write down the type of new functions first;"
I always thought that it is useful to actually separate the type from the implementation - as opposed to the C-style conflation of both. So something like
seems perfectly reasonable - though familiarity with the mainstream, conflated syntax
creates a bias towards
s: string"belonging together" even though they are just distinct aspects of the same positional argument:sis the name the value of the positional argument is bound tostringis the type the positional argument is expected to beYes, it is interesting to note that devs that use languages where type annotations are optional end up with a mindset of writing type annotation first and the implementation after.
Programming languages influence the way we find solutions.