Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

61–70 of 402 posts

Re: Leaving Haskell behind

#61

Basically, 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…

Some programs live for decades. Some programs get worked on after the original authors are gone. Code is written once, but (if the program is worth keeping) read many times. Optimizing for "easy to write" is optimizing the 10% and ignoring the 90%. Optimizing for "easy to read and understand by someone who is not the original author" is critical for important, long-lived programs.

It's not "laziness". It's understanding that maintaining software long-term is a really significant problem.

Re: Leaving Haskell behind

#62
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,…

I mis-read that as "stylistic necrophilia", which... rather changed the meaning.

Re: Leaving Haskell behind

#63
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…

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/reference/publishing.html

or even the pip equivalent.

Granted, working on a well set up java project is nice, but the setup process is not simple.

Re: Leaving Haskell behind

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

Re: Leaving Haskell behind

#65
post #31

Earlier quoted context omitted.

Sure, it might help with industrial adoption, but the more you commit to backward compatibility, the more mediocre your language becomes. (You can't really adapt new things if you have to keep everything around.) What's the point in creating the N+1th generic blub language?

What's the point of creating a language that isn't used? If the goal of the language is to academically research new programming techniques, then fine. Other languages will eventually adopt some of the more useful ideas and industry development will improve because of it.

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.

Re: Leaving Haskell behind

#66

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 miss early return dearly, and understand why it isn’t a thing (except if you have a MonadZero at hand) but I know it’s a syntactic transformation that won’t make it in.

Early return is mandatory for readability sometimes. I suggest using ExceptT for this: https://www.stackage.org/haddock/lts-21.8/mtl-2.2.2/Control-....

You don’t even have to expose ExceptT in your interface; you can just use it internally for early return and have your function return an Either.

Re: Leaving Haskell behind

#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 alleviate this somewhat, so I hope to try this in the future. But holy shit is working with monads annoying.

Re: Leaving Haskell behind

#68
post #42
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…

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?

That's simply because I talk about my personal experience, and there's only so many languages you can experience professionally over a few years.

Re: Leaving Haskell behind

#69
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…

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…

All I know about Ruby is that I always seem to download three versions of documentation

Re: Leaving Haskell behind

#70
post #42
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…

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?

Linux
Post reply on HN