You made me look up the definition of "note." It appears to mean a short piece of writing meant to be commentary or to share information. OP's link looks like it's both of those things.
As someone who loves Haskell more than any other language, some challenges are
- the tooling is decades behind, say, Rust or Go
- finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search"
- creating the right solution also looks different. It's usually borne out of thinking about the types and coming up with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic
- same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk
- GHC directives effectively mean there are multiple "Haskells"
Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption.
Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.
No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL.
Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context.
I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.
The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
No, this is not the reality of using Haskell packages.
The problem you describe was solved more than a decade ago.
You use a Stackage snapshot (https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package.
Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.
That's definitely not true, even if that was true maybe 6 years ago. As someone who's uses Haskell daily and also many other languages, I can see Haskell's tooling as more advanced than many others.
I tried building a cross platform shared library. I still couldn't get GHC to generate the library with Haskell's Runtime (RTS) statically linked. Tried multiple AI models and nothing could make it work. Eventually gave up after a month.
Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects.
Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC.
Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
I think the GHC directives are what hurts Haskell the most. At this point they should just embrace the GHC extensions and make it the "official" Haskell.
Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.
As someone else mentioned, that's what GHC2021 and GHC2024 are for.
If you're suggesting that _every_ GHC extension is enabled then I think you don't really understand the implications of that. Many aren't compatible with each other in varying degrees, for one. They also exist on a wide range of stability and production readiness.
On the other hand, I agree that the extensions indeed hurt Haskell. Standardizing on them is absolutely necessary to survival for a team of even a modest size. GHC2021 and GHC2024 help to do this for the community at large.
The real "deep" change that I think would be best for Haskell is probably impossible - that would be for GHC to split into two compilers - one for production use and one for research. I don't even know HOW we'd do that but I think that's ultimately what us production users want in some form or another.
the only other haskell compiler is MicroHs. and it has no pragmas. it just enables the whole thing.
this is not a real problem in practice. even without the GHC20XX stuff (which is nice). it feels like a problem a novice would point at (and be totally wrong)
sorry your favorite language doesn't let you import language features according to your needs. half of them have trade-offs! like -XOverloadedLists. Useful, but hurts inference. Maybe you don't want it globally. But maybe in a few modules, it's perfect. {-# LANGUAGE OverloadedLists -#} is the answer that no other mainstream lang has.
-XPolyKinds is another great example of that sort of extension.
Preferably there would be more implementation. But if they only implement the "standard" language, it will be missing a lot of things. That is the point!
It's not Haskell anymore. It's Glasgow Haskell. It's its own language at this point.
For all the academic interest the language has, it seems very few of those people want to do anything foundational to make the language more ergonomic and more relevant.
cabal is as cargo-level but has a bad CLI. it really isn't that bad. and Haskell has amazing Nix support. Like 3 different good options there depending on your project.
and this isn't even to mention stack..
now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)
Haskell is more easily compared with e.g. OCaml than with something like Rust. (It's worth noting that OCaml now has its own 'rustified' development OxCaml.) The main practical difference is that Haskell is idiomatically based on lazy evaluation, whereas OCaml is strict. This makes corecursive patterns a bit easier to express in Haskell, but OCaml and OxCaml are friendlier wrt. performance concerns.
That's a fair question. It's part ecosystem, part tooling. The ghcup, stack, cabal mishmash is closer to maven than a tool with a modern streamlined UI like cargo.
And yes, Haskell is significantly more expressive than Rust--at the cost of performance.
I had a Casio as well because, IIRC, it was the only thing the shop had. Eventually I had to also get a TI because it allowed using imaginary numbers in a matrix operation. Not that that was used in more than one course after all. But I grew to like it and even had an emulator for a long time on my first smart phone.
But yeah, Casio was definitely more friendly and polished in UI, but dumber. You could only use "wizard" type things and pseudo gui clickies while the ti was crude and text-heavy but let you enter just about anything anywhere and seemed more symbol and language oriented. Which one was nicer in use? I guess it would depend on how much of that language you could memorize. Or browse a cheat sheet for.
It's usually a small amount of waste, and handling gas is very different from distillate.
You'd need to either liquify that gas or collect it to a pipeline in order to make it useful. I remember reading that modern refineries make use of the gases instead of flaring them though I'm not sure how.
Nobody likes experimenting on animals, but it is use mice or orphans in third world countries. In silico and computational models are just not a good enough analogue for the human body.
Well it's good to be honest, and so I commend you on that.
So the hierarchy is
- our kids
- "third-world orphans"
- other species
For what it's worth, I'm not denying the benefit we obtain by testing on animals, nor am I suggesting that we live surrounded by rodents that we know to be vectors for multiple diseases that would affect us.
The comment above was merely an observation on the value of life and how little attention we pay to it.
We subject sentient beings to untold amounts of horror every day, and we are completely destroying the balance of life on earth with a system that is entirely devoted to serving humans--individual humans, not humanity.
The statue is not the point. The point is what this little creature did and how we might learn to show mercy and respect to our fellow sentient beings.
Correct. These are the creatures that will ruin your home/barn if infested with them.
Source: recently finished getting rid of a rat infestation in my barn. they also reproduce at a crazy rate. Some poison + getting two barn cats = problem solved.
Major, major rabbit hole warning. You think you're about to read something about a philosophy professor, and what you get is an Alice Munro/Larry McMurtry mashup. His son seems to be a pretty amazing writer in his own right.
For big tasks you can run the plan.md’s TODOs through 5.2 pro and tell it to write out a prompt for xyz model. It’ll usually greatly expand the input. Presumably it knows all the tricks that’ve been written for prompting various models.
reply