> Why Dependent Haskell Is the Future of Software Development
I find this hard to believe, considering probably less then 1-2% of developers in the world have any clue to what this article is about.
I find this hard to believe, considering probably less then 1-2% of developers in the world have any clue to what this article is about.
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 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.
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.
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".
Some programmers write software for aircraft. The "ship it now" maxim doesn't exist in that context.
Also, a Haskell DSL for automotive control systems: http://tomahawkins.org/
[1] All statistics made up on the spot. I think it's in the right ballpark, though.
Static analysis is a powerful technique. But sound formal methods have been failing to make a splash for nearly five decades.
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.
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".
FTFY! :D
Do people really choose companies based on the language they are using?
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).
(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.