Hacker Newsnew | past | comments | ask | show | jobs | submit | incompletude's commentslogin

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.


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


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.


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.


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?


Type checking and strongly typed languages are rapidly taking market share and in the near feature, except for niche specific software, mostly everything will be typed. There are a few reasons for this: it makes software easier to change and to test, and in a scenario of fast-growing complexity like the world we live in today, it is better suited for software development.

I would recommend to every software developer to learn the type ecosystem inside their language to make sure they have a good/high-paying job in the near future.

In 5 to 10 years, almost every serious engineering job will be working with an ecosystem that contains types.


I prefer to build MLPs (minimum loveable product) instead. If your MVP is bare bones and far away from the ideal product, you are effectively working against your core business viability. You instead have proved that an unfinished product is not viable.


You should vest them monthly instead of only after the full term completion.

If the full term is 2 years, pay him 23/24 and let him go.


If you have been giving honest feedback about the performance issue and he is aware of what is going on, you can risk a termination whitout compensation but you are probably getting sued. If he is not aware about the management insatisfaction you are most likely getting sued because he will see receive it as an unjust termination.

The best case scenario here is to push some form of compensation agreement.

Also, as a manager, you should build trust, even you people that you don't particularly like, so termination without compensation can have negative lasting effects on teammates.


stock options vesting is specifically designed for this, whoever brings value to the business should have them. job title is not important, value is what matters.

a 1-5% equity (varies widely) for early stage startups (seed or angel) is common practice to negotiate commitment.

if your company do not want to negotiate this and you provide value just get a second job as a consultant.


Our fellow human comrades in the country next door have a very similar belief system that contains the same defense mechanisms. Spread the word and fight the enemies of their deity.

This is self-reflection: everyone believes what fits better to one, don't push your shit over others or risky getting killed with bows and arrows, and every now and then bombs.

Religions are very creative ancient defense mechanisms. It exists for you to have bonds to your group, for you to survive, and protecting the belief system is to protect your own. But this is not 1600 anymore, time to grow up. Take the good stuff and throw the toxic shit behind or put it all behind.


And that is why I also understand that he is dead by bow and arrow.

Sometimes is terrorism.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: