Comment by agentultra
14 days ago
You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell?
I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages.
> This makes no sense, and is, in fact, very harmful when writing real-world programs,
Gosh, what am I doing with my life? I must have made up all those programs I wrote on my stream, the ones I use to maintain my website, and all the boring line-of-business code I write at work. /s
In all seriousness, Haskell has its warts, but being impractical isn't one of them. To some purists the committee has been overly pragmatic with the design of the language. As far as functional programming languages go it's pretty hairy. You have "pure" functions in the base libraries that can throw runtime exceptions when given the wrong values for their arguments (ie: the infamous head function). Bottom, a special kind of null value, is a member of every type. There exist functions to escape the type system entirely that are used with some frequency to make things work. The committee has gone back more than once to reshape the type-class hierarchy much to the chagrin of the community of maintainers who had to manually patch old code or risk having it not longer compile on new versions of the base libraries. These are all hairy, pragmatic trade-offs the language and ecosystem designers and maintainers have had to make... because people write software using this language to solve problems they have and they have to maintain these systems.
[0] https://www.microsoft.com/en-us/research/wp-content/uploads/...
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.
4 replies →
I think we can drop the "real-world," qualifier as it is unlikely there is an "imaginary-world" that we write programs for.
What engineering merits did you have in mind?
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.
> it is unlikely there is an "imaginary-world" that we write programs for
I think academia is typically what's meant as an imaginary world, along with play that may be in reference to no world at all.