5 ms·

>> ... programming in TypeScript every day. That explains why OP got depressed, considered quitting the industry and then switched to F#. If I keep using TypeS

>> ... programming in TypeScript every day. That explains why OP got depressed, considered quitting the industry and then switched to F#. If I keep using TypeScript, I might just snap and switch to COBOL.

lucasmullens 8y ago
Why the hatred of TypeScript? The vast majority of TypeScript devs tend to love the language in my experience
- isoskeles 8y ago
  Every single person I've met who "hates" typescript really "likes" javascript and was one day forced to start working on switching over to static typing. Maybe not this person's case, I wouldn't be too surprised if someone has another reason, but I seriously haven't heard anyone else with a strong opinion against typescript founded upon any other context. I could probably google around for other reasons.
  - agumonkey 8y ago
    I can totally see someone used to soft mutable js objects going insane in ml land.
- whatshisface 8y ago
  >The vast majority of TypeScript devs tend to love the language That sounds kind of like saying, "the vast majority of people with cilantro in their burritos like cilantro."
  - Insanity 8y ago
    it does, kind of, because sometimes you need to fit yourself to the project / company that already had some codebase before you. So I sometimes interact with languages that I like a bit less whilst working. But in general, yeah, it's kind of like that saying :)
  - akiselev 8y ago
    Due to Javascript Stockholm Syndrome it's more like "the vast majority of people forced to eat burritos at their day job like cilantro on their burritos."
- int_19h 8y ago
  I suspect it was more a hatred of the web stack in general.
- fouc 8y ago
  I suspect that developers tend to fall into roughly two kinds of backgrounds. That is static/compiled (c/java/etc) languages vs dynamic/interpreted (ruby/python/js/etc) languages. Perhaps this leads to a different coding styles & expectations. The former end up with a preference for strong typing. Perhaps their coding style also depends on that. The latter don't seem to find types to be a source of bugs.
  - akiselev 8y ago
    To me it seems more like two wildly different forms of PTSD. For the former group (those who prefer static typing), unmaintainable and poorly documented spaghetti code has been the most identifiable source of pain in their career while for the latter, it has been long iteration times due to bureaucratic nightmares caused by compiler and management. Like early childhood experiences, each programmer I've discussed the subject with seems to have their own unique professional experience that has molded their opinions. It's less a religion and more a coping mechanism for bad experiences.
    - jondubois 8y ago
      For me, bureaucracy and TypeScript go hand in hand. There are benefits to using TypeScript, but they're not worth the problems. TypeScript gives an illusion of added productivity and safety but when you actually look at results, bug density is exactly the same as JavaScript. As a TS developer, most of your time is spent on catering to the compiler's complaints, but doing so doesn't actually yield any benefits in terms of producing high quality software. TS and TSLint are bandaid solutions which don't address the root problems behind what makes code bad (which 99% of the time comes down to bad design/architecture). TS simply cannot prevent bad design/architecture - It can only formalize it. It's nice to have linted code with everything typed and statically locked into place but that means very little in terms of actual code quality.
      - akiselev 8y ago
        The reason Typescript has been so successful is that many of us don't have a choice in whether the beauracracy exists or not and have to pick up the pieces. Typescript is, by definition, a bandaid. That's what it was designed for.
