Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

391–400 of 402 posts

Re: Leaving Haskell behind

#391
Haskell continues to punch above its weight in divisiveness. When was the last time you saw an article hating on F#, OCaml or some lisp get this kind of attention?

Haskell hate has an distinguished history. In the 2000s OCaml was "winning" in FP-for-production-apps land, which for no good reason resulted in an outpouring of vitriol for Haskell.

Steve Yegge's joke article comes right at the inflection where Haskell "grows up" and starts offering compelling advantages for production apps, but nobody knows it yet.

The 2010s see real adoption and fervor but no drop in click-grabbing haskell hate. If anything it increases, although the OCaml community buries the hatchet.

So it almost warms my heart to see this still getting attention in the 2020s. Switching to Haskell a decade ago changed my life for the better in every way, so I'd of course rather see Haskell love climbing the charts. But this trend instead supports the thesis that Haskell has "stayed weird", which is probably a good thing.

Re: Leaving Haskell behind

#392
post #84

> The way that Haskell-the-language evolves — well, the way that GHC evolves, which is de facto Haskell since it's the only reasonable public implementation — is that it gradually moves to correct its past missteps and inconsistencies even in pretty fundamental parts of the language or standard libraries. I would say that the biggest problem is that GHC is tied to a particular version of base (the standard library).…

Indeed, as you note, a reinstallable base is a goal everyone wants. Its basically historical reasons and coupling of primitives (tied to the compiler innards) to nonprimitives which has caused this situation, but sufficient elbow grease should improve things.

Re: Leaving Haskell behind

#393
post #247

Earlier quoted context omitted.

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…

> Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work I don't quite get the criticism against annotations. Metaprogramming and code as data seem to get a lot of love in the context of lisp, python or ruby, but a lot of hate when it happens to be done in Java. I absolutely love the powers that reflection, annotations etc give me. The diffic…

> Just run the code in the debugger.

How do you set a breakpoint on an annotation? You can’t, and that’s the issue. You can’t reason about annotations in the precise way you can reason about library calls.

Re: Leaving Haskell behind

#394

Earlier quoted context omitted.

Having developed Haskell professionally for many years, I've spent the last two years programming OCaml professionally. I've been really enjoying the OCaml tooling: dune, Merlin and ocamlformat work extremely well for me. Dune especially is packed full of features, for example a file-watch mode for tests. Merlin doesn't choke on large codebases like some of the Haskell tooling did and ocamlformat works better than an…

I have to agree so much. Been following for years, and started new experiments this week. It all worked so well. dune init … opam install some tools like lsp restart vscode dune build --watch and I’m good to go. Edit: adding some counterpoints and issues to level the field (but are being worked on) 1. dune/opam - wish they were one thing. I can still install packages with dune, and a package lock file exists for dete…

1. I agree. And this is being worked on, in the future dune will take on more package management tasks.

2. Agree, YAML has decisively won the config format wars. But dune it's extremely unlikely that dune will change this, and we can at least tell ourselves that s-exprs are pretty cool after all.

3. Yup, I hope Eio becomes the de facto standard in the future.

Re: Leaving Haskell behind

#395
post #387

Earlier quoted context omitted.

The maven surefire plugin downloads dependencies dynamically depending on the kind of tests it finds. Is it not very clever? I agree. But it's one of the most popular maven plugins.

During Maven build, sure. But it does not add unknown dependencies to your code at runtime. I am used to classpath problems with surefire but that it downloads undeclared stuff is new to me. Afair it pulls only in transitive dependencies. Could you give an example? I am mainly building war files and it turned out to be good practice to explicitely declare any ambigous transitive dependencies. There's even a Maven plu…

"Runtime" was imprecise, I meant at build execution time. The point being that you can't pre-download the dependencies without executing the build.

Re: Leaving Haskell behind

#396
post #302
post #64

I have been using Scala. I have found that it can give you the best of both worlds. You can reason algebraically, and often after a refactor, if it compiles, it works. Type inference and monads works great too. You also get to benefit from being in the java ecosystem. In instances where it gets too esoteric, I can break rules and code more like java. I am curious what others think.

I have really enjoyed Scala for the same reasons. Has some escape hatches if needed, and a large ecosystem. sbt drives me insane though, and is probably my least favorite part of the development experience.

Opposite experience with sbt here. It’s been much more useful than Maven or Gradle. Only fewer plug-ins than Gradle.

Re: Leaving Haskell behind

#397

Many of these reasons are why I moved to F# and haven't looked back (much). I sometimes miss Higher Kinded Types, but F# still has generics and if I'm being honest it forces me to write even simpler code then I would have in Haskell. I generally prefer this outcome. However F# never feels "leet" like Haskell does. It's like Haskell, but all business. I get a lot done in F# and really enjoy it, but I'll catch myself l…

I'm glad to read this. I'm new to FP and enjoying F#. Because it's terse and down to business. I've often wondered if I'm missing out by not using Haskell. It seems, for my purposes, probably not.

Re: Leaving Haskell behind

#398
post #60

This really resonates with me. I’ve been using it in a decidedly industrial application for about 1.5 years now. I had some fairly significant experience with it prior ( https://github.com/mattgreen/hython ). For the first time in a long time (20 years experience) I’ve needed to learn a significant amount of things. It’s a combo of the domain and the language. It’s rather exhilarating, and also exhausting. Could also…

> I’m still thirsty for a PL that is essentially OCaml but with a better syntax. But that’s just me. Not just you, me too! In fact it’s why I went in deep on Reason when it arrived initially. Shame it never really got traction.

Wish I had the capacity of time and energy to create this dream language of mine too.

Roc lang seems to be building up to what I desire. But we shall see. At the end of the day, picking one of the mainstream runtimes ids the safest bet. F# if we want to enjoy some fun but stay pragmatic.

Re: Leaving Haskell behind

#399
post #294
post #272

Earlier quoted context omitted.

When writing a compiler it helps for sure. Though most of my time is protobuf in Java, I still wouldn't mind having an ADT or two for when I got lists of things and the things aren't exactly uniform but I don't want to make a type hierarchy.

Doesn't `sealed trait ... permits ...` and `record` satisfy that these days for Java? That's what our proto2 `oneof`s generate into.

> I don't want to make a type hierarchy

Yeah I could emulate it, but it's much more verbose, and the signal to noise ratio is bad. Ex, a four line Haskell ADT could be 40 to 100 lines of java, and you gotta think things through a bit more. Instead I might have two fields which are Optional and specify an invariant in the comments.

Re: Leaving Haskell behind

#400

Earlier quoted context omitted.

Typed lisp? Unlike Lisp, Haskell has enormously complex syntax, so generating code in it is a huge hassle. Template Haskell is something to use only when absolutely necessary, while Lispers write macros without a second thought. I considered your method of writing my own tooling, but have had a vague feeling that Lisp works better for this frame of mind.

Haskell has almost no syntax, even `$` is a userland function. Are you arguing against the feature of allowing ad-hoc infix operators in userland?

"almost no syntax" is, I suppose, a matter of opinion. I wouldn't consider these sections from the Haskell 2010 Report to have "almost no syntax."

https://www.haskell.org/onlinereport/haskell2010/haskellch3....

https://www.haskell.org/onlinereport/haskell2010/haskellch4....

https://www.haskell.org/onlinereport/haskell2010/haskellch5....

Dealing with this in Template Haskell is unwieldy at best.

Post reply on HN