Hacker News Reader

Comment by chucklenorris | Hacker News Reader

As i said before, a lot of people expect that writing typescript is as easy as writing js, which is not. I estimate the typescript tax to be around 40-100% more time, especially if you want to do typescript right and not use `any` all over the place. And besides, typescript is a poor fit for someone who is used to writing highly dynamic, lambda based code, which is one of the main niceities of js. My guess is that a lot of people with a background in java and c# found themselves writing server side js and were really unconfortable with this paradigm, so they tried again to turn js into what they knew best - an imperative object oriented programming language. Now, i'm not saying that types are a bad thing, i for one like typescript especially in projects with a lot of people, but, it's funny to see new people struggling to finish a task that should take a few hours in days.

View on HN

These estimations are pure imagination. I doubt you have `any` real data to support it. Also, that is not the reason why Typescript was created, nor the reason why people adopt it, not even what Typescript really is. Today, almost every Node.js framework supports Typescript out of the box. I challenge you to provide a modern framework that doesn't provide types. And this is not an opinion, nor it is wishful thinking, it is a fact: type checking and strongly typed languages will take over almost every modern software development paradigm.

I work with typescript everyday. I review prs, i mentor junior devs that are learning typescript. Ofcourse this is my experience, maybe yours is different, if so please tell me about it. The only thing i said is that there is an upfront cost in velocity that people are usually not considering when they are choosing to use ts over js. Sure, that cost may be amortised in fewer bugs and easier collaboration across large development teams. But i see people struggling everyday with specifying correct and complete types. I reject prs, i babysit devs that can't figure out how to type certain code constructs. And if i don't do this the project ends up a mess of anys and ts-ignores which undermines the value proposition of typescript.

I think whatever tax you pay in writing typescript (which, as someone reasonably experienced with it, I believe is none or exceptionally minimal) you easily get back from improved efficiencies of not requiring memorizing the entire shape of your application, looking up in seperate documentation, or a run/inspect/write-code just to see what things are.

I think that typescript's type refinement is extremley useful to know whether you've covered all the cases for the types of data as it flows through your system.

If someone cannot reason about types when forced to, I wouldn't want to see their code _without_ typescript.

Strongly typed languages already did take over the software development paradigm. It happened when Java, C++ and C were the dominant languages. Then it regressed back to dynamically typed languages as ruby, php, python and js skyrocketed into popularity.

With the advent of typescript and other things like it... types are now back in vogue but for how long?

The universe is a four dimensional loop. Programming, like history, like life, moves in an endless flat circle. It's all so predictable... Because This ENTIRE thread represents a precursor to the inevitable and impending oscillation back to the beginning of the circle. Types will fall out of vogue and history will repeat.

> types are now back in vogue but for how long?

Probably until startups and organizations that use more flexible languages race past those who strongly type things. Just like in the early days of the web and actually for ~2 decades in which everyone who used loosely typed languages raced past those who strongly typed stuff due to the ease of use and flexibility. If typing was the way to go, already existing typed languages would rule the roost. But they didn't.

The end users dont care about any engineering concerns that we have. They care whether they can do what they want with an app or service. And organizations that can ship code fast will keep their strong advantage.

> Strongly typed languages already did take over the software development paradigm. It happened when Java, C++ and C were the dominant languages.

C is not a strongly typed language. Did you mean statically typed?

An estimation doesn't need data. It's a best guess. I don't think its fair to call it an imagination. As far as we know that's what he thinks based off his observations.

I converted a few codebases from JS to TS and this takes a surprising amount of time. I won't put out estimates but it's definitely non trivial.

> I challenge you to provide a modern framework that doesn't provide types

Ruby on Rails

He was clearly talking about nodejs frameworks.

> These estimations are pure imagination

There are decades of literature on the matter.

You simply have to look for it.

Statically typed languages are known to lead to slower initial development times, because languages are inherently more complex and there are more concepts to grasp.

usually thy also need to be compiled, which makes times even longer and setups harder.

Good news is that long term they tend to be associated with easier maintenance, but it's not totally clear if it's due to static types or the team getting more accustomed to the code base and tools having more metadata to help the programmer.

One thing that is unquestionable it's that statically typed languages scale better in large teams.

if anything goes well, of course , if you OTOH happen to end up working in places where they use types to build gigantic taxonomies, all the advantages are gone.

> Today, almost every Node.js framework supports Typescript out of the box

it doesn't follow that TS is great though.

It simply says that people building frameworks want to sell them to the larger audience possible.

If they could support Java or C++ or Rust, they would.

Many Java libraries or frameworks still support Java 8, doesn't mean Java 8 is the greatest Java out there.

> Statically typed languages are known to lead to slower initial > development times

I hear people saying that, but I'm not sure I buy it. Is there any research that supports that, and if so, for which languages? Also, what does "initial development" mean here? The first day, week, month, year? And unless your project is trivial, isn't it somewhat important that as much of the initial work as possible provides a solid foundation for the future of the project so it wouldn't pay off skimping on this?

PDF: https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane...

see conclusions

intuitively static typing is less forgiving and forces programmers to write code in a specific form

think how much time has been wasted writing Java boilerplate code.

To be honest, that looked a bit thin. And the most productivity-killing Java boilerplate is hardly due to its static typing but rather the baroque style required by lots of frameworks. It is important to differentiate between language and how people tend to use it.

It's definitely "harder" to write TS in the sense that you have to learn more stuff and think about things more, but I seriously doubt it is any slower on anything except the smallest projects.

Any time you lose writing type hints you gain back from better IDE support and fewer bugs.

It's really a no brainer. I can only assume everyone here arguing against it works on one-man projects using Notepad.

Reply on news.ycombinator.com