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.
Leaving Haskell behind
361–370 of 402 posts
Re: Leaving Haskell behind
#362Earlier 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.
That precisely why I think this is a great shortcoming of the language.
Re: Leaving Haskell behind
#363Earlier 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…
Re: Leaving Haskell behind
#364Earlier 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.
Re: Leaving Haskell behind
#365Earlier 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.
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
#366Earlier 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…
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
#367Earlier 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).
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
#368Cabal 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
#369Earlier 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.
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
#370Earlier 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…
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