DEV Community

Discussion on: The TypeScript Experience

Collapse
peerreynders profile image
peerreynders

The comparison with C# comes up because

  • Anders Hejlsberg is the lead architect of C# and TypeScript
  • by implication:

"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.

const RNA_COMPLEMENT = {
  G: 'C',
  C: 'G',
  T: 'A',
  A: 'U',
} as const;

type DnaNucleotide = keyof typeof RNA_COMPLEMENT;
Enter fullscreen mode Exit fullscreen mode

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:

Thread Thread
lucamug profile image
lucamug Author

The "Ideology" video linked is very nice.

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)
Thread Thread
peerreynders profile image
peerreynders

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

/** @type {(string, boolean) => number} */
function sbn(s, b) {
  /* ... implementation details ... */
}
Enter fullscreen mode Exit fullscreen mode

seems perfectly reasonable - though familiarity with the mainstream, conflated syntax

function sbn(s: string, b: boolean): number {
  /* ... implementation details ... */
}
Enter fullscreen mode Exit fullscreen mode

creates a bias towards s: string "belonging together" even though they are just distinct aspects of the same positional argument:

  • s is the name the value of the positional argument is bound to
  • string is the type the positional argument is expected to be
Thread Thread
lucamug profile image
lucamug Author

"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.