Live data from Hacker News

Leaving Haskell behind

journal.infinitenegativeutility.com

361–370 of 402 posts

Re: Leaving Haskell behind

#361
post #228

Earlier quoted context omitted.

It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.

Yes. I've been in teams where there has been gradle vs maven arguments. Right now the Mac (M1 or M2) users in our team can't run our integration tests. It has been suggested that if we migrate our 50-100 services to Java 17 then the tests will work for them again. Trying to do this breaks the Gradle scripts, and the errors are so vague I can't tell why it's complaining.

While I understand what you're saying, the "XY doesn't work for mac users on M1/M2" is a really pervasive problem across all technologies.

Re: Leaving Haskell behind

#362
post #356

Earlier quoted context omitted.

The problem is that you should always write your code to be idiomatic in the language. In this case I feel like the Idiomatic Haskell way has serious drawbacks. For example, It's fine in C to manually allocate/free memory, it's the way you have to write C. It's not fine to do the same thing in Rust. Even though you of course could do that in Rust as well.

It's perfectly idiomatic Haskell to annotate all your functions with an effect you believe they should all have.

The only reason this is idiomatic is because there is no better way. That's the entire point I'm making... Haskell prides itself in writing generic and reusable functions. This then is then thrown out of the window with the kitchen sink monad. Very understandable, because everything else sucks.

That precisely why I think this is a great shortcoming of the language.

Re: Leaving Haskell behind

#363

Earlier quoted context omitted.

The Blub Paradox is relevant here: http://www.paulgraham.com/avg.html It's hard to know what you're missing if you haven't tried it. If you see patterns moving data around, it's nice to abstract those out. And higher-level languages give you more powerful abstractions.

I have used many different programming languages (including BASIC, C, Python, JavaScript, Java, Perl, PHP, Haskell, Lisp, and others), even with powerful abstractions (which I can understand how helpful they are), and I still think C is better, and mostly use C. There are improvements which could be made (and I have some ideas of such), but most of the stuff I have seen is usually just worse instead. Some GNU feature…

If you seriously think C is THE best programming language you should simply be banned from writing code. Seriously. C is completely memory unsafe, all languages which are memory safe surpass it by default.

Re: Leaving Haskell behind

#364

Earlier quoted context omitted.

why do sometimes people say things like "and it can take half a day to get someone up to speed with these tools if they haven't used them" half a day is like almost no time at all half a day is just few hours, how is this a long time .. how is this any time at all makes me doubt myself a bit, am i too mediocre to think that way the previous line make more sense to me "It's taken me years to settle into this system" ,…

I don't think it's half a day to get proficient, it's half a day to hack something half working together so they're unblocked and can do the other stuff they want to do.

[deleted]

Re: Leaving Haskell behind

#365
post #356

Earlier quoted context omitted.

It's perfectly idiomatic Haskell to annotate all your functions with an effect you believe they should all have.

The only reason this is idiomatic is because there is no better way. That's the entire point I'm making... Haskell prides itself in writing generic and reusable functions. This then is then thrown out of the window with the kitchen sink monad. Very understandable, because everything else sucks. That precisely why I think this is a great shortcoming of the language.

It's not a shortcoming of the language; it's a shortcoming of the goal! You can't have both the goal of fine-grained effect tracking and the goal of not having to make fine-grained changes when effects change. They're incompatible goals in any language.

The strength of Haskell is that it allows you to achieve the first goal if you want. Most languages don't (pretty much no other language, actually).

Re: Leaving Haskell behind

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

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 deterministic-enough builds.

2. dune files and s-expressions are still weird to write. I wish we can move away, or at best, have a tool that helps you remember and where configs. best I have now is chatgpt instead of having to crawl dune docs

3. eio, lwt, async - 3 async runtimes, hoping that one day it’ll be easy to use an async lib with an lwt-based project via eio. The division will likely never be consolidated

Re: Leaving Haskell behind

#367
post #365

Earlier quoted context omitted.

