4 ms·

The real purpose of TypeScript is job creation. Corporations constantly need new ways to keep their employees busy, distracted, and compliant. I really hope tha

The real purpose of TypeScript is job creation. Corporations constantly need new ways to keep their employees busy, distracted, and compliant. I really hope that one day, most developers will realize that there are far more important things than static typing... I mean so much more important that it makes static typing seem completely futile and even counterproductive. You may downvote today, but you might understand what I mean in 5 to 10 years. I've been through all the phases already. I'm even exhausted trying to explain it to people. The hype is too strong. Good luck, gen z.

girvo 5y ago
I'll downvote today because cryptic "you'll understand when you're older" comments that don't expand on why you believe that to be the case add very little to the discourse, even if I might agree with the overall premise.
throwanem 5y ago
If you've been to that much effort already, one imagines you'll have a canned summary of your thesis and arguments somewhere linkable. I mean, of course there are far more important things than static typing. Which of them do you have in mind?
- Scarbutt 5y ago
  Handling of state. Reusability, extendability, flexibility, immutability, avoiding brittleness and coupling. The things Typescript gives you are very physically visible and so, gives the illusion and confidence it will guard you in everything but in reality it helps in the most trivial of problems and you are paying a big cost for it.
  - mb7733 5y ago
    What is the cost?
  - throwanem 5y ago
    I've been writing Javascript for twenty-six years, seventeen professionally, and Typescript since 2017. No one has ever in my experience made the claim that Typescript solves all, or even really any, of the concerns you list. That when well used it can make them easier to solve, sure, and that's true. It comes in exchange for a little more effort, that's also true, but I've found that tradeoff considerably beneficial on net, because the type system when used thoughtfully makes whole classes of bugs harder to write, and their virtuous complements easier. If people are saying the type system is a magic bullet, the problem is with that claim and the people making it, not with the type system.
- cryptica 5y ago
  High cohesion, loose coupling. That summarizes it. But to understand what it means usually takes at least 10 years and most people will never understand it. My best interpretation of high cohesion is that it means that every component/module/class in a system can be easily explained to a non-technical person who has business/domain knowledge... In as few words as possible. Loose coupling requires simple interfaces. Simple functions/methods which accept simple (raw primitives or plain objects) as arguments... You want to avoid methods which accept 'live instances' as much as possible. Instances which have their own internal state should not cross module boundaries ideally (not passed around as arguments). That is also a sign of low cohesion. High cohesion and loose coupling often go together naturally. For loose coupling, I often think of a power plug/power point or a USB port... Simpler is better. Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with 10 holes... Imagine how much work that would be for the electronic equipment manufacturers. The interface must be as simple as necessary to get the job done. If you can do these two things, it will constrain how you think about and write code and you will produce the most maintainable code you can imagine. The language won't even matter at all. If your method interfaces are simple (no complex type parameters), it becomes trivial to figure out which types a specific methods accepts as arguments. IMO TypeScript makes it easier to work with bad code, but isn't a better solution simply to avoid bad code? It's not that difficult once you have the right approach. In a way, I feel like TypeScript is a symptom of the entire industry surrendering to bad code... A surprising number of people in the corporate sphere actually believe that there is no such thing as good code and even that architecture, software design and planning doesn't matter. The only solution they will accept is to throw more people at the problem and implement security through obscurity.
  - TheCoelacanth 5y ago
    I don't agree that types make it easier to write bad code. If anything, they make it easier to spot bad code by making interfaces more explicit.
  - branko_d 5y ago
    > Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with 10 holes... Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with unknown number of holes. With static typing, you at least know how many holes are there. Now, I agree that "the interface must be as simple as necessary to get the job done", but non-trivial problems will have non-trivial essential complexity even after you have removed all incidental complexity.
