You don't need to know the author personally to appreciate the result of their work...
> Gosh, what am I doing with my life?
I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways!
Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.
Strange. In my experience Haskell is the best language for long-term maintainability! I can actually come back to code I've written years ago and understand what it does. I've never experience that with another language.
This is not really what maintainability means to me. To me, it just means you have a good memory.
To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.
Haskell scores poorly on any of those points.
It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday".
"Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work.
Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.
> To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.
> Haskell scores poorly on any of those points
Interesting. I work at a company with over a hundred people committing to a Haskell code-base that runs our entire back-end. As far as I can tell we're continuously shipping code several times a day, every day, with very low impact on our service level indicators.
When we do have production issues they're rarely attributed to Haskell. I can think of one incident in 3 years where a space leak was caught in production. It was straight forward to address and fix before it impacted customers.
In practice, Haskell has been amazing to work with. I just rewrote over a thousand lines of code and shipped that to production without incident. I've never had that go off easily in any other language I've worked with (and I've been around for over twenty years and worked in everything from C, C++, Python, and JS).
I worked for a company that had a product with several million lines of C, couple hundreds of lines of Java, same for Go, Ruby and Python.
And it worked great! And you know why? -- The programmers were skilled at what they were doing. There were about 60 employees in total, and they managed a relatively big codebase for a complicated product (distributed filesystem). Btw, our build system was written in Haskell.
And why do I mention this? -- because I also worked in many other companies, who used all the same languages, typically for much smaller codebases compared to the number of people working on them. And the effects were usually awful.
In conclusion: the choice of language doesn't define the outcome. You may be successful choosing a bad language if you hire good programmers and other stars align to make it happen. You can also easily fail if you use a good language, but other, more important conditions don't hold.
Your individual success is at best an indication that it's possible to use Haskell to achieve your goals. It doesn't mean it's a good tool. You didn't even try to have a test that'd compare Haskell to other languages, you don't have any explanation for why Haskell is good for your case. It just worked "somehow".
What I say, I saw from a more general perspective, and with some justification. But if you need examples rather than justification: at one point in the past, Japanese high-schools used Haskell to teach computer science. I was able to compare the experience to Basic and Pascal which I experienced personally. In the hands of a mediocre-bad programmer Haskell is an awful tool and produces far worse results than Basic or Pascal. And, surprise, most programmers in the world are mediocre-bad. You cannot take your example and extrapolate from it that if everyone used Haskell software would've been better. In fact, there's every indication it wouldn't. In most likelyhood it'd be a lot worse.
I’ve been in this industry for over twenty years. I’ve written a fair share of code in other languages. There’s not enough empirical evidence to suggest that one language is better than any other.
My example is only a counter argument that Haskell isn’t suitable because of the reasons you stated. Clearly it can be maintained, work can be split among groups, and delivered with reasonable efficiency… like a lot of software can be in other languages.
I don't know what to tell you. I've been successfully using Haskell in production for over ten years, and it's the most maintainable language I've used for a variety of reasons, including the one given in my message above.
Real world in this contexts contrasts the world of programs that nobody needs or uses. Programs that are written for amusement or with no stringent requirements.
> Gosh, what am I doing with my life?
I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways!
Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.