The only reason this is idiomatic is because there is no better way. That's the entire point I'm making... Haskell prides itself in writing generic and reusable functions. This then is then thrown out of the window with the kitchen sink monad. Very understandable, because everything else sucks. That precisely why I think this is a great shortcoming of the language.

It's not a shortcoming of the language; it's a shortcoming of the goal! You can't have both the goal of fine-grained effect tracking and the goal of not having to make fine-grained changes when effects change. They're incompatible goals in any language. The strength of Haskell is that it allows you to achieve the first goal if you want. Most languages don't (pretty much no other language, actually).

That's an extremely limited point of view. Just because Haskell allows precise specification does not mean it is impossible to disallow loose specification. In fact that's one of the strongest values of Haskell's type system. For example you can overconstrain your head function

    head :: [Int] -> Int
But you can also just leave out the type signature all together to let the type checker figure out the most generic type. You can have your cake and eat it too.

You can even almost do what I want with partial type signatures. Just sprinkle it everywhere inside your constraints. GHC will automatically pick the right constraints. At the call site you actually care for the definition you can not use the partial type signature. The great disadvantage of this is that you now introduce ANY constraints into your type signature and you lose your types as documentation.

But that doesn't have to be

You could have a constraint with something like `UseMonadSubset (...)` which works almost like partial type signature. GHC should infer 0 or more of the monads insde `UseMonadSubset` as the actuall constraint. `

Then you could write something like:

    fibonacci :: UseMyMonadSubset m => m Int
    fibonacci = -- Uses only MonadState (Int, Int, Int)

    -- Type checks because type checker can see fibonacci ONLY uses MonadState
    foo :: MonadState (Int, Int, Int) m => Int
    foo = fibonacci

    bar :: UseMonadSubset m => Int
    bar = fibonacci
Which allows for precise specification if you want to and if you don't you let the type checker figure it out. You may even be able to implement this as GHC type checker plugin.

Re: Leaving Haskell behind

#368
Completely agree with the author. Haskell is a great language but the ecosystem sux. I have a small project that breaks every time I update stack. It really lacks some high quality, bomb proof libraries, like for http for example. Cross compilation is next to impossible, stack also recently broke for using Docker for that.

Cabal is a mess, as is its weird AF format.

cargo is a dream by comparison. I am not happy with some things about Rust either but by comparison it has amazing tooling, and some incredible solid libraries. It also helps that you don't have to be a wizard to get extremely good performance.

Re: Leaving Haskell behind

#369
post #251

Earlier quoted context omitted.

But that can't be runtime dependencies to your code? I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.

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.

That sort of thing is unfortunate, but not too bad since we can add those packages to our own dependency list (e.g. in the pluginManagement section). It's a bit redundant, but as a bonus it ensures that such "dynamic" behaviour is acting as expected (since the build will fail if it picks different packages to the ones we wrote down!)

The same approach can be used when depending on third-party jars/plugins which don't fully specify their dependencies: just add the missing ones as extra dependencies of our project. (This happens a lot, where projects have undeclared dependencies on some commonly-used library, and don't notice since it's usually available in a well-stocked ~/.maven2 cache)

Re: Leaving Haskell behind

#370
post #337

Earlier quoted context omitted.

> In that same thread that you've linked, other people have later replied arguing for why they prefer Stack so... I merely stated that I have no trouble running old projects using stack. > I don't really think that you've given an argument that is persuasive enough to someone who is new to Haskell. Honestly, cabal improved a lot since the old ages. For a beginner, either stack or cabal should be very fine imo. > or w…

> I merely stated that I have no trouble running old projects using stack. I was referring to the linked forum thread. > Not sure why you would want to do that. Either you use stack and let it handle your ghc install, or you don't, and I really don't see why you would use stack only for compiler install. What I mean is that when I start VS Code on my Haskell project again after a couple months, it tells me that it ne…

Ah, didn't run into this issue, as I don't use vscode.

Apparently there is some work being done to improve the stack hls experience, but I wouldn't know how it's going and when it's being delivered: https://github.com/commercialhaskell/stack/issues/6154

Post reply on HN