That.. is mostly the case for innovative concepts at some point before they get adopted. At some point some years ago you could write a lengthy and passionate article about React or Typescript and discuss why it would be so advantageous and most front end developers would feel lost.

Good ideas aren't necessarily easy to comprehend. In order for them to work for a wider audience someone need to properly package, document and maybe simplify them for it to work for them.

I agree. But the headline was not referring to a concept (Dependent Types) but specifically to "Dependent Haskell" as the future of software development. Making it sound like we all are going to be Haskell programmers in the future.

I think I can rephrase my opinion for either the language or concept and still agree with it. I believe Haskell has continuously become more developer friendly and may some time reach some kind of friendliness and use case support threshold that allows for a wider adoption.

I recently started looking at Haskell a couple of weeks ago after years of hiatus. The IDE support have gone from almost none-existing and/or bug ridden to almost as good as Java and the new package manager has so far been pleasant to use. Although I'm using it for small side projects so it might not be fair comparison to my day work use case.

This is probably because it's about cutting edge language design. The feature the article is about (dependent types) might well be the future of software development and could end up in every strongly typed language, but because it's new and Haskell's functional syntax looks weird compared to C-based languages, it makes the headline sound a bit hyperbolic.

I wouldn't disagree that dependent types are great for certain specialised problem domains, but they've already been around for ages and didn't yet revolutionise the world of software design. I think the sentiment that this is unlikely to make a big splash is totally on point. Languages have to balance ease of use with features in order to become very popular. Nothing as purebred as Haskell is likely to become the next Python or Visual Basic. Real work horses are dirty, messy machines. Of course this new feature might turn out to be popular for Haskell users.

>but they've already been around for ages and didn't yet revolutionise the world of software design.

I think it's mostly because languages with dependent types are awfully clunky to use. Perhaps dependent typing is even a dead end, but I wouldn't count out other ideas such as refinement typing just yet. I think it will take a lot of work and failed attempts (such as typestate in early Rust) to get fancy type theory into mainstream languages (just like it took a while for Java to get lambdas).

Case in point: static analysis tools for C++ are getting more capable and popular recently.

Formal methods in general are extremely clunky to use. Just see how much hate Rust gets for making it extremely difficult to make an intrusive linked list. And memory safety is only one kind of correctness assertion.

So I'm gonna be a pessimist here and say: nope, not gonna be the future, because programmers are lazy and "ship it now" is better than "prove the bugs don't exist".

Not all programmers build WordPress plugins.

Some programmers write software for aircraft. The "ship it now" maxim doesn't exist in that context.

No one is writing aircraft software in Haskell. They need good control over memory usage.

Counter-example: https://smaccmpilot.org/software/index.html

Also, a Haskell DSL for automotive control systems: http://tomahawkins.org/

That isn't a counter-example unless you're taking his post literally. In which case I claim that Python is a system programming language because one time somebody somewhere wrote a driver in it.

Well... for 95-99%[1] of all software being written, "ship it now" beats "prove that bugs don't exist". Better formal methods could really help that 1-5%, but they're not going to impact the 95% very much.

[1] All statistics made up on the spot. I think it's in the right ballpark, though.

The cpp static analysis tools are all wildly unsound. This is a core design principle behind all real world deployable static analysis systems, whether they are based on abstract interpretation or model checking or symbolic execution, or anything else.

Static analysis is a powerful technique. But sound formal methods have been failing to make a splash for nearly five decades.

Honestly, I'd be happy with a language that can propagate the result of a conditional statement into compile-time constraints inside the branches, and also can create executables without jumping through 20 hoops.

The thing about Haskell is you shouldn’t consider it a finished product. Yes, there are people using it and their experience is invaluable, but it’s also a huge research project into what a programming language could look like. It isn’t mainstream ready yet, but you can see the future come into view.

On the other hand, even those messy real work horses have been adopting functional programming features at a rapid pace over the past decade or two. And many of those features originate from Haskell.

> and didn't yet revolutionise the world of software design

Well, they have. There's a reason why the companies who have adopted these technologies have adopted them.

The future is here, it's just not evenly distributed.

But why dependent types and not one of the many other formal methods that have been around for decades? Especially given the trend towards compilation speed being a relevant design choice (e.g., golang).

Sound global formal verification largely sucks. Type checking is about as far as we've ever gotten using it for widespread real world applications, and most type checkers in major languages are only "sound-y".

> 0.1-0.2%

FTFY! :D

I remember going to a happy hour at a large consulting company I worked for and 95% of people had never heard of Haskell much less knew anything about it. So needless to say I was easily pulled away from that company when the next person I interviewed with had written production Haskell code.

I find this to be odd. Haskell seems to be the one language where recruiters lead with "we program in Haskell here" before saying what the company does.

Do people really choose companies based on the language they are using?

"We Program in COBOL!"

(Walks away slowly avoiding eye contact)

A bit less facs- fascatio- fesceeshus- silly, companies that aren't smart enough to invest in good tools probably aren't smart enough to invest in good people. You can overdo the tech worship, but you can totally underdo it and cost yourself a bomb.

At some point, money is no longer an issue (or falls into diminishing returns), and I'd even take some amount of a pay cut if it meant working in a language and on projects that were mentally stimulating

But even this is odd to me.

Programming seems to be the easy part. The hard (and stimulating part) is everything around that. If somebody says that they work in Haskell but doesn't say what they are working on then I'll just be confused.

To me, it is like selling a company based on where you put the curly braces (a slight exaggeration here).

Haskell is less of a programming language and more of a religion, so people choosing companies based on their religion makes sense.