proxyon 5y ago
> The real purpose of TypeScript is job creation. Corporations constantly need new ways to keep their employees busy, distracted, and compliant. You threw out a wild thesis and then said nothing to support it. Can you elaborate and actually provide evidence for what you're referring to and why Typescript is a trojan horse for useless busy work like you're alleging? At our org Typescript has been a game changer for and by developers. It makes our lives better. It was driven by us, for us. And we had to sell it to management, who reluctantly OKed it knowing it was going to cost the org money but make us happy. How does that fit with your thesis?
exdsq 5y ago
What’s an example?
arcanon 5y ago
The gen z people I know think webdev is a joke. They’re off playing with unreal engine blueprints and shaders and stuff. TS on the serverside is an abomination. Just learn a real language like Go or hey Java.
- phist_mcgee 5y ago
  https://www.youtube.com/watch?v=1vBesOFURek https://www.youtube.com/watch?v=1vBesOFURek
- seer 5y ago
  Interesting that you mention it. I'm much more versed in TS than in go or java for sure, but after some knowledge sharing sessions with devs in those languages, as well as Scala devs, I can say they all _can_ learn a thing or two about types from TS, even if they themselves are superior on the backend. For example I was surprised to realise how TS took go's value based interfaces and applied it to java concepts. And added almost Haskel level type manipulation on top of it. These are rather recent developments - last couple of years stuff, but in TS you can write things closer to higher kinded types, conditional / dependent types and all sorts of wizardry that can explain to the compiler what _exactly_ you want to accomplish, much more so than in Java or go. And you have a very cheery and down to earth language underneath to do it with. Once you do, you almost don't need unit tests - you get the "if it compiles, it'll work" kind of feeling. I've had sessions of days writing TS code without ever running it once, completing a complex feature, then compiling it and having it work exactly as specified on the first try, it's bizarre. Now I'm not saying you can't do that with go or java, its just that I have a feeling people are dissing TS for what it was 5 years ago, and haven't realised they've been passed over already. TS's biggest downside compared to langs like Scala is that you can't use typescript types at runtime, where apparently Scala gets its more advanced features (implicits etc). Oh oh and if it ever gets pattern matching and algebraic effects ... And if deno's creators play their cards right and fix the standard library, give us go's channels, scala collections or swift's actors ... one can only dream.
  - machiaweliczny 5y ago
    Would it be possible to fork Deno and expose types at runtime? My backend collegues seem to desire it.

girvo 5y ago

I'll downvote today because cryptic "you'll understand when you're older" comments that don't expand on why you believe that to be the case add very little to the discourse, even if I might agree with the overall premise.

throwanem 5y ago

If you've been to that much effort already, one imagines you'll have a canned summary of your thesis and arguments somewhere linkable. I mean, of course there are far more important things than static typing. Which of them do you have in mind?

Scarbutt 5y ago
Handling of state. Reusability, extendability, flexibility, immutability, avoiding brittleness and coupling. The things Typescript gives you are very physically visible and so, gives the illusion and confidence it will guard you in everything but in reality it helps in the most trivial of problems and you are paying a big cost for it.
- mb7733 5y ago
  What is the cost?
- throwanem 5y ago
  I've been writing Javascript for twenty-six years, seventeen professionally, and Typescript since 2017. No one has ever in my experience made the claim that Typescript solves all, or even really any, of the concerns you list. That when well used it can make them easier to solve, sure, and that's true. It comes in exchange for a little more effort, that's also true, but I've found that tradeoff considerably beneficial on net, because the type system when used thoughtfully makes whole classes of bugs harder to write, and their virtuous complements easier. If people are saying the type system is a magic bullet, the problem is with that claim and the people making it, not with the type system.
