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

81–90 of 402 posts

Re: Leaving Haskell behind

#81

Post by Tainnor »

bradrn wrote: post #73
Tainnor wrote: post #23

Earlier quoted context omitted.

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'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are) There was a long and drawn-out transition, but these days it’s quite simple: use GHCup to manage your tooling, and Cabal to manage your packages. At one point Stack was the best option, but no longer: it’s not as well maintained, and is missing a lot of features (see e.g. https://disco…

You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?

Re: Leaving Haskell behind

#82

Post by dkarl »

mberning wrote: post #27
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…

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.

Re: Leaving Haskell behind

#83

Post by bluk »

wslh wrote: post #42
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…

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?

As much as I like Swift, the tooling has been and still is subpar. Swift package management is barely viable.

You have to use Xcode. You can try other IDEs but LSP equivalent features are at the most basic level. Xcode is the kitchen sink of IDEs which has led to many negative opinions as it struggles under its own weight. Every other year there’s new UI for things like debugging which is fine but what would be really nice is if the actual debugging worked. Technically there are reasons why you can’t print a local variable sometimes when stepping through a program, but in practice, I do not care and I want to know what the value is.

If you don’t care about the “optional” tooling like the dependency manager and LSP or a linter (which is closer to ESLint versus Rust Analyzer), the required tooling leaves much to be desired. The compiler sometimes gives up when it takes too much time to process a complex type. It would be understandable in some cases but most people encounter the problem when just writing seemingly simple SwiftUI. Error messages and auto fix-it suggestions are improving but still disappointing. I remember when Apple switched from GCC to LLVM and everyone was praising the error messages as a reason to switch.

Swift is actually ambitious. The generics system is world class. It has to support the legacy of a huge ecosystem on multiple platforms. SwiftUI is one of those bets that you might be surprised that Apple can still make. But whenever I fire up that SwiftUI Preview, I am crossing my fingers that maybe I’ll see something instead of an error. Swift lives up to its name in terms of moving quickly and the language design is probably fine, but outside of that, the tooling is still very immature for a decade old language which tons of resources are invested in.

Re: Leaving Haskell behind

#84

Post by runeks »

> 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). So when changes are made to base, and a new version of GHC comes out that supports only this and not earlier versions, you're forced to change basically all of your dependencies, if you want to use this newer GHC version, as they all depend on base.

I still don't understand why this is necessary. Why must code compiled with GHC 9.6 use base version 4.18.0.0? Why should the binary that is GHC care about which version of the Data.List module the code that it compiles uses? I understand that all the GHC-specific stuff exposed by base is tied to a particular GHC version, but why all the rest?

There is, however, work in progress to split base into multiple packages to fix this (as I understand it): https://gitlab.haskell.org/ghc/ghc-wiki-mirror/-/blob/master...

Re: Leaving Haskell behind

#85

Post by regularfry »

Tainnor wrote: post #33
regularfry wrote: post #22

Hm. Not really convinced by either Ruby counter-example. The first one's ok, ish, but doesn't take advantage of the fact you can pass a block to `zip` so you don't need the `map` call. The second one's just wrong. You wouldn't use `flat_map` for that if you didn't want indentation, you'd use `Enumerator#product`: def all_flavors flavors = [:vanilla, :chocolate, :strawberry] containers = [:cone, :cup] toppings = [:spr…

The point is that Haskell's do notation works for every monad, whereas "product" in Ruby works for just a cartesian product of sets, and not any other use of monads (e.g. generating random values, async code, operations that might return errors, IO operations, and so on).

The point is more specific than that: the claim here against this example is that Haskell's `do` notation uniquely lets you avoid indentation depth. The thing is, none of those other examples cause indentation depth problems in other languages because they don't force you through type system hoops to get useful work done.

Besides, you can (ab)use Enumerator for all sorts of monadic things if needs be and end up with something quite terse. A random number generator is trivial, for instance.

I'm not saying that `do` notation isn't a neat trick, it just tends to be a trick other languages don't need. Its generality is both a blessing and a curse.

Re: Leaving Haskell behind

#86

Post by runeks »

Pannoniae wrote: post #65
xedrac wrote: post #31

Earlier quoted context omitted.

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.

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

Re: Leaving Haskell behind

#87

Post by mrkeen »

runeks wrote: 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).…

> I still don't understand why this is necessary. Why must code compiled with GHC 9.6 use base version 4.18.0.0?

It's hinted at in the section you quoted. A newer ghc might reject older base code as invalid.

Re: Leaving Haskell behind

#88

Post by bradrn »

Tainnor wrote: post #81
bradrn wrote: post #73

Earlier quoted context omitted.

> I'm always confused about whether I should have ghcup or stack manage my Haskell versions (and what the benefits and drawbacks are) There was a long and drawn-out transition, but these days it’s quite simple: use GHCup to manage your tooling, and Cabal to manage your packages. At one point Stack was the best option, but no longer: it’s not as well maintained, and is missing a lot of features (see e.g. https://disco…

You say "don't use stack" and the other person in this comment thread says "use stack". Do you see the issue?

Fair enough, though I’ll note that only I’ve given an up-to-date reference.

Re: Leaving Haskell behind

#89

Post by regularfry »

paulddraper wrote: post #69
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…

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

Adding `install: --no-document` into ~/.gemrc is something of a reflex for me. Should only be getting `ri` docs these days by default though.

Re: Leaving Haskell behind

#90

Post by joeyh »

This is a pretty good post. The weak part of it to me is that I have never felt pushed to use any particular new fancy type stuff if I don't want to. Don't want servant's type-level http apis? Drop down a level and use warp. Libraries are often layered this way because it's understood that excessively complicated types can be a trap. One does have to develop an intuition for how far to go, which will involve making mistakes.
Post reply on HN