Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

Post reply on HN
Print view View original

91–100 of 402 posts

Re: Leaving Haskell behind

#91

Post by pjmlp »

xmcqdpt2 wrote: post #63
alex_smart wrote: post #49

Earlier quoted context omitted.

What is wrong with Java's tooling?

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…

Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.

Re: Leaving Haskell behind

#92

Post by regularfry »

saurik wrote: post #71
regularfry wrote: post #30

Earlier quoted context omitted.

Cargo is an evolution of older ideas from Ruby's bundler, so in a sense it does have a longer pedigree than most other tools of that ilk. Bundler mostly doesn't suck. There are design choices I disagree with but there's a happy path to using it that gets a lot right. There are ways to do language tooling that don't suck. Without much direct experience of cargo I can't say whether that carries across, but I wouldn't b…

FWIW, the thing which really sucks about cargo is how it handles cross-compilation. Most "professional" workflows are always cross-compilation: even if you are technically on Linux already you don't want to build for the exact version you have so you create a sysroot and cross compile towards it... and cargo is somehow so bad at this that increasingly large numbers of projects are being forced to turn on a environmen…

Yeah, that tracks. That sort of cross-compiling isn't something you'd ever see in the Ruby world, as far as I can recall, so I guess it's a reversion to the mean.

Re: Leaving Haskell behind

#93

Post by pjmlp »

dkarl wrote: post #82
mberning wrote: post #27

Earlier 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.

Rightfully so, most of the alternatives are found lacking in feature parity.

Re: Leaving Haskell behind

#94

Post by harry8 »

pyrale wrote: post #24
pooya72 wrote: post #14

If 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…

yeah sure, maybe, but when I look at software i can install which has a purpose other than programming a computer there's a metric f.ton() written in Java (a language I don't like much) and we can count the items on our fingers written in haskell (a language I greatly prefer for aesthetic reasons).

Xmonad, pandoc and there are more. Let's list everything we can.

We can scream at anyone who points this out or face up to it and work out /why/ and how to actually /fix/ that issue.

When i mention it here it's about 50/50 which way it goes.

Re: Leaving Haskell behind

#95

Post by rowanG077 »

consilient wrote: post #79
rowanG077 wrote: post #67

Interesting. 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…

You should generally be writing code against typeclasses, not a particular monad transformer stack. For example: fibonacci :: MonadState (Int, Int, Int) m => m Int fibonacci = do (prev, prev2, n) 0 then put (prev + prev2, prev, n - 1) >> fibonacci else return prev2 concreteFib :: ReaderT String (StateT (Int, Int, Int) (ExceptT String Identity)) Int concreteFib = fibonacci

You misunderstand my problem. Add a logger to that fibonacci function. Potentially EVERY usage site now has to change, maybe even multiple layers. Adding a log in most languages is a local transformation. In Haskell it isn't, it can have codebase wide consequences.

Re: Leaving Haskell behind

#96

Post by chpatrick »

I recently went to one of the largest Haskell meetups in Europe and pretty much no one used Haskell any more (including some formerly core people), it was almost just a social gathering.

I think in 2023 many of the things that made Haskell appealing compared to other languages before have been widely adopted, while the developer experience and ecosystem for Haskell is as bad as it was. I wouldn't use it for a new project outside of some specific areas.

Re: Leaving Haskell behind

#97

Post by lihaoyi »

If 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, etc. But many of those past problems are much better today. Scala today is a much better platform than it was at peak-hype circa 2015, despite some ongoing warts. Nowhere near perfect, but pretty good overall

I see people in the comments looking for a "better OCaml" or a "industrial Haskell", those folks should definitey try Scala

Re: Leaving Haskell behind

#98

Post by consilient »

jerf wrote: post #76
consilient wrote: post #40

Earlier 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…

> And it is not perfect. You will still occasionally have the original imperative problems. But you will have radically, radically fewer of them, so few that the cost/benefit analysis of using the super-strong stuff becomes very difficult to justify, especially over the advantages of being able to use that library you really need.

This has unfortunately not been my experience. Working alone, sure, I can write acceptably pure code in a conventional language. But generally the issue isn't what I can do, it's what my coworkers will do. Even if almost everyone manages to maintain strict discipline without the support of the language, it really only takes one "productive" cowboy to create a disaster. The biggest advantage of pure functional programming is that taking the path of least resistance produces code that's still sort of ok.

Re: Leaving Haskell behind

#99

Post by boxed »

mymac wrote: post #28
pyrale wrote: post #20

As 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…

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.

Re: Leaving Haskell behind

#100

Post by Pannoniae »

runeks wrote: post #86
Pannoniae wrote: post #65

Earlier quoted context omitted.

Not creating something because people don't want to use it is really myopic thinking in my opinion. That's like not creating art because no one buys it. Deliberately aiming for something worse in hopes of public/industrial acceptance is not a good approach IMO.

> Deliberately aiming for something worse in hopes of public/industrial acceptance is not a good approach IMO. It's not "worse", it's a tradeoff between backwards compatibility and fixups. Backwards compatibility is a really useful feature in and of itself, and the question is whether this outweighs the usefulness of all the tiny fixups. In my opinion it mostly does.

I agree with you, it's a tradeoff. I definitely don't want to say that backwards compatibility is not important..... but when you have N other languages priding themselves on that, what is the value add in creating another stagnant but stable language like that?

I think the reason why this is not emphasised more is because breaking compatibility is a visible cost (program broke, time to investigate and fix it) while the pains from maintaining backwards compatibility is an invisible cost. (you can't easily quantify the wasted hours and extra bugs from unintuitive/broken language features) This is kind of a natural consequence of the incentives, so I understand why it happens. I'd be happier if it wouldn't.

Post reply on HN