Is this our last chance to use fun programming languages at work?

Source: Dev.to

The Conflict

A different way to look at this is from the perspective of mainstream vs. niche programming languages.

• If you are obsessed with a programming language, you are likely obsessed with some niche, esoteric language.
• If you are not obsessed, you are probably using something more or less standard – the good old “nobody ever got fired for choosing Oracle”.

Those aren’t the same, but bear with me. I’m not arguing for any side; I just want to establish that there is a conflict:

Within a team, a company, or a wider industry, there are people with different values and interests.

A very new conflict is the use of LLMs (large language models). Once again, some people are all‑in, some refuse to use them, and many fall somewhere in‑between.

If we overlap those dimensions, we get conflicting quadrants. It’s a simple illustration – conflicts are rarely two‑dimensional.

Conflicts aren’t fun. Sure, some people love them and thrive in them, but for most of us, constant conflict is draining. If most people on my team are in one quadrant and I’m in another, I have to:

• suppress my needs,
• argue,
• change companies,
• or something else.

A Possible Solution

While looking at a project at work, it clicked: we can have our cake and eat it too – one group can have a particular tool, another can use something else. We can run successful, low‑conflict teams across multiple quadrants.

Below is the story of that little project. Maybe it can give you hope or inspiration in some dark, turbulent times.

The Project: Migrating an Internal Dashboard to PureScript

Background

• About two years ago I wanted to migrate an existing internal dashboard to PureScript.
• The dashboard was part of a legacy system that nobody wanted to touch, let alone extend – the bar was quite low.

Goals

1. Quickly migrate basic functionality to unblock a larger legacy‑system migration that was driving me crazy.
2. Make it composable and extendable with the lowest possible friction: copy‑pasteable components and easy integration of TypeScript/JavaScript components.
3. Showcase PureScript and get people curious (spoiler: this didn’t bear fruit).

It was never a goal to spread PureScript usage; the arrangement with the team and tech leadership was to try it for a few weeks, then consider or plan a rewrite to TypeScript.

I built an MVP (including the migration of core functionality) in my free time because there was no time for it during work hours. As a plus, I produced a video about PureScript + shadcn/ui and a template.

Why Not Introduce Unmaintainable Tech?

I believe one of the worst, unprofessional stunts is to introduce something that nobody can maintain. It can soil the reputation of the technology forever.

I once saw a project built in Haskell that suffered from terrible management and unrealistic plans from the start. It was doomed to fail, people quit, and eventually nobody could or wanted to maintain it. Years later, people who didn’t even know what Haskell looked like blamed the language (and the dev team) for everything.

Execution

After I deployed the first version, it was just the two of us contributing.

• My accomplice had no prior PureScript experience and initially hated it—mostly because of the tooling and compilation errors.
• Nevertheless, he contributed more code and functionality than I did.
• In a couple of weeks we got the project to a fairly large state, even though it wasn’t on our team’s priority list; we worked on it in the evenings and between other tasks.

The LLM‑Assisted Era

Things were going well, the project was growing, and then we entered the LLM‑assisted coding era.

• A lot of annoying things that used to be managed manually are now behind a nice UI: customer‑support tools, dev tools, product configurations, analytics, and exploration tools.
• A huge portion of that code isn’t human‑written. The result? Quite successful.

One of the main reasons it works (and scales) so well is that it’s a stateless app (aside from persisting users’ dark/light‑mode preference) and consists of simple flows. When we let the LLMs loose, we already had a solid codebase full of copy‑pasteable snippets.

Each tool is isolated; it doesn’t affect the rest. The only problem is organizing everything and not cluttering the UI, but that’s more of a fun puzzle than a real issue. In this context I’m not afraid of potentially bad or slow changes affecting other tools—there’s no need for massive smoke tests or QA cycles.

A Real‑World Example

“One person wanted to add a new fraud‑prevention tool. They aren’t part of our team and have never touched PureScript before.”

We had a five‑minute chat, I shared the repository, and said:

“Look, as long as there are secure endpoints, there isn’t anything else to worry about, really.”

The project’s README is just:

npm install
npm start

No sophisticated setup. The contributor opened a pull request the next day; the code looked good, consistent, and the UI was nice and friendly.

Lessons Learned

• Steep learning curves are no longer a show‑stopper.
  The contribution entry level is pretty low now, thanks to good documentation, copy‑pasteable patterns, and LLM assistance.

• Don’t generalize.
  I’m not saying every contribution is equal, nor that this approach replaces acquiring deep skills. It simply lowers the barrier for getting started.

• Stateless, isolated components make it safe to experiment and iterate quickly.

• LLMs can accelerate development without sacrificing maintainability—provided the underlying architecture is simple and well‑structured.

Conclusion

Conflicts over language choice, tooling, and the adoption of LLMs are inevitable. But they don’t have to be destructive. By:

