Here's the thing: I am willing to accept that Haskell is the best programming language ever created. People have been telling me this for over 15 years now. And yet it seems like the most complex code written in Haskell is the Haskell compiler itself (and maybe some tooling around it). If Haskell's clear advantages really make that much of a difference, maybe its (very vocal) supporters should start doing really impressive things with it rather than write compilers. I don't know, write a really safe operating system; a novel database; some crazy Watson-like machine; a never-failing hardware controller. Otherwise, all of this is just talk.
I'm not sure what the cause is, but it definitely gnaws at me.
Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because their domain is the programming language, so they don't feel like they're spending their mind power on two different things. They can't imagine that someone trying to solve a tricky scheduling problem wouldn't want to spend time thinking about types.
The other group that can adopt languages like Haskell are those whose domain doesn't require too much thought: namely CRUD applications. These guys want to spend time thinking about type-driven-design. It might actually make their code quality better. They, too, can't understand why people solving a hard concurrent-data-structure problem wouldn't want to spend time thinking about expressing their ideas elegantly through types.
Both of these groups have one thing in common: expendable energy to spend thinking about programming language concepts. So to them, it seems easy; and it probably is, if you're willing to put some effort into it, which is precisely what many developers don't want to do.
Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).
Sometimes, I get so frustrated by how weird the syntax can get (the templates always confuse me to the point I have to stop and slowly read the code before I get its meaning)!
I find Ruby, C and Go really fun. The reason I get shit done is because they are so fun! I can't wait to do something else in them!
Also, the elegant utility library code that took four hours to write can—and likely will—be reused, and save you hours upon hours.
Meanwhile, the Java hacker will always have +1 hour of coding, because he never learns.
: I realise calling C fun is weird, but I enjoy writing C code, and it's my guilty pleasure, I guess.
Elisp gurus, in my experience, don't get all that much work done, other than writing lots of editor extensions. This is great if their job is writing editor extensions, less great if their job is something else. It's the same as with compiler writers: they're great at making other people more productive, but when it comes to writing end-user software, not so much. In general, of course - there are exceptions.
Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible.
Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.
Haskell seems to disseminate ideas rather than code. It even disseminated LINQ into C#.
Perhaps this makes the lack of volume of production Haskell code less stinging because it has contributed to languages in other ways?
There's kind of an upside to this as well, because Haskell isn't entrenched in industry, it's still free to make changes and grow the language (i.e. Applicative becomes superclass of Monad), although this gap may be starting to slowly close with the recent popularity.
But you see, this is the claim that requires substantial evidence. Let's assume we're in a mess. If Haskell is one way out of it, as some people claim, why won't they show us the way? They've had more than 20 years to do it. There are enough Haskell developers out there to give us this pesky evidence we need. And yet we've seen absolutely none. There are way more impressive BASIC programs out there than Haskell programs. I think that there are two reasons for that: 1) People involved in PL research are less interested in programs that aren't compilers, and 2) languages like Haskell make certain tradeoffs that their designers fail to see, and as a result their advantages fall way short of the claims they make.
My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA.
What exactly are you looking for? Web app frameworks? they exist. database connectors? they exist. mathematical proofs relating to correctness? they exist, in abundance. data structures arcane and common? they exist. regex libs? they exist. Sophisticated programs running sophisticated systems? They exist, and you won't hear about them except as a rumor on message boards...
If you mean, "is there going to be a big marketing campaign to make me and my manager feel comfortable"... I doubt it.
Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making a fortune by betting on Haskell?
I'm not willing to claim that Haskell is perfect, but I am willing to claim it is better. I'm also willing to claim that if it had anything resembling the community, say, C# has (to pick a random example) then it'd solve most of the problems you're highlighting here.
And it's getting that way. The number of programmers proficient in it and projects succeeding using it grow year over year.
But if you want to argue from a perfect world then you need to note reality will look different and search for trajectories that aim to approach your perfect world... not just current states which are far from it.
Absolutely. Which means that there are substantial switching cost, which a slight marginal improvement can't overcome. But if benefits are so immense, they should be able to. I think Haskell's supporters tend to overstate its advantages (and it certainly has plenty of those), and discount its disadvantages (and it's got plenty of those, too). All in all, Haskell is an extremely interesting and very good language, but it most certainly does not solve all or even most of the challenges of modern software development. It's good, it's very interesting, but it's not the second coming. I, for one, would take the JVMs monitoring and hot code swapping capabilities over Haskell's type safety, because those solve a bigger pain point for me.
Ultimately, choose the tools with tradeoffs beneficial to your goals, obviously. Engineering of any kind is nothing if not about understanding tradeoffs.
That all said, I do think there are upgrade paths for both technologies—JVM languages with better semantics and "ML-alike" implementations with better runtimes. I'd be more than happy to use either.
The reality is that most companies choose "fast+cheap" and usually incur significant technical debt which is paid off through throwing bodies at the problem. It is usually considered better to hire 3 people who are mediocre than 1 person who is very skilled. This is extremely well addressed in the software engineering literature going back to the late 60s.
It's also the case that software engineering is very conservative: "Don't change ANYTHING" is the default state of the industry with regards to practices.
Where is the redis of Haskell? The ffmpeg of ML? There's something else at play here.
e.g., I run a tutorial site for common lisp. One request has been for 'example of web framework'. At some point, I'll do it (it's useful), but my heart at the moment is in implementing an extensible indexing system for n-dimensional tuples. It's a good deal more esoteric and a lot more fun than screwing with http/html.
And this is why better languages fail: because language weenies have atypical minds, and can't comprehend why something marketed inappropriately to the mainstream never catches on as something mainstream.
This is also precisely why Java succeeded. This is also why LightTable finally got across what Smalltalkers had been raving about. It's really not only about who has the best tech or the best message. It's who has the best tech that can make itself understood.
- Elm's Time Travelling Debugger: http://debug.elm-lang.org/
- Pandoc: https://github.com/jgm/pandoc
- XMonad: http://xmonad.org/
- (GHC, should really count)
My theory is that it is because that is what we teach. If you go to school you learn Java (which is basically C#) and if you learn a language on your own most people recommend Java/C# because it will get you a job.
By extension we end up with the vast majority of coders knowing Java/C#, thus most code gets written that way.
Asking someone to switch to using a new paradigm—like moving from OOP to FP—is asking them to relearn how to structure a program. All those habits and instincts no longer apply and new ones need to be learned. It takes years to learn how to write good high-quality FP programs. I know I'm still learning and I first picked up Haskell as a primary hobby four years ago. It probably took me a year before I really understood what a monad was and could apply that abstraction, similar to how long it took me to really understand and apply things like visitor patterns.
I believe that if you took an entirely untrained person you could get them to be at least as productive if you taught them with FP versus OOP from the start.
Stuff that people are willing to pay for, which can be a very important concept for many (if not most) of us.
Wikipedia claims that there are over 200 billion (with a 'B') lines of COBOL in production. That further supports your point, of course.
There are lots of examples like this in Haskell, where you come to a point at which the abstractions provided to you don't work, mostly when the problem has more structure than you can hope to capture in the type system and some generic operations. In an imperative program it is much easier to "teach" or "tell" the computer what to do, when the compiler or language can not do it for you, whereas in a pure functional language you essentially have to give up at that point.
Not sure why there are so few other good examples to point to though.
It basically allows you to procedurally generate thumping dance music by live coding in a Haskell DSL in Emacs.
Which, given Haskell's rather academic reputation, is pretty damn cool.
On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by a base language. People seem to balk less at the idea of DSLs compared to the idea of powerful languages.
Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a significant break from a normal approach to OOP, and Clojure's distinctive concurrency constructs which are more complex than Go's. It's not that any one of these things is hard, but you have to know all of them. Unless you have Lisp, or Haskell (or similar) experience, the only one you're likely to know is the JVM, and even then, maybe not.
This isn't like C++ or Java which are huge languages with a lot to wrap your head around but at core simply reuse concepts that most programmers are familiar with, (OOP, basic types) It's the very things that make the language interesting to begin with that makes it trickier to pick up.
Most of this holds for Haskell, Erlang, etc.
Then again, real code is written in these languages, but they don't tend to dominate.
I've written Haskell, I've written Scheme, I picked up Go in a couple weeks, and learning a new functional language shouldn't take me more a few weeks. Nevertheless, if I were starting a project now, I would probably pick some combination of Python/Java/C++. Why? Because their library support & ecosystem far outweighs any productivity boosts I could get with Go, Node.js, Clojure, Erlang, Haskell, etc. And yeah, I know you can use Java classes with Scala/Clojure, but there's an impedance mismatch mapping the concepts and existing library structure onto a functional language that doesn't exist with Jython.