3 ms·

> What I think Haskell does attract are people that like to develop overwrought, abstract, and ornate systems. Haha. I'm laughing in move semantics. C++, Perl

> What I think Haskell does attract are people that like to develop overwrought, abstract, and ornate systems. Haha. I'm laughing in move semantics. C++, Perl, Python, Go, Java -- literally any programming language that some group of people somewhere has grown to a large enough scale is full of complexity. Go is supposed to be "simple" but there is nothing simple about k8s by virtue of being written in Go. Don't mistake Haskell's jargon, idioms, and ideas for your wilful ignorance. There are a lot of good ideas in Haskell that could benefit most programmers if they took the time to learn them. There's a fast concurrent run-time and great primitives for working with software transactional memory, a fast and advanced type system to help you get feedback on your program interactively and reject more poorly formed programs, immutable data structures and rules for composing them that enable distributing computations safely while making code much easier to manage. There is a lot going on here and it has been slowly adopted into other language ecosystems for decades for a reason. I understand it's often more work than folks are willing to invest but that's no reason to be so dismissive.

nostrebored 5y ago
An abstraction in a pragmatic field like engineering is only as good as its utility. Haskell is unapproachable, and its abstractions are complex. More complex than most engineers actually need. From a utility perspective, these abstractions are bad.
- agentultra 5y ago
  Honestly I spent enough time to dig into Haskell to learn it well enough to make an informed criticism of the language. I ended up sticking around. I understand there's plenty of jargon and terms that are unfamiliar to a lot of folks but they're not unapproachable or complex (usually). People commonly point to weird words like, "Functor," or, "Monad." It seems insurmountable and complex but if you really dig in and learn what they mean it's infuriatingly simple and practical. I hardly even notice when I'm using them but I can see the pattern in software everywhere (or where they leak because they don't use them). Our job is abstraction. And good abstractions matter. There's a reason most software these days isn't written in machine language or assembly. And there's a reason why it's incredibly difficult to verify, say the security properties, of software systems in assembly; we use higher-level languages for that work. Update: The kind of complexity that is bad in my opinion is the incidental kind that is beyond your control. Move semantics and object initializers are an example of a language abstraction that leaks a lot. It's incredibly hard to write a class that works well in all cases and you have to know a lot about what's happening under the abstraction layer in order to avoid the pitfalls of using them. This kind of complexity is everywhere in software, even Haskell in some places. The blast radius for this kind of complexity has been well managed in Haskell though. So it often comes down to what you need. In my experience using Haskell has let me spend less time working on errors/bugs (no use after free, off-by-ones, no unhandled cases, I can even avoid a lot of threading and shared state issues) and more time focusing on the problems I"m trying to solve.

nostrebored 5y ago

An abstraction in a pragmatic field like engineering is only as good as its utility. Haskell is unapproachable, and its abstractions are complex. More complex than most engineers actually need. From a utility perspective, these abstractions are bad.

agentultra 5y ago
Honestly I spent enough time to dig into Haskell to learn it well enough to make an informed criticism of the language. I ended up sticking around. I understand there's plenty of jargon and terms that are unfamiliar to a lot of folks but they're not unapproachable or complex (usually). People commonly point to weird words like, "Functor," or, "Monad." It seems insurmountable and complex but if you really dig in and learn what they mean it's infuriatingly simple and practical. I hardly even notice when I'm using them but I can see the pattern in software everywhere (or where they leak because they don't use them). Our job is abstraction. And good abstractions matter. There's a reason most software these days isn't written in machine language or assembly. And there's a reason why it's incredibly difficult to verify, say the security properties, of software systems in assembly; we use higher-level languages for that work. Update: The kind of complexity that is bad in my opinion is the incidental kind that is beyond your control. Move semantics and object initializers are an example of a language abstraction that leaks a lot. It's incredibly hard to write a class that works well in all cases and you have to know a lot about what's happening under the abstraction layer in order to avoid the pitfalls of using them. This kind of complexity is everywhere in software, even Haskell in some places. The blast radius for this kind of complexity has been well managed in Haskell though. So it often comes down to what you need. In my experience using Haskell has let me spend less time working on errors/bugs (no use after free, off-by-ones, no unhandled cases, I can even avoid a lot of threading and shared state issues) and more time focusing on the problems I"m trying to solve.