3 ms·

Maybe it already is. That doesn't mean it would happen. People do not genuinely optimize for what they want, they tend to optimize for what they want given what

by tel 13y ago

Maybe it already is. That doesn't mean it would happen. People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. 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.

pron 13y ago
> People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. 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.
- tel 13y ago
  I think Haskell has, of late, entered into the echo chamber a bit and been dressed up as much more than it is. I believe Haskell has a cleanliness of semantics which makes it rich, but I don't believe that it has the best RTS at all. My understanding (via Scala, an experiment) is that it's difficult to embed these semantics into the JVM. 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.

by tel 13y ago

pron 13y ago

> People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. 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.

tel 13y ago
I think Haskell has, of late, entered into the echo chamber a bit and been dressed up as much more than it is. I believe Haskell has a cleanliness of semantics which makes it rich, but I don't believe that it has the best RTS at all. My understanding (via Scala, an experiment) is that it's difficult to embed these semantics into the JVM. 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.