If you want to get things done, don't use Haskell. You'll be fighting against the type system constantly. You'll be asking questions on Stack Overflow only to get no response. You'll be rewriting software that's in other language's standard library. Productive programmers don't use Haskell.
Leaving Haskell behind
241–250 of 402 posts
Re: Leaving Haskell behind
#242Earlier quoted context omitted.
Maven or Gradle
I feel like Maven is doomed by its history. When Maven was created, expressing dependencies with version ranges was encouraged. But there was no lockfile concept, so that did not work well. Instead of adding lockfiles, they decided to leave the tool as it was but encourage people not to use dependency ranges. But dependency ranges are still supported, so you need a plugin to check your POM files and make sure you are…
Re: Leaving Haskell behind
#243Basically, the author's criticism is that the language is too powerful, too expressive, people try very abstract things, tooling is bad and no one cares about the language. There is something sinister in this - first, in the author's lamentations about bad tooling. Other languages require linters, formatters, static analysers, etc. because the language's built-in features and type system are sub-par. In Haskell, that…
> 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…
Haskell is successfully used in industry, in some cases with billions of users.
https://engineering.fb.com/2015/06/26/security/fighting-spam...
Re: Leaving Haskell behind
#244Re: Leaving Haskell behind
#245Haskell is a complex and a flexible language. It pushes you toward correctness, but in other dimensions is less opinionated than other languages. If you choose to stay away from the low-level Template Haskell (the types for it are updated often) and the bleeding edge type system tricks, Haskell would be quite stable.
The idea to use only the simple parts of Haskell is great - but what is simple is a rather subjective judgment. Oftentimes the technical choices would be made before the the impact on dev ux and effort to maintain becomes clear. Luckily, doing large refactoring in a complex Haskell project is safe, and improving over the initial choices is easier than in most other languages.
Re: Leaving Haskell behind
#246Earlier quoted context omitted.
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)…
I don't really get your point, other than trying to insult everyone. It's fairly well established that in the real world, strict functional programming languages aren't an option. So who really cares that you keep railing on about them? Until they're an actual option, we are not being "zealots" when we can't use them... not "refuse" to, can't ... and, yes, you're just being an insulting jerk with no real options to o…
This just isn't true.
We write essentially 100% Haskell where I work. All day, every day. Have done for years.
We have a "real world" business, with real customers, who pay real money.
Re: Leaving Haskell behind
#247As 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…
What is wrong with Java's tooling?
Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work, and hard to reason about in the sense of building a proof that it will always behave in the correct and intended way.
Re: Leaving Haskell behind
#248If 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…
Scala has mostly all the issues the post is discussing. Perhaps once you're on Scala 3 you're going to enjoy stability, but your dependencies most likely won't give you that. And the JVM, and compilation times, and poor Scala 3 support on editors / IDEs. I prefer the Haskell tooling TBH.
Re: Leaving Haskell behind
#249As 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've also used several languages and IMHO, Haskell's tooling is some of the worst. Language server breaks with random errors all the time for me, I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are), and so on. I have a project I work on from time to time, and I'm 100% sure that the next time I'll open it up, it will stop working again. Py…
Re: Leaving Haskell behind
#250Earlier quoted context omitted.
What is wrong with Java's tooling?
Maven is awfully slow and awfully stateful (plugins or multiple executions interfering with each other), has too many quirks, and documentation is lacking. Gradle is imperative and also stateful. Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work, and hard to reason about in the sense of building a proof that it will always behave in the…