Hacker News Reader

Comment by sAbakumoff | Hacker News Reader

My vision of it is Flow and TS and stuff prevent 15% of bugs that the beginner and intermediate level developers typically make, but engineers on the advanced and higher levels avoid these bugs by just writing a good code in any language they use.

View on HN

I've been writing js professionally for more than ten years, and I totally love flow. Sure, it doesn't happen that often that I feel like I've caught with it a bug I wouldn't have without it (not even sure how you can tell one from the other, when you correct a type check error), but the most notable effect is the release of tension : I don't have to double check everything I write, I can rely on the type system to report obvious problems.

If anything, I think flow does not go far enough, compared to compiled languages with type systems. The fact that it allows to mix typed and non typed code is error prone, and there are annoying edge cases, like the spread variables not being correctly checked for (this can cascade quickly, when passing properties in react). I would love to see types as a core part of the language, with native browser tooling.

Thanks, that's interesting experience!

Similar experience with typescript, the win is not having to make room in headspace for things the machine can handle.

>but engineers on the advanced and higher levels avoid these bugs by just writing a good code in any language they use.

Belief that one can just "write good code" and you don't need types/tooling/linting etc is a sure sign of a still inexperienced developer.

Actual senior developers are much more humble and use all the help they can find.

>Actual senior developers are much more humble and use all the help they can find.

sure, this is raison d'etre of package managers like NPM.

Christ, absolutely. No more hunting down obscure libraries through the Internet and guessing which version the author had in mind.

Or which 3 packages with the same name from spooky abandonware looking websites.

No amount of good code will prevent a typo in a property name that's only encountered on the edge case of an edge case. It's arguably that 100% test coverage could catch such a bug but that's neither always possible nor cost effective. Static type checking is for catching exactly that sort of thing.

Oh yes, the old “I’m too good to need help from no stinking compiler” argument.

I never mentioned my level, didn't I? :-) In fact our team is going to switch to TS and I just don't have any other option but start using it. I am OK with that, I guess.

I dunno man, it sounds more like an intervention than a switch.

The best comment in this thread!))

So it helps developers that need it and does not get in the way of developers that don't ? Then its a win without any downsides.

Even advanced and higher level developers can easily make the same mistakes as beginners or intermediate given that the code base is big enough and there are many people working on it. The probablility of that is lower but not 0. As an example you can look at quotes from MS guys, they said that it was benefitial for them to create TypeScript. And from my experience many MS engeneers are at very good level.

Typing systems for dynamic languages shouldn't be viewed as crutches for the inexperienced dev - experienced devs should seek them out when the ROI is there.

If any level of your tech stack offers you guarantees, use them so that you have less code to write. Less code is less opportunity for bugs and faster development.

That's an assumption for a best case scenario vs optimizing for the worst. I rather optimize for the worst, especially in a team; and furthermore a company with growth.

True, but a lot of those people would rather use a safer language to prevent those bugs than write preventative code every single time, or remember to replace built in language features with their own functions every time.

I wouldn't consider engineers who think they "just write good code" and won't make those mistakes "advanced" or on a higher level. They have yet to learn one of the most important lessons.

To not make type errors you not only have to be a perfect typist and completely engaged all the time, you also need to be an expert in the part of the system you're developing.

Don't you just need to to actually use/test your code? Don't you need to do this in a statically typed language as well?

Often you don't. When you're really leveraging the type system, if it compiles it'll be correct. You might need to test the actual business logic, but realistically that ends up being a small proportion of the code you write. People don't like talking about how type systems let you write fewer tests, perhaps because it makes them sound like cowboy coders, but honestly it's a huge advantage.

Not only can you write more precise tests (because you don't have to worry about run time crashes from type errors or logic errors from type mismatches) but your tests themselves are also type checked.

> writing a good code

AND

using good code.

If a "Expert" have the option between use something that solve more problems better than other, is NOT a expert to not use it. Is just masochist.

Agreed, re-using a good code is one of the most important skills.

Won't most code bases be written by teams consisting of some or even most beginner and intermediate level developers?

My impression is that most companies experience a shortage of talent such that they take in greener members with each passing year. Ideally they should have the best conditions to turn out good quality code before they get to an advanced level. The tooling plays a big part.

Revolutionary complement: if your definition of talent excludes junior developers, there won't be any seniors 10 years later. Every single senior was junior few years ago.

Moreover, companies are biased more against older people then young. Which gives us few yes when we are hiring magically appearing seniors - after they got experience (elsewhere) and before they are old.

Engineers on the advanced levels are concerned about lightning fast and safe refactoring and resilience against spaghettification when passing on their code to other team members or outsiders of unoptimisticly unpredictable skill sets.

This is an issue on which self-serving opinion, on both sides, predominates, so this study is very welcome. If you think it is flawed, do your own study.

I am wondering what level downvoters have :-)

"I think you're arrogant in suggesting that only beginner and intermediate programmers make these mistakes" level.

Yes, advanced programmers make these mistakes too, and they find tools like this helpful in catching them. That's why Microsoft created TypeScript. That's why Facebook created Flow. Facebook and Microsoft are two companies I wouldn't call beginner or intermediate.

1. Never I suggested that advanced programmer don't make mistakes. They do. Beginners just make more and/or more expensive mistakes.

2. Never I suggested that MS and FB are beginners.

Reply on news.ycombinator.com