4 ms·

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 a

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.
  - cryptica 5y ago
    Yes but you forget incentives. If a tool makes something easier. People get lazier. E.g. People today have terrible handwriting because of computer keyboards. Many people today can't do long division on paper because of calculators. People today struggle to find their way around new places when they don't have Google Maps. But in this case, the skill which is being atrophied is an actual useful skill... Though it's not obvious at a glance. A tool which makes it easier to do the wrong thing will lead more people to do the wrong thing. The friction which dynamic languages create is a positive and promotes good code and professional development.
    - branko_d 5y ago
      Are you arguing that we should know which roots contain water and which parts of a horse are best for making bow strings? Circumstances change, skills evolve with the circumstances. Yes, there is a danger of sudden reversal of circumstances, but we still have our ability to relearn and rediscover the "old" skills if need be. If friction was "positive and promoted good code", the best code would be on punch cards.
      - 5y ago

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.
- cryptica 5y ago
  Yes but you forget incentives. If a tool makes something easier. People get lazier. E.g. People today have terrible handwriting because of computer keyboards. Many people today can't do long division on paper because of calculators. People today struggle to find their way around new places when they don't have Google Maps. But in this case, the skill which is being atrophied is an actual useful skill... Though it's not obvious at a glance. A tool which makes it easier to do the wrong thing will lead more people to do the wrong thing. The friction which dynamic languages create is a positive and promotes good code and professional development.
  - branko_d 5y ago
    Are you arguing that we should know which roots contain water and which parts of a horse are best for making bow strings? Circumstances change, skills evolve with the circumstances. Yes, there is a danger of sudden reversal of circumstances, but we still have our ability to relearn and rediscover the "old" skills if need be. If friction was "positive and promoted good code", the best code would be on punch cards.
    - 5y ago