5 ms·

I think the skepticism of new shiny things is healthy. Of the set of things that exist, most things are worse than the things one already uses/prefers. Most new

I think the skepticism of new shiny things is healthy. Of the set of things that exist, most things are worse than the things one already uses/prefers. Most new things solve a specific problem that may not overlap with the problems one is trying to solve. With software development, a huge part of the puzzle is tooling (as the article points out), so even if typescript is obviously superior as a language, the tooling needs to catch up before it's a reasonable/useful alternative. In this case, the tooling quality, enabled by the static typing, shot typescript way past the thing it was replacing.

nickysielicki 6y ago
Strong typing is not shiny or new and, even if you're a javascript guy, not being remotely familiar with any strongly-typed language (or generics?!) is a red flag. (edit: red flag is a bad description, because he ended up being self-reflective and looking deeper, which is just about the furthest thing from a red flag.)
- mywittyname 6y ago
  Agreed. But some people have an attitude of Strongly Typed == Needlessly Verbose. Probably because most developers have only experienced Strong Typing via Java.
  - capableweb 6y ago
    I'm in neither camps (I don't have anything against types in places but I also don't try to put them everywhere). Could you explain how TypeScripts types would be more/less verbose than the types from Java? At a glance, TypeScript looks a bit more flexible, but mostly the same. Then Java is a verbose language in general (forced directory structure, one-class-per-file and yadda yadda) but that's besides the point as you're pointing to TypeScripts types being less verbose than Javas.
    - lalaithion 6y ago
      1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated<Generic<Type>> x = returnsComplicatedThing();`. (At least up until the last few years) 2) TypeScript has type aliases, meaning you can write `type MyTable = List<Map<string, number | string | Foo>>` and not have to repeat yourself everywhere. 3) TypeScript has anonymous unions and tuples, so instead of writing `Triple<Integer, String, Foo>` you can just write `[number, string, Foo]`, and likewise instead of `OneOf<Integer, String, Foo>` you can write `number | string | Foo`. These are also built in and very ergonomic, so you don't have to write a OneOf4 class whenever you want to have one of 4 things, and you don't have to write helper methods to convert between different sized OneOfs.
      - crocarneiro 6y ago
        Don't know about the other two, but the first one is available in java 10 and later.
        mgkimsal 6y ago
        Worked on a project with an old (12+ years?) - but still being developed/used - Java system. Just last year a move was made up to Java 11 (from 8). Decent test coverage, but moving multiple systems is still a big task, but... they did it. Java 11. Yay. But... teammates were running in to issues with 'new' stuff - like, using 'var'. There were others, but this was sort of the archetypal argument. "Well, it doesn't match the rest of the style of the file/app - it'll make it hard to read". Well... hrm... any new feature literally doesn't match the style of what came before it, because you have new keywords/features/syntax to handle processes a new way. It's definitional. But just because there's a new feature doesn't mean it'll be adopted (for better or worse, I supposed, depending on your stance).
        Quekid5 6y ago
        Java-the-language/JVM has picked up pace hugely in the last few years, but Java-the-ecosystem tends to lag quite severely. Not least because these systems tend to be entrenched systems that move quite a lot of money around... or are highly business critical in some other way. This leads to extreme conservatism wrt. upgrades, etc. (That part has also gotten better, but especially the Java 8 -> anything later upgrade has been extremely painful because of modularization. Past Java 9 it usually isn't that much of an issue. However, JDK 11 was the first LTS release after 8, so most shops basically delayed the transition until JDK 11.)
  - vbsteven 6y ago
    This, and usually Java from 10-15 years ago before the `var` keyword and diamond operator.
  - dandersh 6y ago
    I definitely fell in this camp. To be fair I was fairly junior and was used to JS. It wasn't until I started using Haskell that I saw the benefits of knowing exactly what I was working with. It also helped me be more deliberate and thoughtful as you had to define everything up front.
  - brailsafe 6y ago
    Strong typing can be both needlessly verbose and useful, or the total opposite. My experience with java compared to Typescript, is that the tools largely compensate for Java's verbosity, while that is less true of TS or JS. For example, generating strongly typed method definitions from field declarations.
- ben509 6y ago
  > red flag is a bad description, because he ended up being self-reflective and looking deeper No, red flag is fair since it's just a warning sign. Even if we take it as a mark on the guy, it's true that he ought to get outside the scripty bubble.
- brailsafe 6y ago
  I built websites and wrote JavaScript for a long time before discovering generics by returning to school and being forced to build data structures from scratch in java. Other than that, there's no way I'd have ever come across them. I was just turned down from a senior position because someone had more years of React experience, so we're not exactly in the most sophisticated hierarchy here. Seniority should probably not depend on your exposure to technical language mechanics, especially those that weren't related to your area of expertise.
madeofpalk 6y ago
The author actively describes themselves as being "Anti-Typescript" and "hating" something they have no experience with. That's not skepticism.
victorbojica 6y ago
Being skeptical shouldn't mean being ignorant. Being skeptical should mean Trying to understand the pros and cons and believing it's not worth it.
- Vinnl 6y ago
  Or alternatively waiting it out a bit until it's more obvious what the pros and cons are (because others have tried it out in depth and shared their experience). Still a far cry from actively dismissing it.
  - cosmotic 6y ago
    Also more efficient. There's an endless, constant supply of new things not yet worth fully exploring.

nickysielicki 6y ago

Strong typing is not shiny or new and, even if you're a javascript guy, not being remotely familiar with any strongly-typed language (or generics?!) is a red flag. (edit: red flag is a bad description, because he ended up being self-reflective and looking deeper, which is just about the furthest thing from a red flag.)

mywittyname 6y ago
Agreed. But some people have an attitude of Strongly Typed == Needlessly Verbose. Probably because most developers have only experienced Strong Typing via Java.
- capableweb 6y ago
  I'm in neither camps (I don't have anything against types in places but I also don't try to put them everywhere). Could you explain how TypeScripts types would be more/less verbose than the types from Java? At a glance, TypeScript looks a bit more flexible, but mostly the same. Then Java is a verbose language in general (forced directory structure, one-class-per-file and yadda yadda) but that's besides the point as you're pointing to TypeScripts types being less verbose than Javas.
  - lalaithion 6y ago
    1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated<Generic<Type>> x = returnsComplicatedThing();`. (At least up until the last few years) 2) TypeScript has type aliases, meaning you can write `type MyTable = List<Map<string, number | string | Foo>>` and not have to repeat yourself everywhere. 3) TypeScript has anonymous unions and tuples, so instead of writing `Triple<Integer, String, Foo>` you can just write `[number, string, Foo]`, and likewise instead of `OneOf<Integer, String, Foo>` you can write `number | string | Foo`. These are also built in and very ergonomic, so you don't have to write a OneOf4 class whenever you want to have one of 4 things, and you don't have to write helper methods to convert between different sized OneOfs.
    - crocarneiro 6y ago
      Don't know about the other two, but the first one is available in java 10 and later.
      - mgkimsal 6y ago
        Worked on a project with an old (12+ years?) - but still being developed/used - Java system. Just last year a move was made up to Java 11 (from 8). Decent test coverage, but moving multiple systems is still a big task, but... they did it. Java 11. Yay. But... teammates were running in to issues with 'new' stuff - like, using 'var'. There were others, but this was sort of the archetypal argument. "Well, it doesn't match the rest of the style of the file/app - it'll make it hard to read". Well... hrm... any new feature literally doesn't match the style of what came before it, because you have new keywords/features/syntax to handle processes a new way. It's definitional. But just because there's a new feature doesn't mean it'll be adopted (for better or worse, I supposed, depending on your stance).
      - Quekid5 6y ago
        Java-the-language/JVM has picked up pace hugely in the last few years, but Java-the-ecosystem tends to lag quite severely. Not least because these systems tend to be entrenched systems that move quite a lot of money around... or are highly business critical in some other way. This leads to extreme conservatism wrt. upgrades, etc. (That part has also gotten better, but especially the Java 8 -> anything later upgrade has been extremely painful because of modularization. Past Java 9 it usually isn't that much of an issue. However, JDK 11 was the first LTS release after 8, so most shops basically delayed the transition until JDK 11.)
- vbsteven 6y ago
  This, and usually Java from 10-15 years ago before the `var` keyword and diamond operator.
- dandersh 6y ago
  I definitely fell in this camp. To be fair I was fairly junior and was used to JS. It wasn't until I started using Haskell that I saw the benefits of knowing exactly what I was working with. It also helped me be more deliberate and thoughtful as you had to define everything up front.
- brailsafe 6y ago
  Strong typing can be both needlessly verbose and useful, or the total opposite. My experience with java compared to Typescript, is that the tools largely compensate for Java's verbosity, while that is less true of TS or JS. For example, generating strongly typed method definitions from field declarations.
ben509 6y ago
> red flag is a bad description, because he ended up being self-reflective and looking deeper No, red flag is fair since it's just a warning sign. Even if we take it as a mark on the guy, it's true that he ought to get outside the scripty bubble.
brailsafe 6y ago
I built websites and wrote JavaScript for a long time before discovering generics by returning to school and being forced to build data structures from scratch in java. Other than that, there's no way I'd have ever come across them. I was just turned down from a senior position because someone had more years of React experience, so we're not exactly in the most sophisticated hierarchy here. Seniority should probably not depend on your exposure to technical language mechanics, especially those that weren't related to your area of expertise.

madeofpalk 6y ago

The author actively describes themselves as being "Anti-Typescript" and "hating" something they have no experience with. That's not skepticism.

victorbojica 6y ago

Being skeptical shouldn't mean being ignorant. Being skeptical should mean Trying to understand the pros and cons and believing it's not worth it.

Vinnl 6y ago
Or alternatively waiting it out a bit until it's more obvious what the pros and cons are (because others have tried it out in depth and shared their experience). Still a far cry from actively dismissing it.
- cosmotic 6y ago
  Also more efficient. There's an endless, constant supply of new things not yet worth fully exploring.