Sure sounds like an LLM.

It’s not exactly like vim, and there are plenty of vim plugins that don’t work with it (anything vim8 onward). There has never been a 1-to-1 correspondence, the gulf widens as both develop different features with different philosophies.

The most egregious offense on Neovim’s part that I can’t get past is the removal of access to the shell in which you run vim (via :!, :w !, etc.). Vim is so much more capable of being closely intertwined with the shell, whereas neovim requires everything to be done through terminal buffers (speaking of which, vim’s terminal buffers are a lot better than Neovim’s).

Also, Lua is really overrated and worse for vim scripting than vim9script (which is both more native to vim and faster).

Most of vim is not emulated. It’s very surface-level and limited. The closest is evil mode for emacs, which is decent, but still lacks a fair bit. The emulators in Intellij and VsCode are paltry in comparison to what vim can do.

The OP is on feddit.uk, so most likely not an American.

The question is also just that, a question. Not an expectation.

That’s what happens when you start using LLMs for all of your software development. Garbage code all day long.

Because they vibe code the shit out of everything now. Insane shit is bound to happen.

Oh for sure, it’s definitely less common, though there are a number of other companies running it in production as well. This isn’t my first Haskell job, after all. My last job was also a similar size company and codebase. Facebook was even running it for a while for their sizeable abusive content detection system before that was shuttered due to company politics/policies (back when they were trying to do something about it at all).

But yeah, it’s not the first pick for a lot of companies, though I tend to think of that as a simple mindshare/inertia explanation than anything inherent to the language/ecosystem.

I’m not entirely sure what the Haskell comment is supposed to mean. Just that it would be cool? Or that it would be hard?

Because if it’s the latter, that’s just really not true. Haskell’s quite well-suited to writing web servers and has many high-quality libraries for it. I’d actually argue that it’s one of the best options for it in 2025. I write Haskell professionally developing web servers we use for our web and mobile apps. We have about 0.5 million lines of Haskell in production (and given how terse Haskell is, you could expect that size to be at least double were it written in an imperative language).

Heh, guilty. Pretty much always something where I had an ambition to make a change but got distracted or didn’t have time to work on it.

They aren’t useful now, but even assuming they were, the fundamental issue is that it’s extremely expensive to train and run them, and there is no current inkling of a business model where they actually make sense, financially. You would need to charge far more than what people could actually afford to pay to make them anywhere near profitable. Every AI company is burning through cash at an insane rate. When the bubble pops and the money runs out, no one will want to train and host them anymore for commercial purposes.

LLMs do not understand anything. There is no semantic understanding whatsoever. It is merely stochastic generation of tokens according to a probability distribution derived from linguistic correlations in its training data.

Also, it is incredibly common for engineers at businesses to have their engineers write code to automate away boilerplate and otherwise inefficient processes. Nowhere did I say that automation must always be done via open source tooling (though that is certainly preferable when possible, of course).

What do you think people and businesses were doing before all of this LLM insanity? Exactly what I’m describing. It’s hardly novel or even interesting.

All of that can be automated with tools built for the task. None of this is actually that hard to solve at all. We should automate away pain points instead of boiling the world in the hopes that a linguistic, stochastic model can just so happen to accurately predictively generate the tokens you want in order to save a few fucking hours.

The hubris around this whole topic is astounding to me.

…regular coding, again. We’ve been doing this for decades now and this LLM bullshit is wholely unnecessary and extremely detrimental.

The AI bubble will pop. Shit will get even more expensive or nonexistent (as these companies go bust, because they are ludicrously unprofitable), because the endless supply of speculative and circular investments will dry up, much like the dotcom crash.

It’s such an incredibly stupid thing to not only bet on, but to become dependent on to function. Absolute lunacy.

I’ve done that. It sucks.

If your experience with FP is as limited as you say, then, respectfully, you lack the requisite experience to compare the two. It’s an entire paradigm shift that requires you to completely change how you think if you’re accustomed to OOP, and really requires one to program in a language designed for it. The features that OOP languages have cribbed from FP languages are very surface-level and not at all representative of what it actually is (and I’d say they largely miss the point of FP).

