Hacker News Reader

Comment by cryptica | Hacker News Reader

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.

View on HN

> 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?

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.

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.

https://www.youtube.com/watch?v=1vBesOFURek

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.

Would it be possible to fork Deno and expose types at runtime? My backend collegues seem to desire it.

You could probably codegen the .d.ts output of your types into different the body of API responses (or use it to generate a json schema), forking deno for it is probably overkill

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?

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.

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.

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

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.

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.

I understand that we are not used to factor in psychology when it comes to software development and that this argument may seem contrived but I'm speaking from my own professional experience when I say that I've observed both in myself and others that learning to use dynamically typed languages correctly has had a significant positive impact on the general code style. I've gone back and forth between the two paradigms multiple times. It forces developers to pay more attention to software design and structure or else it becomes overwhelming. The fact that code becomes overwhelming more quickly with dynamically typed languages is a positive thing. It's an effective deterrent against complexity and incorrect abstractions.

TypeScript also makes it easier to work with good code.

> symptom of the entire industry surrendering to bad code

Exactly. That's why TypeScript is structural typing with inference. The industry has given up on teaching developers how to organize code. The only way to force everyone to play nice together is through tools: prettier, VSCode, TypeScript, lint, etc. etc.

Part of me thinks this is a social problem. Too many unmoored egos in the industry and no one in the social position of being able to lay down ground rules for a codebase. Or possibly a result of devs chasing higher salaries and becoming mercenaries always on the move. It's rare to have teammates that have been with a company longer than a year anymore.

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.

What is the cost?

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.

What’s an example?

Reply on news.ycombinator.com