cryptica 5y ago
High cohesion, loose coupling. That summarizes it. But to understand what it means usually takes at least 10 years and most people will never understand it. My best interpretation of high cohesion is that it means that every component/module/class in a system can be easily explained to a non-technical person who has business/domain knowledge... In as few words as possible. Loose coupling requires simple interfaces. Simple functions/methods which accept simple (raw primitives or plain objects) as arguments... You want to avoid methods which accept 'live instances' as much as possible. Instances which have their own internal state should not cross module boundaries ideally (not passed around as arguments). That is also a sign of low cohesion. High cohesion and loose coupling often go together naturally. For loose coupling, I often think of a power plug/power point or a USB port... Simpler is better. Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with 10 holes... Imagine how much work that would be for the electronic equipment manufacturers. The interface must be as simple as necessary to get the job done. If you can do these two things, it will constrain how you think about and write code and you will produce the most maintainable code you can imagine. The language won't even matter at all. If your method interfaces are simple (no complex type parameters), it becomes trivial to figure out which types a specific methods accepts as arguments. IMO TypeScript makes it easier to work with bad code, but isn't a better solution simply to avoid bad code? It's not that difficult once you have the right approach. In a way, I feel like TypeScript is a symptom of the entire industry surrendering to bad code... A surprising number of people in the corporate sphere actually believe that there is no such thing as good code and even that architecture, software design and planning doesn't matter. The only solution they will accept is to throw more people at the problem and implement security through obscurity.
- TheCoelacanth 5y ago
  I don't agree that types make it easier to write bad code. If anything, they make it easier to spot bad code by making interfaces more explicit.
- branko_d 5y ago
  > Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with 10 holes... Imagine how difficult it would be to plug an elaborate 10-prong power plug into a socket with unknown number of holes. With static typing, you at least know how many holes are there. Now, I agree that "the interface must be as simple as necessary to get the job done", but non-trivial problems will have non-trivial essential complexity even after you have removed all incidental complexity.

proxyon 5y ago

> The real purpose of TypeScript is job creation. Corporations constantly need new ways to keep their employees busy, distracted, and compliant. You threw out a wild thesis and then said nothing to support it. Can you elaborate and actually provide evidence for what you're referring to and why Typescript is a trojan horse for useless busy work like you're alleging? At our org Typescript has been a game changer for and by developers. It makes our lives better. It was driven by us, for us. And we had to sell it to management, who reluctantly OKed it knowing it was going to cost the org money but make us happy. How does that fit with your thesis?

exdsq 5y ago

What’s an example?

arcanon 5y ago

The gen z people I know think webdev is a joke. They’re off playing with unreal engine blueprints and shaders and stuff. TS on the serverside is an abomination. Just learn a real language like Go or hey Java.

phist_mcgee 5y ago
https://www.youtube.com/watch?v=1vBesOFURek https://www.youtube.com/watch?v=1vBesOFURek
seer 5y ago
Interesting that you mention it. I'm much more versed in TS than in go or java for sure, but after some knowledge sharing sessions with devs in those languages, as well as Scala devs, I can say they all _can_ learn a thing or two about types from TS, even if they themselves are superior on the backend. For example I was surprised to realise how TS took go's value based interfaces and applied it to java concepts. And added almost Haskel level type manipulation on top of it. These are rather recent developments - last couple of years stuff, but in TS you can write things closer to higher kinded types, conditional / dependent types and all sorts of wizardry that can explain to the compiler what _exactly_ you want to accomplish, much more so than in Java or go. And you have a very cheery and down to earth language underneath to do it with. Once you do, you almost don't need unit tests - you get the "if it compiles, it'll work" kind of feeling. I've had sessions of days writing TS code without ever running it once, completing a complex feature, then compiling it and having it work exactly as specified on the first try, it's bizarre. Now I'm not saying you can't do that with go or java, its just that I have a feeling people are dissing TS for what it was 5 years ago, and haven't realised they've been passed over already. TS's biggest downside compared to langs like Scala is that you can't use typescript types at runtime, where apparently Scala gets its more advanced features (implicits etc). Oh oh and if it ever gets pattern matching and algebraic effects ... And if deno's creators play their cards right and fix the standard library, give us go's channels, scala collections or swift's actors ... one can only dream.
- machiaweliczny 5y ago
  Would it be possible to fork Deno and expose types at runtime? My backend collegues seem to desire it.