Hacker News Reader

Comment by jondubois | Hacker News Reader

>> The worse the abstraction that you and your colleagues are likely to use, the better a language is Go

I feel the same way about most statically typed languages. They're designed for developers who aren't good at coming up with abstractions. Basically, they're great for junior developers. For senior developers, they just give you more work and slow down progress.

On my last project (statically typed language), we had to do a refactoring of a decent portion of the code just because it allowed us to use one interface/type instead of two related interfaces/types (one inheriting from the other). It didn't fix any bugs, make it more maintainable or even change the external behaviour at all.

View on HN

Another gent who asserts that languages he likes to use are better for "senior developers" while those he doesn't are better for "junior people".

Don't hire anyone who makes such insulting remarks.

Why is it insulting? I didn't say that using the language means that you're a junior. I just said that it was designed for juniors.

Just like there are adults who wear diapers, it doesn't mean that they're juniors. In fact, most of them are very senior. They just like to be on the safe side.

Gents, this ^ is what "full retard" looks like.

Sorry for the confusion, next time I will try to dumb it down further... Maybe I need to start using static type annotations to indicate sarcasm.

I have to side with jondubois on this one, and I don't think it's an "insulting remark" to make.

According to my experience, there is clearly a spectrum of language difficulty. Go is on the one end, being easy to pick up and use productively by design, and e.g. Haskell is more on the other end, where you have to take a lot of time to learn the underlying concepts before you can use them really effectively.

Languages like Haskell are clearly aimed at "senior developers" in a way that Go is not, where "senior" doesn't necessarily mean "min. X years of industry experience", but "min. X years of category theory experience".

And this difference is important to keep in mind. When I work on a really difficult problem, it's probably a good idea to choose a powerful language to help me solve the problem, but it means that only sufficiently senior developers can work on the program. On the other hand, a run-of-the-mill CRUD application should probably be written in something like Go or JavaScript because it's way easier to hire developers for these languages. If I write a dumb CRUD application in Haskell, it means that my experts can probably never hand this over to junior developers. That's not a productive use of their time.

I'm curious in what way static languages are "designed for developers who aren't good at coming up with abstractions", are "more work" and "slow down progress".

Those are quite strong statements to not be backed up by strong examples, and I personally find that your example does not clearly illustrate how that would make statically typed languages have the attributes you ascribe them.

> For senior developers, they just give you more work and slow down progress.

From my point of view, the static type system does work for me. Having to write tests for what a static type system can prove is tedious, and it only provides run time instead of compile time errors.

I don't think he's bothering with tests ;-)

I get that you're frustrated, but... it's unhelpful to dream up reasons for something decades after the fact happened. The more reasonable explanation is that they're designed that way, so that the compiler can verify particular properties of the code and because back then the performance difference really mattered. That in turn has some costs on development speed in the prototyping phase.

Can anyone seriously argue that our industry has a problem with development speed? And that extra speed will evaporate once the code base becomes big enough and one needs 1:1 test-to-code lines to keep the thing under control.

So basically you are saying that using a language with static typing you are guaranteed by the compiler that your refactoring is safe, while in a dynamic typed language you completely lose this guarantee and you will introduce bug, and you choose happily the second option? And you are also convinced that people that want some correctness guarantee are juniors while who doesn’t care of introducing bugs is a senior? Since when did the world start going upside down?

Dynamic languages are ok for toy projects/websites.

If you have to build something large/complex/that has to work within constraints, statically typed languages are the way to go.

If refactoring "a decent portion of the code" of a project involves only a couple of interfaces/types, it is a tiny project and yeah, using a toy language would probably have been ok for that.

Agreed, that's the same thing I feel now that I am experienced in both types of languages (statically and dynamic typed). I am way faster when using dynamic typed languages.

Reply on news.ycombinator.com