1. Choosing a low‑friction, composable architecture,
2. Keeping components isolated and stateless,
3. Leveraging LLMs for boilerplate and repetitive code,

you can build a system that welcomes contributors from any quadrant—whether they love PureScript, hate it, or have never heard of it before.

So, the next time you wonder whether to care about the programming language you use, remember that the process and environment you create can be far more important than the language itself.

Open‑Source, LLMs, and Functional Code

In work environments there are opportunities now to have good human code (I would go as far as to say, good functional code) and open the gates to various contributors. If you have a higher bar than LLMs can deliver, you can always refactor and polish the code as needed.

As a bonus, we can lower the fear of maintainability and bus‑factor. Microsoft says they are going to use LLMs to rewrite everything to Rust, so if somebody out there was brave enough to claim that, surely we can be brave enough to introduce new technologies at a smaller scale.

If somebody hates your Haskell tool at work, what stops them from rewriting it over the weekend?
It has never been easier.

I only have experience migrating Ruby, JavaScript, and Python code to functional languages, but I’m pretty sure it works the other way around.

It also extrapolates to making libraries. If someone says:

“Oh, no! There is no Haskell SDK for a new hyped technology!”

We can just laugh at them and send them back to 2025! (Sorry, this is one of my favorite internal jokes.)

PureScript & FFI Generation

In the case of PureScript, we don’t even need to rewrite libraries – we can generate FFIs (PureScript‑friendly bindings) to existing JS/TS libraries. We can also generate TypeScript code that uses those libraries and then generate PureScript bindings to that code instead.

Example:
We use shadcn/ui and have a couple of graphs integrated already, but not all of them. A few months ago I wanted to investigate how the data looked somewhere (to work on improving caches), just once. LLMs are pretty good at making quick charts – they don’t want to use shadcn/ui and prefer using Radix charts directly. But I don’t have to maintain it, so who cares?

(There is a chance I’ll need it again next time, and I still haven’t learned it, but that’s a different problem.)

Tooling & Errors

I don’t want to wade through a bunch of complaints and myths; the last two things I want to mention are tooling and errors.

I don’t have an exact Venn diagram, but many people who complained about Haskell tooling are now using chat as an interface to their code. So… yeah… make your own conclusions.

The situation with compilation errors is even more interesting. These errors – in Haskell, PureScript, and so on – are a huge pain point for many inexperienced and experienced developers. Talking about this has been in my backlog for a long time.

Long story short: 90 % of the time, if not more, the compilation errors are actually very good and precise. The problem is that they are often too precise. The compiler tells you exactly what the problem is, but in words and concepts you don’t understand. If you did, you wouldn’t make the mistake in the first place.

firstLetter :: String -> String
firstLetter xs = head xs

• Couldn't match type ‘Char’ with ‘[Char]’
  Expected: [String]
    Actual: String
• In the first argument of ‘head’, namely ‘xs’
  In the expression: head xs
  In an equation for ‘firstLetter’: firstLetter xs = head xs

0 || True

• No instance for ‘Num Bool’ arising from the literal ‘0’

I’m not defending those errors, by the way. They still suck for humans. But guess what? They are really good for the machines. Feed those suckers to LLMs. No need to be scared of compilation errors.

A Real‑World LLM‑Generated Module

On this project we were cautious with LLM‑generated code, but eventually we ended up with a couple of modules that only Claudius reads and edits. Once I was curious and wanted to check what we had there.

We had 10 states for different in‑flight statuses – a common pattern where, when one action is happening, we don’t want to allow others. Each action/button had its own flag/state and checked all the others (9 checks) to determine if it should be disabled. Terrible.

• If you look at one change or PR at a time, it’s fine – each one just adds a normal state, nothing special.
• If you step back and look at the bigger picture – hell. It was a quick and easy fix to go from 10 states to 1.

Refactoring and dealing with tech debt are quite important, but can be scary. This is a point for languages with fearless refactoring, like PureScript. I can’t imagine how JavaScript developers, for instance, can survive this long‑term.

This is me, right now, on a specific project. It is not an argument for an FP‑only future.

Questions for You

1. Do you care what programming language you use?
2. What are you doing about it?
3. Do LLMs care what programming language they use?
4. How does the language choice affect the things you care about?
5. How will it affect the future?

This is February 2026; regardless of your opinion and experience, there is a chance (not a 0 % chance) that programming languages will matter less because of the new abstraction level. But they might matter more. Could it be our last chance to choose and care about programming languages?

I would love to ramble, speculate, and expand on this more, but probably some other time.

Side Quest: PureScript Adoption

For that project, my side quest was to get people excited about PureScript, maybe teach a couple of people. It failed. Nobody really wanted to, and there isn’t much incentive at this point.