[denismenace]

They also assumed Haskell performed so well, because the author was an expert at it. So, they independently hired a college graduate with no prior knowledge of Haskell and gave him 8 days to learn it. Turns out the graduate implemented the second best solution in terms of lines of code and development time.

[kubb]

But they hired someone capable of learning.

99% of developers will not learn a language that doesn’t look familiar to them on principle. They don’t like it and it’s the end of discussion.

[blacksqr]

What a shame.

When I started out in the 1990s professional programmers generally made a point of learning new languages, to acquire skills and expose themselves to alternate ways of thinking.

I remember a boss in the early 2ks who was teaching himself OCaml in his spare time just because.

[ookdatnog]

I love learning interesting niche languages and also wish it was still the case that learning interesting languages purely out of interest was common.

But I'm afraid that the network effects that favor large languages are only getting stronger over time. It's very hard to convince someone to learn a new language if they're used to finding the answer to almost every question they can think of on Stack Overflow and find free libraries for almost any task on GitHub. Your niche language will have neither of those things. Large languages will continue to consolidate and become impossible to displace, even if a new language pops up that is strictly better in terms of design.

Entrenched programming languages have reached the point where, I believe, they will never be displaced. So there are certain obvious mistakes, such as every object in Java being nullable, that we will have to live with in perpetuity.

[dleslie]

In the mid-to-late naughts there arose the diploma mills, offering short programmes to turn students into silicon valley hopefuls. It fundamentally shifted the culture of software development.

[klodolph]

There was also a dire need for more programmers. I think the industry would take what it could get.

[bluGill]

There are a lot of developers that won't even learn new things about their current language. I'm still fighting to get some people to adopt C++11 which is 13 years old now.

[rramadass]

I used to think this sort of "unreasonable" mindset was a characteristic of "old fogies" and "bright young'uns" always knew better. But ever since i moved from the latter to the former group years ago i began to understand this mindset. It is basically a fear of losing the expertise one has acquired over a long career through a language which has become almost second nature. Also with time and experience you become very cautious about trying out new things in production code because you still don't understand the ramifications fully. For all its complexity, pre C++11 was far simpler to understand and write code in. We knew the minefields and what to avoid and how to model effectively. So most of us are not a fan of new additions to the language every 3 years just because the committee members are trying to ape other languages. Speaking for myself, i only wanted a concurrency library and some compile-time programming constructs as new additions to the language, everything else was strictly not necessary.

Looked at from the above viewpoint, you should be able to appreciate us "old fogies" mindset and why we refuse to eagerly jump on the C++11 (and later) bandwagon just because it exists. We need a justification for every new thing we are forced to re-learn and use. So my suggestion is to take one new feature at a time, discuss and convince the folks of its utility, maybe make the changes in one single module and demonstrate it. The argument of "its new and shiny" will never fly with us.

[bluGill]

I am one of those old fogies. While some of the new things in C++ are not useful to me, there are a lot of things aped from other languages that make my life better. Those who are not interested in learning everything can sit back for a bit while those who eagerly jump to new things figure out what is good and what they can ignore (remember that each problem domain is different so we won't all have the same answer). For me, just using unique_ptr would be a major improvement.

Even the old fogies need to be aware of what is happening. I haven't yet done much Rust, but the advocates (when I cut through their Rust religion) are saying some things that really speak to my pain points and so I'm planning to learn it (and have been for a couple years - I may retire before I get around to it, but some new and shiny things are not just glitter and so it remains on my list)

[rramadass]

Ah; a kindred "old fogey" :-) Yes our experience shapes how eager we are to jump to learn new things. But it is eventually done at our own pace. In general though, with age and experience people become more cautious psychologically. Probably because we have made so many mistakes which in hindsight could have been avoided if we had thought more and studied more. This is what is frustrating with "shiny new" features. Even before people have gotten some substantial real-world experience with C++11, you have C++14/17/20/23 piling on top and making us feel peak "imposter syndrome". To make matters worse, the noobs/wannabes start "cargo cult programming" with no real understanding and thus ruining the s/n ratio. They don't understand that merely learning the new syntactical features will not magically make one a better and more productive programmer.

The C++ standards committee really needs to disband itself for a decade and leave us programmers in peace :-) Stroustrup wasn't kidding when in the preface to the 4th edition of TC++PL he said "C++11 feels like a new language".

Finally, i agree that we need to be aware and keep abreast of new languages/features which are genuinely good/useful but i would rather be "slow and sure" than "fast and fail".

[bluGill]

> C++ standards committee

Is working on things that would be useful. The early adopters of modules have reported some very intriguing results - it isn't ready for me to try yet, but so far what the standard committee has done looks like it will be a win for me in 5 more years when I finally can adopt it. Reflection and contracts are two other things coming that have some intriguing uses in the real world and I'm hopeful to see how/if they work out.

[hresvelgr]

I think the dichotomy of script kiddies versus hackers applies aptly to modern developers. Some developers learn their frameworks and libraries and enough of the language to be productive (script kiddies), whereas some have a keen interest in understanding how a system works and the art of software engineering (hackers). Hackers in my experience are still a very rare breed.

[epgui]

This has been my experience with most engineers.

[eddsolves]

I can’t think of a time I’ve seen this, and I’ve worked with most languages at least once (including Haskell, Rust, Go, F#, PHP, Java, etc…)

[marcosdumay]

One of the other competitors was the project head. All of those people seem deeply inclined into learning and experimenting.

[gaze]

Even if this is sometimes true, when you adopt this viewpoint your work turns to crap. Hire good people, and if you can't hire good people, do something more interesting.

[golly_ned]

How did they learn the languages they currently know?

Perhaps only God knows.

[warkdarrior]

They took a programming camp they paid for, where they were given the task to learn the language of the day. So they learned it because they were forced to, not out of curiosity or desire to improve.

[pyrale]

Monkeys using a typewriter were also proven to be 83% more productive than the average developer. Study suggests that their edge likely came from not understanding and ignoring the certified scrum master™.

[kccqzy]

Someone who learned Haskell intensely for 8 days could very well be more productive than someone who learned Haskell intensely for 80 days. The former probably got a good introduction to the standard library functions and has become familiar with the main classes like Functor, Applicative, Foldable, Traversable. The latter might be too engorged in advanced language features like TypeInType; or evaluating and choosing between slightly different abstractions to accomplish a single goal, like choosing van Laarhoven optics vs profunctor optics.

And I'm not trying to demean advanced type system extensions or van Laarhoven lenses; I'm just reflecting on my personal journey with Haskell. Playing around with the language in this way is similar to playing around with advanced template meta programming in C++. It just takes experience to have the discipline to know the difference and write simple code and be productive.

[mhitza]

Submitted report was published in 1994.

At the time I don't think Haskell had any of that, and not sure when monads were introduced in Haskell either (wasn't on day 1 I think). Which means that the language was simpler in some aspects.

But what I do think made the job simpler is that they had easy access to other people that knew Haskell. Whereas, today, unless you have a mentor you're going to need to handle any issues you're encountering via delayed responses on community forums... Or AI, most of the time.

[kccqzy]

Yeah I know the report was from 1994. But it doesn't make sense to learn and use Haskell as if it's still 1994 and so that's not my argument. If anything, having the article be a top link on HN might convince someone to learn Haskell today, and that's what's relevant.

Totally agree on having people nearby that knew Haskell already.