I have been writing Haskell professionally for the last 5 years over the course of 2 jobs developing database-backed web services for web and mobile apps, and spent about ~5 years before that developing in OOP/imperative languages. I have a good deal of experience with both paradigms.

OOP is more useful as an abstraction than a programming paradigm.

It’s a very poor (and leaky) abstraction, and you can achieve much more powerful abstractions with FP languages (especially Haskell, which has a type system that is far more powerful than any OOP language is capable of). This is evidenced by the fact that a whole slee of design patterns exist to solve problems created by OOP itself. FP languages, on the other hand, have little need for design patterns, because useful patterns are easy to abstract over and turn into libraries.

Real, human, non-computer programming is object-oriented, and so people find it a natural way of organizing things.

I have no idea what this even means. Programming is taking input and producing output. That, at its core, is a function. Pure and simple. Many useful ideas are quite difficult to express as a noun, which is how you end up with a whole array of super awkwardly named classes that try to “noun-ify” verbs (think classes named like Serializer, Resolver, Initializer, and so on).

It makes more sense to say “for each dog, dog, dog.bark()” instead of “map( bark, dogs)”.

This entirely misses the point of FP. What data is actually being transformed here? It’s a nonsensical example.

A good use case for OOP is machine learning. Despite the industry’s best effort to use functional programming for it, Object oriented just makes more sense.

Not really sure what you’re talking about. No one uses functional programming for machine learning outside of research. To be clear, Python is not functional programming. The reasons for that having nothing to do with the paradigm and everything to do with social reasons and inertia. Python was already used by a lot of academics for some ecosystem reasons, and the ecosystem has grown since then. Had the history of things been different, functional programming absolutely would have excelled at it and would have been a much better fit, because machine learning is fundamentally a pipeline of transformations on data.

You want a set of parameters, unique to each function applied to the input. This allows you to use each function without referencing the parameters every single time. You can write “function(input)” instead of “function(input, parameters)”.

This is trivial to do in functional programming languages with a variety of methods. Commonly this is done with the Reader Monad, or even simply partial application of functions (also known as closures).

I mean, I have an OOP background. I found FP as a result of my dissatisfaction with OOP. In fact, I used to teach OOP languages to new students and saw the same mistakes over and over again, mistakes that are simply not possible in FP. It’s a very similar story for everyone I work with, too. We all had jobs in various OOP languages before we managed to get jobs writing Haskell.

Oh, and I’m currently teaching Haskell to someone at work who has a CS degree and has only done OOP languages (and C), and while it’s different than what he’s used to, he’s still picking it up very quickly (working towards making him a junior engineer, which I think shouldn’t take too much longer). In fact, just the other day we pair programmed on a bug ticket I have and he was not only following along with the code, he spotted issues I hadn’t seen yet. Part of it is certainly that’s he smart (which is why I’m doing this in the first place), but part of it is also that, with a bit of familiarity, FP languages are incredibly easy to read and follow. The primary difference is that FP does everything explicitly, whereas OOP encourages a lot of implicit (and hidden) behavior. When you organize code around functions, there’s necessarily more explicit arguments and explicit return values, which makes it far, far easier to follow the flow of logic of code (and test!). Recently I was trying to read through our Kotlin codebase at work (for our Android app), and it was so much harder because so much is implicit.

I was required to take an ethics class, but it was a complete joke. Guy just wasted a bunch of time on very surface-level, Philosophy 101 stuff like talking about who Aristotle was. I’m not sure we even had homework actually. Real ethics were nowhere to be found.

FP has been around a long time, and yes, it is outright better than OOP. Sorry. I write Haskell professionally, and never have I ever felt like something would be easier done in an OOP language. Quite the opposite.

Unrestricted mutation makes programming really hard, and OOP and mutability go hand-in-hand. If you try to make immutable objects, then you’re just doing FP with worse ergonomics.

No one can, because they (LLMs) are fundamentally not suited to the tasks people try to use them for.

Eh, it’s just different. Other languages are hard in other ways. Haskell’s at least have very good reason behind them.

I write Haskell professionally and and am teaching to people without any experience, and it’s really no different than anything else. Though I will say that my experience is that university professors are often pretty clueless about the language and don’t teach it well.