skrebbel 8y ago
Hah! This fits with the point of the article I guess. I mean, I started with Pascal, then C and C++, then PHP, then Ruby then C# and some Java, then Scala, then JavaScript, and now Elixir and TypeScript. Of all those, I like TypeScript the best (barring the NPM / deployment / transpilation / packaging mess, that is). I mean, I like it the best by far. It combines functional with OO much like Scala set out to do, but in a much simpler and more accessible way. I really love it, I think in its structures. All JS I write feels like TypeScript. Even a lot of the Elixir I write (for better or worse) feels like TypeScript with a funny syntax. I now feel like structural typing is the big missed opportunity of most statically typed languages. The fact that I can define a type simply by writing, say, an object literal, continues to make my day. let a = { name: "Pete", age: 6 }; a.nmae = 7; // type error! a = { nmae: "Mike", age: 7 }; // type error! or even function moo() { return { name: "Pete", age: 6 }; } const a = moo(); a.+---------------------+ |name string | |age number | +---------------------+ Stuff like this feels so normal so quickly that I feel like I'm using yesterday's tools whenever I either don't get the autocomplete/type error (hi Elixir, Ruby, Python, PHP), or I have to manually add a `type Moo = yada yada` declaration above my function (hi Haskell, Scala, C#, F#, Java, srsly all of them). I'm not claiming any of this is new. I mean truth is I haven't seen any Haskell or F# or Scala code that does this, but I bet that's just my limited exposure to functional languages. I've heard these languages are pretty powerful, so sorry if I insulted your cult there :-) Still, I've used no other language that enables this ability to write code the way one would write dynamically typed code - head-first, straight down into the operational stuff, and finetune the data structures as we go along - while still getting type checking and all the confidence and tool support that comes with it for free. I agree with the OP. TypeScript is my cult. <3
- insulanian 8y ago
  Next version of F# is bringing anonymous records, which can give similar experience to your structural typing examples.
jasonhansel 8y ago
In a way, I think the problem is that TypeScript doesn't go far enough: it adds static typing, but has to awkwardly attach those types to APIs intended for a weakly-typed language.
- jondubois 8y ago
  Yes, JSON is by far the most popular data interchange format ever invented. This is for a good reason; it's the most compatible format possible; it works with any language and any system regardless of what kind of typing is used. As compatible as it is, there is definitely a lot of friction/awkwardness around type-casting JSON objects to typed objects within a statically typed programming language; there is an impedance mismatch. It's not as awkward as trying to type cast objects designed under one type system to a different type system (e.g. SOAP APIs) but it's still really awkward. The impedance mismatch goes away completely if you use a dynamically typed language like JavaScript. For example, JSON produced by a python program can be parsed by a JavaScript/Node.js program without any issues. The root reason why types are bad is because they're opinionated. There is no absolute right way to type something; and because of this, it's not correct to force other projects which interface with your project to adhere to your type definitions.

lucasmullens 8y ago

Why the hatred of TypeScript? The vast majority of TypeScript devs tend to love the language in my experience

isoskeles 8y ago
Every single person I've met who "hates" typescript really "likes" javascript and was one day forced to start working on switching over to static typing. Maybe not this person's case, I wouldn't be too surprised if someone has another reason, but I seriously haven't heard anyone else with a strong opinion against typescript founded upon any other context. I could probably google around for other reasons.
- agumonkey 8y ago
  I can totally see someone used to soft mutable js objects going insane in ml land.
whatshisface 8y ago
>The vast majority of TypeScript devs tend to love the language That sounds kind of like saying, "the vast majority of people with cilantro in their burritos like cilantro."
- Insanity 8y ago
  it does, kind of, because sometimes you need to fit yourself to the project / company that already had some codebase before you. So I sometimes interact with languages that I like a bit less whilst working. But in general, yeah, it's kind of like that saying :)
- akiselev 8y ago
  Due to Javascript Stockholm Syndrome it's more like "the vast majority of people forced to eat burritos at their day job like cilantro on their burritos."
