It seems to me that the stewards and maintainers of the language actually _intend_ for Haskell to be friendly to research, experimentation and academic pursuit. That is fine, as far as it goes, but obviously this will, at some point, be at odds with the interests of programmers looking to use Haskell as a practical, stable tool. It sounds to me like what is needed is the ability to mark all the experimental, envelope-pushing bleeding edge stuff to a different track (whether through pragmas or even a package level declaration) so that programmers know just by looking at the package whether it's something they want to pull in. This would allow practically-minded developers to adopt a policy along the lines of "we only use Haskell stable" or whatever it'd be called. The dynamic I'm describing is the "Avoid success at all costs" phrase, right? The idea being that if Haskell adoption gets "too high" then the language will become inertial and be unable to continue pushing bleeding edge concepts. What I'm proposing is a way to allow that to happen but also maintain a separate track at the level of the language stewardship that formally acknowledges and recognizes that day-to-day programmers need some way to opt out of some of the edgier stuff and to stay within a more limited subset of stable Haskell.
Leaving Haskell behind
141–150 of 402 posts
Re: Leaving Haskell behind
#142It's strange that under any article like this, there's always commentary along the lines of "Hmm, yes, indeed $LANG is bad. What shall we all migrate to instead?"
Reminder that this post represents one person's opinion.
Haskell is still just fine as a programming language for getting actual work done.
Re: Leaving Haskell behind
#143Earlier quoted context omitted.
What is wrong with Java's tooling?
If you ask for my personal experience: - The community leans a lot on configuration over code, and that's annoying. Sometimes, a hardcoded string in your conf could have been a hardcoded string directly in the code. - Sometimes, dependency injection systems are so abstract that knowing which class is depended on in a specific runtime instance becomes a pain in the ass. - Your idea just won't load class x, the obvious…
I agree with some of that criticism (although I haven't had issues with having to manually delete files - if you do, I suspect it's a project that hasn't been set up with a proper maven/gradle setup but where all the build info is in some IDE config. that's an antipattern at this point but used to be very common).
But I don't think it's necessarily about the tooling.
And yes, Hibernate is just horrible.
Re: Leaving Haskell behind
#144Earlier quoted context omitted.
Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/refer…
I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially…
> there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix)
Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time.
That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.
Re: Leaving Haskell behind
#145> 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.
Haskell's motto is "avoid success at all costs", and part of this is making these kinds of backwards incompatible changes to clean things up.
Re: Leaving Haskell behind
#146As 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…
I expect that now that things are settling down around pyproject.yaml, Python's tooling will settle down. I've been settling on Hatch for most projects rather than using Poetry these days and Flit for smaller projects. It's managing to replace the mess of makefiles and shell scripts I used to have and supports standardised metadata. These days, I mostly use a combination of hatch, pip-tools (mostly when I'm dealing with lambdas and Django projects), and pipx whenever I'm doing anything with Python. it's not perfect yet, but it's much improved. The new pip dependency resolver still has its issues though if you haven't clamped your dependencies sufficiently and its solver can get caught in loops of excessive backtracking. Hopefully that'll improve too. pyenv is still somewhat hit-and-miss though.
What's really surprised me lately is how much better OCaml's opam tool has gotten! Last time I was using OCaml in anger, the experience was very, very clunky, but these days it's quite smooth.
Re: Leaving Haskell behind
#147Interesting. I use Haskell professionally and this article doesn't touch on the most fundamental problem I have with Haskell at all: Function coloring. Basically every monad transformer is different. Just calling basic function from somewhere else can involve lifting. Refactoring is a total pain. Oh you just want to log here but your concrete monad doesn't have a logger? Too bad... I understand an effect system allev…
In the general case, adding IO to any piece of code requires changing all callers. I would argue that it's a feature, not a bug: now `f x` is no longer a value, but an action: calling it twice can result in duplicated logs, for example.
If you need that logging for debugging then you should use `Debug.trace` though.
Re: Leaving Haskell behind
#148Earlier quoted context omitted.
Which requires sweeping changes... In most other languages it's literally a one liner where you want to log something.
It requires changing the places where you instantiate your monad transformer stack, which you should have very few of.
I don't think having very few is a good scenario. I have written a compiler and had about 10 different stacks. Changing every single one just to be able to add a logger to a single function somewhere is honestly insane.
What I see in the wild is having one huge kitchen sink stack which sucks as well.
Re: Leaving Haskell behind
#149I want to seriously invest some time into properly learn a functional language. My goals are simple- write small scripts, solve programming problems in sites like Codewars, Leetcode, Euler Program, etc. And yes, having the "functional enlightenment" or something similar. Which language should I learn and invest time into? Scala, Clojure, Haskell, OCaml?
Learn Haskell, it's the most elegant, and if you're using it for LeetCode / project euler you can have the experience of polishing a simple elegant program until it shines. It's a very satisfying experience.
Also, Haskell is lazy, which is fun and very different from other languages you'll use.
If you become a Haskell afficionado, it also kind of acts as a secret handshake in interviews. Like, you aren't going to be programming in Haskell here, but "you get it"
Re: Leaving Haskell behind
#150Earlier quoted context omitted.
I’m a bit incredulous that Java’s tooling is in the “sucks” category. You could say a lot of negative things about Java, but the tools available freely and commercially are in a league of their own.
What Java build tool would you say does dependency management decently? Most people are still using Maven or Gradle.
Depends on what you call "decently". Maven and Gradle do the job, but the bigger problem is the ecosystem:
Libraries don't declare version ranges for their transitive dependencies (like they do e.g. in Ruby), instead they just depend on a specific version. Of course, because two different libraries may depend on the same subdependency but in different versions, you will just get one version and you have no way of knowing whether it will work correctly.
That isn't a problem in 90% of cases, but sometimes it is and you'll notice it when you're suddenly getting ClassNotFound exceptions.
There are some solutions to this, e.g. bigger frameworks like Spring publish BOMs, which are just sets of library versions known to work together, but they don't cover everything.