I was thinking of Haskell recently, why isn't it more popular with AI? Haskell is very terse and token efficient, it has many expressive safety features. Rust is getting additional adoption because of its strictness, so hey why not have this in Rust over Javascript if it takes the same time to write?

An ideal language for agentic AI I would think is extremely strict, where the AI can iterate over the tooling for correctness. It would probably be less verbose and more terse to allow the AI to be more efficient with tokens.

There is this memo video of S. P. Jones that famously says "Haskell is Useless". I love Haskell, but I wished it was universal like C, C++, JavaScript, Rust, and C#. By that I mean: It could be used to create apps for desktop, mobile, and web. JavaScript can be used to do so many things like power the entire web, be on node and let anyone create cli and share the code with web, and mobile through React Native, on desktop with Electron and its alike things, it lets you do plugins for god knows how many things, it lets you write things for the GNOME Shell... C and C++ are perhaps behind everything in the world and string theory finally gets seen will see they are written in C. And they can be compiled to Web and almost everything in the world. Rust is a placeholder for the two, and C# reinvented itself when it saw Mono and now works even in the browser. Each time I see Haskell I wonder what else can I do rather than creating CLI apps, and it makes me choose something else that grants me more code reuse and interesting applications.

If I could have a vision for Haskell, it was for it to be useful. Academic research and making compilers is cool, a few cli things here and there are cool too, but why can't we build music players and game engines and flutters and web pages with it? The language is way more elegant and beautiful than all the JS/C like languages out there and I really wished I could use it for the things I did. I'm aware of Servant/Yesod/IHP/Miso/Reflex for web, GTK/Monomer for desktop, TidalCycles for music, SDL/gloss for games, and various FFI/plugin, but none of them feel as coherent and worked on as the others, none of them are polished. Haskell surely needs good DX, but it also needs really better reasons for existing.

hasufell has been a wonderful person in haskell land. hes got very clear headed ideas about stuff and so forth.

also the stuff i can now build in haskell with computer aid is epic. earlier this week i stood up what i believe is one of the/ if not the: best step file format reader writer on like every axis. some c ones are 20-30 percent faster on the largest possible cad assemblies i could try out.

an important axis that folks neglect to consider: the main way llms are getting scaled up for better coding is metric megatons of reinforcement learning traces, and type checking thats fancy gives a cheaper and faster training feedback loop.

with an llm as a sortah insane manic intern im looking over the shoulder, so to speak, im able to build the apis and designs i can see but cant type anywhere near the same scale. but i can specify the keystones for the exact designs quite compactly and then the agent kinda acts as a compiler inhave to correct and iterate running

RE the debugging experience in Haskell: we recently wrote a post about bringing live run-time debugging to our Haskell VR compositor: https://simulavr.com/blog/debug-hud/

Live step-through debugging and interactivity we think is pretty underrated in the Haskell ecosystem.

While I agree compile time is a big issue, I think the focus should really be on incremental build, because considering how much work the Haskell compiler has to do, it is expected to be quite slow on full build.

But incremental build has no reason to be slow, if the scope is as fine-grained as the function and type level.

It doesn't have enough marginal value add on top of competitors like Rust. There are other more significant synergies with coding agents that are getting attention instead, like autonomous formal verification. Languages like Lean enable an entirely new category of engineering, and Haskell just doesn't. So it's stuck in a difficult middle where it's too different to justify relative to its gains, but not different enough to capture the new opportunities emerging.

Just like Ruby was IMHO a "simple" lang carved out of Perl; Elm is a "simple" lang carved out of Haskell.

Some languages are here merely to inspire others.

Not that Elm is such a success... But it is "simple" (Haskell and Perl are not; they big).

I remember when Charles Hoskinson announced that smart contracts on his crypto platform Cardano / Plutus would use Haskell.

It just didn't get anything like the adoption that Solidity had at the time.

> the onboarding experience of rust

> we are going to build the best onboarding experience in the programming language ecosystem

> This can only be done if we commit to unix principles > write programs that do one thing and do it well

Rust is so approachable because Cargo does not subscribe to "do one thing". In fact Cargo does a bunch of things. Which is very convenient for newcomers, because they only need to learn one thing instead of a bunch (and how they interact).

The same holds for a GUI like a file explorer with buttons and interactions like drag / drop or marquee select, which is a bunch simpler than chaining 3 programs together to delete 30 old files and move some folder into a subdirectory.

It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.

It's also a reason why the installation experience for Haskell is so bad: there are a bunch of programs and users don't know where to start and what they need.

> Cabal and Stack: which one should I install? > We recommend installing both.

One thing and one thing well.

Atleast it seems they've added a combined installer for these tools since the last time I've checked.

They’re pitching a tall order. First they will need to convince the masses that code should be understood.

Sooo they are fixing how you install Haskell? :D

Is it even possible for Haskell to have compilation times similar to Go, given the language semantics?

In before a certain defense tech engineer in 3...2...1

> Beginners: the onboarding experience must be our benchmark for usability

OK, so I put this into Gemini: "show me a non-trivial haskell function and type signature with at least five distinct arguments"

And I get:

---

processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)

processRecord transform mVal items pred (bVal, cVal, dList, eVal)

  | pred eVal = Right (transform (const bVal undefined) mVal, cVal, dList, eVal) -- simplified example logic

  | otherwise = Left "Predicate failed on the fifth argument"

---

My brain just crashes after the "::".

For the beginner, there isn't enough syntax on offer to discern who's doing what to whom here.

Is there a "function signatures for dummys" somewhere?

[flagged]

[flagged]