int_19h 8y ago
I suspect it was more a hatred of the web stack in general.
fouc 8y ago
I suspect that developers tend to fall into roughly two kinds of backgrounds. That is static/compiled (c/java/etc) languages vs dynamic/interpreted (ruby/python/js/etc) languages. Perhaps this leads to a different coding styles & expectations. The former end up with a preference for strong typing. Perhaps their coding style also depends on that. The latter don't seem to find types to be a source of bugs.
- akiselev 8y ago
  To me it seems more like two wildly different forms of PTSD. For the former group (those who prefer static typing), unmaintainable and poorly documented spaghetti code has been the most identifiable source of pain in their career while for the latter, it has been long iteration times due to bureaucratic nightmares caused by compiler and management. Like early childhood experiences, each programmer I've discussed the subject with seems to have their own unique professional experience that has molded their opinions. It's less a religion and more a coping mechanism for bad experiences.
  - jondubois 8y ago
    For me, bureaucracy and TypeScript go hand in hand. There are benefits to using TypeScript, but they're not worth the problems. TypeScript gives an illusion of added productivity and safety but when you actually look at results, bug density is exactly the same as JavaScript. As a TS developer, most of your time is spent on catering to the compiler's complaints, but doing so doesn't actually yield any benefits in terms of producing high quality software. TS and TSLint are bandaid solutions which don't address the root problems behind what makes code bad (which 99% of the time comes down to bad design/architecture). TS simply cannot prevent bad design/architecture - It can only formalize it. It's nice to have linted code with everything typed and statically locked into place but that means very little in terms of actual code quality.
    - akiselev 8y ago
      The reason Typescript has been so successful is that many of us don't have a choice in whether the beauracracy exists or not and have to pick up the pieces. Typescript is, by definition, a bandaid. That's what it was designed for.

skrebbel 8y ago

Hah! This fits with the point of the article I guess. I mean, I started with Pascal, then C and C++, then PHP, then Ruby then C# and some Java, then Scala, then JavaScript, and now Elixir and TypeScript. Of all those, I like TypeScript the best (barring the NPM / deployment / transpilation / packaging mess, that is). I mean, I like it the best by far. It combines functional with OO much like Scala set out to do, but in a much simpler and more accessible way. I really love it, I think in its structures. All JS I write feels like TypeScript. Even a lot of the Elixir I write (for better or worse) feels like TypeScript with a funny syntax. I now feel like structural typing is the big missed opportunity of most statically typed languages. The fact that I can define a type simply by writing, say, an object literal, continues to make my day. let a = { name: "Pete", age: 6 }; a.nmae = 7; // type error! a = { nmae: "Mike", age: 7 }; // type error! or even function moo() { return { name: "Pete", age: 6 }; } const a = moo(); a.+---------------------+ |name string | |age number | +---------------------+ Stuff like this feels so normal so quickly that I feel like I'm using yesterday's tools whenever I either don't get the autocomplete/type error (hi Elixir, Ruby, Python, PHP), or I have to manually add a `type Moo = yada yada` declaration above my function (hi Haskell, Scala, C#, F#, Java, srsly all of them). I'm not claiming any of this is new. I mean truth is I haven't seen any Haskell or F# or Scala code that does this, but I bet that's just my limited exposure to functional languages. I've heard these languages are pretty powerful, so sorry if I insulted your cult there :-) Still, I've used no other language that enables this ability to write code the way one would write dynamically typed code - head-first, straight down into the operational stuff, and finetune the data structures as we go along - while still getting type checking and all the confidence and tool support that comes with it for free. I agree with the OP. TypeScript is my cult. <3

insulanian 8y ago
Next version of F# is bringing anonymous records, which can give similar experience to your structural typing examples.

jasonhansel 8y ago

In a way, I think the problem is that TypeScript doesn't go far enough: it adds static typing, but has to awkwardly attach those types to APIs intended for a weakly-typed language.

jondubois 8y ago
Yes, JSON is by far the most popular data interchange format ever invented. This is for a good reason; it's the most compatible format possible; it works with any language and any system regardless of what kind of typing is used. As compatible as it is, there is definitely a lot of friction/awkwardness around type-casting JSON objects to typed objects within a statically typed programming language; there is an impedance mismatch. It's not as awkward as trying to type cast objects designed under one type system to a different type system (e.g. SOAP APIs) but it's still really awkward. The impedance mismatch goes away completely if you use a dynamically typed language like JavaScript. For example, JSON produced by a python program can be parsed by a JavaScript/Node.js program without any issues. The root reason why types are bad is because they're opinionated. There is no absolute right way to type something; and because of this, it's not correct to force other projects which interface with your project to adhere to your type definitions.