Hacker News Reader

Comment by seanhunter | Hacker News Reader

This article seems to ignore two of the most important reasons to choose one language over another. Specifically:

1)Expressiveness in the given problem domain. Some languages are really great in particular niches.

2)Availability of devs. The ability to hire and retain a really great team makes or breaks projects, and while a smart, motivated dev can learn any language, it's definitely a factor in their choice to work or not work with you. If you're in a niche language it will greatly affect the ability of people to use external resources (stackoverflow etc) if they hit blockers and some people will be reluctant to railroad their career into a tech that doesn't appear to be going to the mainstream. On the flipside, if you're lucky you may be able to get really passionate devotees of the language to work for you just to use the language where they might not have done it otherwise.

View on HN

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if it's ultimately more expressive.

This, turns out, is ultimately the most important thing amongst most important things. I've invested quite a lot of effort and time in D, back when D1 was around and D2 was a newsgroup post. D1 was everything I wanted out of better C, while d2 looked like it ought to be a better c++. Two years into heavy D programming, d2 vs d1+tango vs phobos aside, most of my time was spent in hunting for things or re-inventing things for weeks which I could've got in minutes with more popular language. Now that I'm older and hopefully wiser, I just go for my standard c toolbelt or, more often, python and be done with whatever I wanted to do without 'the hunt' (often for unmaintened things or things out of my knowledge scope - so I can't even re-implement).

With all that said... Lisp' siren call is still out there, and experience tells me it will be the same. (As it was once before)

With the existence of d++[1], you can essentially use any existing c or c++ library by simply including its header file.

1: https://github.com/atilaneves/dpp

While interesting, glancing through readme/limitations just furthers my (view)point based on experience.

Since then, I do by and large dive into new languages but don't use them. What I do is bring back home some of the practices which I think are of benefit to me.

Exactly that's why for CFD Fortran still has so many advantages.

This is definitely key - one startup I worked for was messing around with live voice capture and processing, voice recognition, etc.. by and large the libraries we had access to that could help do tiny manipulations, cutting, processing of the waveform data was primarily C. We wrote most of our code in C++ because we could directly call C functions and use header files directly.

This was 15 years ago, but I honestly don't know what language I would use today. It's funny but sometimes binary data handling isn't a particular language's strong suit simply because they don't have the primitives to handle it, or if they do, the APIs to handle them are awkward or unnecessarily verbose. It's kinda neat that in C/C++ you can take a 1MB byte buffer and pass it to a function starting at 30% in. In other languages its like you have to pass in the whole thing and another parameter to tell it where to start. I get that's why C/C++ is in the situation it's in (security - but that's why I don't use C/C++ to handle web requests), but sometimes tasks need that.

That is how I migrated from Turbo Pascal to C++, around 1994, only touching C when required to do so.

Could make use of a saner type system, nice frameworks (Turbo Vision, OWL), while being able to painless create safe wrappers around C libraries.

0) Tool satisfaction

> motivated dev can learn any language

The key word is "motivated". That's why I'm an expert user of C++98 and D but I can't learn Go, Python, C++11, etc.

> able to get really passionate devotees of the language

That.

>I can't learn Go, Python

I lol'd at this

I sometimes think people use "availability of devs" to mean "cheap, expendable service". If you're working in an industry where you bank more on hitting the ground running more than retaining developers then this makes sense, and totally valid.

But I've found that lots of places seem to be focused on if you know X rather than being a well versed, developer who enjoys growth. And it feels more and more like the reason is because they don't expect anyone to stay there for more than a few years tops.

Reply on news.ycombinator.com