> the constant changes that [...] cause regular breakages
Wow, for a language as mature as Haskell I find that surprising. I never really got into Haskell for other reasons, but this one warns me to stay away for the foreseeable future.
Leaving Haskell behind
101–110 of 402 posts
Re: Leaving Haskell behind
#102Earlier quoted context omitted.
If only Python would be able to really solve their dependency and backwards compatibility issues, those are really holding the adoption back. Though there is a good chance that even if they fixed those that people burned in the past will never go back into it.
> [python] backwards compatibility issues What issues? A lot of problems with Python is due to keeping compatibility with Python 2.0. Implicit string concat bites me fairly often for example, and it has never been useful.
2->3 has been a complete disaster, anything older than a few weeks tends to randomly break with some kind of dependency issue, sometimes requiring multiple installations of python on the same machine which will bite each other in hard to predict ways. Python is a wonderful idea but I've yet to be able to write something in python and call it 'finished' because it never ever continues to work in the longer term. Highly frustrating and in my opinion unnecessary.
Re: Leaving Haskell behind
#103Earlier quoted context omitted.
You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?
Fair enough, though I’ll note that only I’ve given an up-to-date reference.
Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions
Re: Leaving Haskell behind
#104Earlier quoted context omitted.
I wonder why this discussion about tooling does not include .NET languages or Swift, even if the first class tooling are IDEs such as Visual Studio or Xcode. Most probably because the open source world escapes big tech dependencies?
As much as I like Swift, the tooling has been and still is subpar. Swift package management is barely viable. You have to use Xcode. You can try other IDEs but LSP equivalent features are at the most basic level. Xcode is the kitchen sink of IDEs which has led to many negative opinions as it struggles under its own weight. Every other year there’s new UI for things like debugging which is fine but what would be reall…
this has been my experience as well. After being one of the five people who liked using Objective-C I was eager to have this new, incredible language to work with, and pushed to adopt it as soon as reasonable on all the codebases I worked with.
That enthusiasm has since waned when stuff happened like compilation times slowing to a crawl because somebody used ternaries extensively. I still think it's a great language, but the tooling really makes it hard to love
Re: Leaving Haskell behind
#105Earlier quoted context omitted.
> Basically, the author's criticism is that the language is too powerful, too expressive, people try very abstract things I think this is a bit unfair. The author's criticism is that people try very abstract things and don't stick the landing . And to an extent I agree, but the problem isn't that Haskell is too powerful, it's that it's just barely powerful enough for too many things. Contra the author, GADTs are not…
I think one of the problems that people who get overexcited about functional languages and all the strong typing and such have is that they generally start out in a bad place. Imperative programs with every flaw in the book, threading by locks, for loops that try to modify the index mid-loop, mutation running rampant, all the bad things they complain about. I've worked in those code bases in industrial contexts, they…
This is amazing! Thank you for writing it. Maybe you should write a blog or something.
Re: Leaving Haskell behind
#106As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter job offerings based on social utility rather than language stacks), I definitely agree with the author's first point: the Haskell community values learning extremely strongly. That's great because you work with curious people that have always something to teac…
> I simply wanted to filter job offerings based on social utility rather than language stacks I wish more people did that.
I think this happens with experience - I’ve recently done the same after spending years chasing languages to work in
Re: Leaving Haskell behind
#107Earlier quoted context omitted.
> Basically, the author's criticism is that the language is too powerful, too expressive, people try very abstract things I think this is a bit unfair. The author's criticism is that people try very abstract things and don't stick the landing . And to an extent I agree, but the problem isn't that Haskell is too powerful, it's that it's just barely powerful enough for too many things. Contra the author, GADTs are not…
I think one of the problems that people who get overexcited about functional languages and all the strong typing and such have is that they generally start out in a bad place. Imperative programs with every flaw in the book, threading by locks, for loops that try to modify the index mid-loop, mutation running rampant, all the bad things they complain about. I've worked in those code bases in industrial contexts, they…
I apologise for the comparison, as your thoughts are very well-structured, and in my head it almost sounds like an insult. But this kind of thinking ("more discipline minimises the problems related to suboptimal languages") is kind of like Uncle Bob's test-zealotry - i.e. you don't need static typing/AOP/linting/any kind of bug-reducing feature, because you can just write more tests (even if it's painful or spurious)
Sure, it is possible to be very disciplined, avoid messy control flow, be careful with mutation, etc.... then good luck trying to get everyone else to get on board with a very niche coding style, unless if you have the strict authority to enforce it. Sadly, in most cases you don't, so you are stuck with the non-verifiable madness.
In an ideal world, this would work - but in an ideal world, we would also be using better languages with way better guarantees and compile-time checks.
Re: Leaving Haskell behind
#108If you like Haskell but want something else, you really should consider Scala. It's not the same. But it has many of the same niceties around the rich type system, but with generally good tooling, the amazingly rich JVM ecosystem (tooling, libraries, learning materials), and a somewhat more pragmatic bent to it. Scala has a bad rep, justifiably so, due to a lot of its problems in the past: community, libraries, tools…
I find the issue is most of the niceties are also built into Rust.
Scala's perfectly good though, there's very little to complain about.
Re: Leaving Haskell behind
#109If I had to choose the three big factors that contributed to my gradual loss of interest in Haskell, they were these : * the stylistic neophilia that celebrates esoteric code but makes maintenance a chore * the awkward tooling that makes working with Haskell in a day-to-day sense clunkier * the constant changes that require sporadic but persistent attention and cause regular breakages Valid points. Back in 2010-2012,…
> Take Java, for instance. It has added features like Streams, functions, lambdas, algebraic data types, records, and pattern matching. In a doomed attempt to escape the prison in which they were locked, the inmates defiled their language and adopted grotesque rituals inspired by the light they saw through the bars of narrow windows. They created an endless pit of suffering of their own, which is made tolerable only…
Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language. For some, things like Kotlin hit a sweet-spot. One can lean a bit more into a functional style, or they can lean more into an OO style and it's acceptable. Some are very interested in thinking in terms of Functors, Applicatives, Readers, etc... some just want map/filter/reduce. That's what the Streams API did for Java devs. For me, Haskell isn't "the goal". It's simply one way of solving problem-sets.
Re: Leaving Haskell behind
#110Earlier quoted context omitted.
> Second, this is similar to the "equalise things by dragging everyone down to the same level"-type of thinking. > and not allowing for an opportunity to write really good code. Basically, enforced mediocrity. > straightforward, laziest, zero optimisation code, and giving themselves an excuse for that. > justify their laziness, Jesus christ you have so much disdain for such a large set of people. Have you ever consid…
> Sometimes I wonder if some language communities really are cults. It's the same with Lisp - replace "type system" with "homoiconic" and you have the exact same mantras about ultimate supremacy and "intellectual" superiority. But the proof of the pudding is in the eating and across probably 10 computing devices in my home, not a single one has any Haskell or Lisp programs running on it. Lots of Java, C, C++, Python,…
> xmonad
I got rid of xmonad in favor of i3 ages ago - precisely because it doesn't force me to edit a Haskell script just to change a keybinding. Obviously just my personal anecdote, but this 'feature' alone probably accounts for a significant % of users either jumping ship, or never boarding it in the first place.