DEV Community: Kevin 心学

🐘 TypeScript for PHP? YES, that's possible! And it's not what you think...

Kevin 心学 — Tue, 21 Jul 2026 12:57:51 +0000

It is time to bring opposites together, to stir up these stagnant waters, and to restore an industry that is dynamic from within, with multiple connections that were previously impossible or unimaginable.

In the previous parts of this series, we explored how PureScript acts as a quiet rewrite of the Web, offering a territory of mathematical precision above JavaScript, and how its universal polymorphism allows it to target wildly different runtimes like Node.js, Erlang's BEAM, Python, Go, Scheme, etc.

But hey, what about the elephant in the room? Yes, what is running the majority of the web, today, in the shadow? You know. The eternal one, the big one, the one whose death everyone talks about, but who never truly dies.

PHP.

While the modern JavaScript ecosystem (among others) races toward edge computing and containerized microservices, around 70% of the web is still powered by PHP. From legacy WordPress sites to affordable shared hosting (cPanel, OVH, GoDaddy, basic LAMP stacks), a massive portion of the internet lives in environments where escaping the PHP runtime is either financially unviable, technically impossible, or simply unnecessary. And I haven't even mentioned powerful and mature ecosystems like Laravel, Symfony, etc. They have proven their worth time and again over the years.

And yet...

For a long time, the PHP ecosystem has been left without a true, strictly typed functional and safe alternative, like TypeScript for Javascript. Even though recent PHP versions introduced fantastic features (short closures, match expressions, Fibers), the frustration that comes with its historical limitations and typing remains very real for some of its users.

Oh yes, there is Hack, and there are phenomenal static analyzers like PHPStan... but Hack eventually required a custom runtime, and PHPStan (as powerful as it is) is ultimately trying to bolt safety onto a fundamentally permissive and imperative language through comments.

What we are talking about here is a true paradigm shift in safety and ergonomics, keeping the great portability of PHP, as it is.

Very well!

This is why I built phpurs: a brand new compiler backend that transpiles PureScript directly to modern PHP 8.4+ syntax.

It is no longer a proof of concept. It is passing the official PureScript test suite, and it is ready for production.

Here is how we bring the elegance of purely functional programming to the big web, while keeping deployment as simple as a legacy FTP upload, or anything alike.

The easy deployment paradox

In modern DevOps, deploying an app often means configuring Docker containers, CI/CD pipelines, Kubernetes, or serverless edge functions. It is powerful, but it is expensive and sometimes... a bit too complex for the real need. Let's be clear: I have nothing against it, I use it every day. But it's not always necessary. A website can run just fine on a very low cost server, possibly a shared one, without needing such an arsenal of tools.

For many freelancers and agencies, the reality is different indeed: clients often have a simple, small and cheap shared hosting plan. They want a robust application, but they don't want to pay for a managed AWS infrastructure.

So... phpurs bridges this gap. It allows you to write your entire business logic, API, and background processes in 100% pure, strictly typed PureScript. And you get all the guarantees of ADTs, pattern matching, the Aff monad, HKTs... and so much more... (some concepts will be new to some of you: don't be intimidated, they're very practical).

Then, you compile it, and you get plain .php files. No overhead. The compiler has pruned what the runtime won't need, and optimized everything (e.g. Tail-Call Optimization, Dead-Code Elimination, Uncurrying...).

You just drag and drop these files via FTP to your client's cheap HostGator, OVH server, or whatever... and it works. No container, no daemon, no reverse proxy. Just native execution.

One of the biggest strengths of PHP is its portability. We leverage it.

Architecture: standing on the shoulders of giants

In fact, phpurs doesn't reinvent the entiiiire wheel. It stands on the incredible work of the PureScript community (e.g. Arista's purescript-backend-optimizer).

The compilation pipeline is beautifully decoupled:

At first, purs compiles your code to corefn.json.
The backend-optimizer reads this CoreFn and performs aggressive dead code elimination (DCE), inlining, uncurrying, etc.
At the end, phpurs takes this highly optimized intermediary AST and prints it as modern PHP syntax. And of course, it will add additional and sophisticated optimizations for PHP's sake.

Concurrency: Aff meets PHP Fibers

One of the biggest historical flaws of PHP was its synchronous, blocking nature. How do you implement PureScript's asynchronous Aff monad in such an environment?

Well, PHP 8.1 introduced Fibers, and the Revolt event loop followed.

Support for Aff has been natively added to phpurs. The behavior of the event loop in the compiled PHP code perfectly mirrors its Node.js counterpart: asynchronous operations are handled transparently without blocking the OS thread. The main process will automatically wait for all pending Aff tasks to complete before exiting, for example.

You can seamlessly run your code with a JS runtime, or a PHP one. You can even switch from one to another, when you're coding.

There is no need for complex daemonized C or Go extensions like Swoole or FrankenPHP. By relying exclusively on native PHP Fibers and asynchronous libraries (like Amphp), phpurs ensures that your concurrent PureScript code can run natively anywhere PHP runs. It just works, and handles multiple requests, like a good ol' Express server in Node.

Moving complexity from runtime to comptime

In standard PHP or JS development, safety often comes at the cost of defensive programming at runtime: checking boolean flags, instantiating heavy wrapper classes, or placing if (!$form->isValid()) throw new Exception(...) checks throughout your domain logic.

Like TypeScript, PureScript flips this paradigm. But it goes further, with a powerful Hindley-Milner type system. Once the PureScript compiler validates your logic, the underlying compiled PHP is freed from defensive checks, leaving a trivial, lightning-fast execution path.

For example, consider a form processing pipeline where you must guarantee that data is validated before saving it to a database. Using Phantom Types, we can tag the state of our data (Unchecked vs Checked).

-- 1. Phantom Types
--    They exist ONLY for the compiler, zero runtime cost.
data Unchecked
data Checked

newtype FormData status = FormData { email :: String, age :: Int }

-- 2. Construction: Creates an `Unchecked` form
createForm :: String -> Int -> FormData Unchecked
createForm email age = FormData { email, age }

-- 3. Smart Constructor.
--    Only validation transforms `Unchecked` into `Checked`
validate :: FormData Unchecked -> Either String (FormData Checked)
validate (FormData d) = 
  if d.age >= 18 && contains (Pattern "@") d.email
  then Right (FormData d)
  else Left "Invalid form data"

-- 4. Database operation ONLY accepts a `FormData Checked`!
saveToDb :: FormData Checked -> Effect Unit
saveToDb (FormData d) = ...

It is mathematically impossible to call saveToDb with unvalidated data (FormData Unchecked). If you try, the compiler halts with a type error before any code is ever generated.

In PHP, we could translate what's above into something like that:

// 1. We must define wrapper classes and mutable state flags
class FormData {
    public function __construct(
        public readonly string $email,
        public readonly int $age,
        public bool $isValidated = false // ⚠️ Runtime state to track!
    ) {}
}

// 2. Construction: creates an "unchecked" form
function createForm(string $email, int $age): FormData {
    // We instantiate a real class object in memory
    return new FormData($email, $age); 
}

// 3. Validation mutates the state or throws Exceptions
function validate (FormData $data): void {
    if ($data->age < 18 || !str_contains($data->email, '@')) {
        throw new Exception("Invalid form data"); // ⚠️ Runtime defensive throw
    }
    $data->isValidated = true; // ⚠️ Runtime mutation
}

// 4. Database operation MUST defensively check the state
function saveToDb (FormData $data): void {
    // ⚠️ Defensive check at runtime: did the developer call validate() before?
    if (!$data->isValidated) { 
        throw new Exception("Security error: Data not validated!"); 
    }

    // ... 
}

Of course, advanced PHP developers might say they could use strict Value Objects (creating a separate ValidatedFormData class) or advanced PHPStan docblocks to avoid the boolean flag. And they'd be completely right. I did it too, for years.

But Value Objects add memory allocations and mapping overhead at runtime, while PHPStan only enforces safety through comments, not rock-solid compiler guarantees. More generally speaking, existing solutions are often smart compromises.

PureScript gives you the best of both worlds: strict, mathematically proven safety at compile-time, that compiles down to raw, zero-overhead unboxed objects at runtime. I simplified it for the example, but now, look at the compiled PHP code phpurs outputs for the entire pipeline:

// 1. Creating a `FormData Unchecked` simply returns a raw PHP object.
//    The `FormData` newtype wrapper is completely unboxed!
$createForm = function ($email = null, $age = null) {
    return (object)["email" => $email, "age" => $age];
};

// 2. Validation checks the raw data and wraps it in `Right`.
//    No state classes or newtypes are instantiated!
$validate = function ($formData = null) {
    if ($formData->age >= 18 && str_contains($formData->email, "@")) {
        return new Data1("Right", $formData);
    }
    return new Data1("Left", "Invalid form data");
};

// 3. Database save has ZERO defensive checks (no `$data->isValidated`)
//    PureScript guaranteed 100% safety at compile-time.
$saveToDb = function ($formData = null) {
    ...
};

Zero defensive runtime overhead. No boolean flags, no try/catch blocks, no dynamic state assertions inside $saveToDb.
Zero object allocations: the Phantom Types (Unchecked/Checked) and FormData newtype wrapper don't instantiate any PHP classes. At runtime, $formData is just a plain, raw PHP object seamlessly passed from $createForm to $saveToDb.

Complexity lives strictly in the compiler. What runs on your host is clean and fast.

What about performance?

It would be a legitimate question. For example, PHP is often criticized for its raw execution speed compared to V8 (Node.js).

In raw micro-benchmarks, PHP 8 is indeed about 2 to 3 times slower than V8 for heavy computational tasks. However, in the vast majority of real-world web applications, the main bottleneck is I/O (database, network, filesystem).

The difference in performance is entirely negligible in practice. You lose almost nothing in speed, but you gain the ability to deploy your code on any server in the world for pennies.

I recently battle-tested phpurs against the test suite of a real-world project (still a WIP, but the code is mature). The results are clear: in practice, it is only x1.15 slower. Of course, the value of this factor will depend on your very specific project(s). But remember: PHP is not the preferred backend for performance, it is for portability.

What about interoperability? The entire PHP ecosystem at your fingertips

You might be thinking: "This is great, but do I have to rewrite the entire world in PureScript? What about my existing PHP libraries, the AWS SDK, the Symfony components I rely on... ?"

Fear not. PureScript has always been designed with a very pragmatic approach to the outside world, and phpurs fully embraces this philosophy through its Foreign Function Interface (FFI).

You are not locked in a pure, isolated bubble. If you need to use a powerful, battle-tested PHP library, you can easily bind it to your PureScript code. The bridge between the two worlds is incredibly straightforward: you simply declare the type signature in PureScript, and provide the implementation in a standard .php file.

-- In PureScript: src/Crypto.purs
-- We declare the function and its type
foreign import hashPassword :: String -> Effect String

// In PHP: src/Crypto.php
// We implement the runtime behavior
$hashPassword = function (string $password): callable {
    return function () use ($password): string {
        return password_hash($password, PASSWORD_BCRYPT);
    };
};

That is all it takes. This simple mechanism allows you to tap into the gigantic Packagist ecosystem. You can leverage Symfony's HttpFoundation, Laravel's Eloquent ORM, Guzzle... anything, while keeping the core of your domain logic purely functional and mathematically proven.

Moreover, since the compiled output is just standard PHP, it plays perfectly well with Composer. This means you can incrementally introduce PureScript into an existing, massive legacy codebase. No need for a Big Bang rewrite: you can start by migrating your most critical, bug-prone business logic first, and let it interact seamlessly with your existing PHP architecture. In both directions: your PureScript modules can seamlessly tap into your existing Composer dependencies via FFI, and/or your legacy PHP codebase can simply require the compiler's output (i.e. PureScript code compiled into PHP code) to execute your newly written functions.

The next frontier

I am already using it in production for several client projects with strictly PHP-only environments, and the runtime stability is rock solid (and super fast). 🟢

Pure dev pleasure, with pragmatic client constraints. Getting the best of both worlds is a very, very pleasant feeling.

Community contributions are highly welcome! If you want to help add missing PHP FFIs to core and major PureScript libraries, your PRs are more than welcome.

Let's bring the elegance of PureScript to the 70% of the web that still runs on PHP! 🐘

Cheers 👋

Edit: A huge thanks to PHP Weekly for featuring this post! That's a delightful surprise. I'm really glad to see this approach resonating with the PHP community!

👉 The Compiler

👉 PureScript Fullstack example, able to run on PHP runtime

🌈 The ultimate polymorphism: PureScript as a universal language (Node's V8, Erlang's BEAM, Chez Scheme...)

Kevin 心学 — Sun, 21 Jun 2026 13:12:49 +0000

Just as PureScript has expanded into the backend after having long been assigned to the frontend (in people's minds), it is now spreading to all areas of programming. It’s a polymorphic language that can target Erlang for concurrency, Chez Scheme for raw speed, etc. Here is why it works.

A few months ago, I wrote an article about how PureScript serves as a "quiet rewrite of the Web", allowing developers to build robust, mathematically sound applications on the rooftops of JavaScript’s chaotic empire.

But as I delved deeper into the ecosystem, a profound realization hit me: I could have written the exact same article by replacing the word "JavaScript" with "Erlang", or "C++", or "Chez Scheme", etc. Not all languages: some aren't dense or powerful enough, others are currently being explored (e.g. WASM). But quite a few! In fact, often the ones having a very, very interesting runtime. JavaScript is a special case, as it is notoriously more controversial. But the principle is the same.

In fact, and with a slightly broader definition, PureScript does not only support powerful polymorphism in its type system. The language itself is polymorphic.

Let's pause for a second. What exactly is polymorphism in programming?

At its core, and to simplify things a bit, polymorphism allows a single piece of code to adapt its behavior depending on the data it receives. Take a simple polymorphic function:

-- Type "a" is generic.
-- In real code, we'd add the constraint "Show a =>"
display :: forall a. a -> String
display value = "Data: " <> show value

display 42       -- Int context.
                 -- Returns 'Data: 42'
                 -- as if the signature was: 
                 -- process :: Int -> String

display "Hello"  -- String context.
                 -- Returns 'Data: "Hello"'
                 -- as if the signature was: 
                 -- process :: String -> String

The function doesn't exist as a single, rigid block of code. Instead, the function will take the right shape at the very moment you call it: either the shape for integers, or the shape for strings. It is the context that defines what the function actually is.

It's the exact same thing for PureScript itself, as a whole. Its nature can change depending on your context of use.

It turns out that PureScript is quietly solving the holy grail of software engineering, the "Write Once, Run Anywhere" promise, by succeeding exactly where older cross-platform languages (like Haxe) hit a glass ceiling. Not just inside the code, in some parts, but with the code itself.

Here is how, and more importantly, why.

Choose your morph (without changing your logic)

If you think PureScript is just "Haskell for the browser", you may be missing one of the biggest paradigm shifts of the decade. Besides its unique features (e.g. Row polymorphism), and thanks to its unique architecture, PureScript compiles your code into an intermediate, mathematically pure abstract syntax tree called CoreFn. This tree can be transpiled into (almost) anything which is sufficiently powerful to understand it, and translate it in its own terms. That's philosophically close to WASM, even though it deals with a completely different topic: you define a universal layer, to facilitate the translation work everywhere else.

From there, the community has built alternative backends that allow you to deploy your identical business logic to radically different physical realities:

You want top-tier web UI and Node.js efficiency? Keep the default compiler or use purs-backend-es for highly-optimized ECMAScript.
You want massive telecom-grade concurrency and 99.99999% uptime? Transpile to the BEAM (Erlang VM) using purerl. You get the legendary resilience of Elixir/Erlang actors, but with absolute compile-time type safety.
You want raw, bare-metal computing speed for heavy algorithms? Transpile to Scheme using purescm, which leverages the formidable Chez Scheme compiler to come very close to C/C++/Rust-level performance on recursive and computational tasks (thanks to 30 years of research by Cisco).

Your core domain (your algorithms, parsers, state machines, and business rules) does not change by a single comma. Yes: not, a, single, comma.

Of course, your target language can and should influence what PureScript will offer to be transpiled into it. And the level of abstraction and generality given by PureScript is directly the one of Category Theory: you will almost certainly find the right tool for each problem. That's a permanently bidirectional dialogue between the two sides, maintained by great developers from the community.

E.g. Aff will be translated into async/await in JS, or Revolt and Fiber internals in PHP.

The Haxe paradox: Why did it stall?

This "compile to anything" promise sounds familiar. In the 2000s and 2010s, languages like Haxe tried to be the ultimate Swiss Army knife, compiling to C++, Java, PHP, and JS. While Haxe became a massive success in the indie gaming industry (shoutout to Dead Cells), it never conquered the mainstream backend or frontend world.

Why? Because of the Lowest Common Denominator Syndrome.

Haxe is an Object-Oriented, imperative language. It tried to abstract the world by forcing its own Standard Library onto every target. When you compiled Haxe to C++, you didn't get idiomatic, lightning-fast C++: you got C++ weighed down by a Haxe garbage collector. When you compiled to JS, you got a heavy runtime overhead. You lost the native superpowers of the target platform.

Furthermore, from a paradigm perspective, Haxe offered nothing that Java, C#, or TypeScript didn't already have. Why use a cross-platform layer when native tools do OOP better?

Haxe felt counterproductive for some. It may have suffered from Esperanto syndrome. A universal system must include its parts without replacing them (not blindly, at least), so that it can grow alongside them.

The PureScript epistemology: purity as a boundary

PureScript succeeds where Haxe stalled because it adopts a radically different philosophy: Symbiosis through Purity.

PureScript does not try to replace the native ecosystem. It fully respects it. And it grows with it.
Because PureScript is strictly mathematically pure, its compiler doesn't need to inject a heavy "PureScript Virtual Machine" into the target code.

Zero-Cost Abstraction: PureScript Arrays compile to native JS Arrays. PureScript Strings are native Strings. The integration is seamless.
The FFI Philosophy: PureScript knows it cannot do database I/O or DOM manipulation natively. Instead of faking a universal HTTP library that runs poorly everywhere, the culture encourages you to use platform-specific Foreign Function Interfaces (FFI).

You write your business logic once, in 100% pure code. Then, you plug in the right FFI. And don't worry about rewriting the world from scratch: the core kernels and standard bindings have already been written by the community for each runtime! And for libs: if you target Node.js, you plug in purescript-node-postgres, if you target Erlang, you plug in purescript-erl-epgsql.

Conclusion: the ultimate alchemy

The dilemma of hybrid technologies is the risk of creating a gray mush, a tool that loses the qualities of both its parents. In software engineering, attempting to support everything often results in a mediocre middle ground: a language that is not as fast as C, as expressive and safe as Haskell, etc.

Don't worry. In this case, the spoon is shaped like mud, but it's just that PureScript might play a prank on you! 😉

In reality, being in the middle should not necessarily imply losing quality. PureScript completely avoids this gray mush by refusing to mix the substances until the very last second. It takes the absolute mathematical rigor of Haskell (substance A) and respectfully marries it to the omnipresence of V8, the resilience of BEAM, or the speed of Scheme (substance B). The substances remain as they are, they just work together so closely that one can still speak of hybridization.

No matter what the people who encounter your product prioritize (speed, safety, concurrency...), you can now rest easy and know your language inside and out.

Needless to say, no single runtime is perfect for everything. In practice, PureScript acts as the unified, overarching language for your entire project, but your transpilation targets can differ from one folder to another. That is the whole point: every pillar of your architecture gets its own privileged runtime. For instance, your background workers and core algorithms can be transpiled to Chez Scheme for raw, bare-metal speed; your real-time WebSocket brokers can compile to Erlang's BEAM for flawless, distributed concurrency; and your user-facing API can run on highly-optimized Node.js.

It is not a downward compromise. PureScript is an epistemological little friend that protects your code, your thinking, from the chaos of the outside world, while letting you choose the exact engine you want to power it. It's made for that. It isn't afraid of movement. It encourages you to use the best runtime for your goal, without having to learn yet another language, right now.

But wait, if you have a Node.js API, a Chez Scheme worker, and an Erlang broker, how do they communicate safely? In a traditional microservices architecture, you would immediately reach for gRPC and Protobuf to enforce a strict, language-agnostic contract between these radically different environments.

Here is the magic of a runtime-agnostic language: PureScript itself is your contract.

Because your entire architecture shares the same PureScript domain types, you get the absolute safety of gRPC combined with the developer comfort of a TypeScript monorepo. Whether your containers communicate synchronously via simple HTTP or asynchronously via RabbitMQ, they serialize and deserialize JSON payloads using the exact same PureScript definitions. The compiler guarantees that all your microservices speak the exact same language, eliminating an entire class of distributed system bugs without any heavy external schema configuration. In this paradigm, gRPC is relegated to being a pure performance optimization for extreme high-throughput binary transport. It becomes entirely unnecessary for 99% of projects.

The quiet rewrite of the web is expanding, but it does not stop at the browser window. It is coming for distributed systems, heavy data pipelines, and bare-metal computations. By allowing developers to decouple their business domain from the physical execution engine, PureScript is silently shifting the power dynamics of software architecture.

We no longer have to compromise between safety and performance. We just have to choose the right form for the right environment.

It’s a long-term endeavor, underway on all fronts: academic and theoretical, as well as practical and industrial. But it’s an endeavor in which the progress made has now become so significant that it allows us to (re)discover the joy of doing this craft.

Say Hello to your little polymorph, say Hello to PureScript.

P.S. Oh, and I almost forgot: a little concrete code never hurts! If you want to see what a production-ready PureScript project looks like in practice, check out this example repository, when our little polymorphic friend wants to take the form of Node.js by day and PHP by night:

👉 PureScript Fullstack example (Node or PHP, whatever the runtime)

Also find a multi-runtime benchmark here:

👉 Purescript universal multi-runtime benchmark

🍄 The End of Developers in 2026? Elon Musk is right... but wrong.

Kevin 心学 — Mon, 09 Mar 2026 15:02:27 +0000

AI can generate code. But code is not just syntax: it’s a language for thinking about systems. It’s time to clarify why.

In recent years, discussions about software development automation have multiplied. Some technology leaders, such as Elon Musk, claim that developers could disappear. At first glance, this idea seems radical: if AI can generate code from simple natural language instructions, why would we still need developers? It could generate machine binaries too.

Yet this reasoning relies on a very narrow definition of code, where code is seen purely as a translation process, an intermediate step in a production chain:

Natural human idea --Developer--> Code --Compiler--> Phenomenon in the machine world

In short:

Ν --Δ--> C --Κ--> Μ

And we all know that AI (Α) and the compiler (Κ) help us in writing code:

Ν --Δ+Α+Κ--> C --Κ--> Μ

In this sense, coding is only about transforming human ideas into executable binary instructions. On this ground, Musk is probably right: many repetitive or syntactic implementation tasks could indeed be automated.

Ν --Α+Κ--> C --Κ--> Μ

And AI could even do a better job than any compiler (as he said himself). So:

Ν --Α+Κ--> Μ

Ok… that may happen to a lot of companies. Musk may be right.

Note that in this picture, we've lost control. We cannot see what's going on in the machine… Because that was one of the many advantages of traditional code. Right? But anyway, that's another topic.

Let's discuss another aspect of things, and see where Musk is wrong.

The Missing Definition

These debates are very often truncated by a cut (sometimes accidental, sometimes deliberate) in the definitional scope of what we call "code".

Let us put aside announcements, speculative interests, and stock prices for a moment, and focus instead on the definition.

In my experience with functional programming (which I have studied for two years), I (re)discovered another dimension of code. Something absolutely essential.

Here, coding primarily means formalizing an idea, modeling a domain, expressing invariants, and structuring a complex system. In this perspective, code becomes an intermediate symbolic language, a tool for thought, not merely a translation to the machine.

Code as Maths

In FP, code is absolutely not reduced to a translative layer from one language to another, from one world to another. It is an extensive layer of language itself. It is then transpiled (e.g. PureScript → JavaScript).

Ν --Δ+Α+Τ--> Σ --Τ--> C --Κ--> Μ

And here comes the difference. We cannot prune the chain the same way we did before (i.e. remove Δ):

Ν --Α+Τ--> Σ --Τ--> C --Κ--> Μ

Why? Because Σ is a extension of Ν. Not a translation, not another shape, not another physicality we give to a substance. This is the substance itself, going further: Σ > N. It is there to express what Ν cannot express. And guess who does the expression job? Δ. The delta. The difference. The added value. The developer.

AI cannot generate human knowledge outside of humanity. If AI generates Σ autonomously, with tangible results, humans will be interested in knowing them. They will want to know the formula, the symbols that are useful to manipulate reality. There will always be Bob, to check a generated idea. His Σ will then become his new N, and a new cycle of territory extension will begin. It will give him more power on reality. And people who have been ignoring their Σ (letting it to AI) will try to imitate Bob's one, will learn his Σ (which became his N). His Σ will become the new N, for everyone. AI will never generate an everlasting and independent Σ, with no human to catch up with it.

Note that these assumptions are based on an ideal world, where AI is truly capable of validating its Σ ideas. Current practice shows something different. It can barely iterate through several validation cycles by attaching itself to your browser to validate the visual reality of your website. It is impressive, but it is still imperfect. And it is pure 2D virtuality. Nothing to do with reality and 3D-world human stakes.

There will always be Σ. There will always be the need to compress ideas or express something new and interesting for the rest of humanity. We need someone to understand the move: that will not come from the entirety of the group, at the same time. Experts are, in my humble opinion, consubstantial to humans. They will always be there. As long as Ν exists, Σ will exist.

Ν is indeed a social convention. It can grow, it can extend its limits. And Σ is in fact one of the many special corners of Ν. Like math vocabulary, like biology vocabulary… Ν and Σ are two faces of the same cube, and cannot be dissociated. We can invent, with AI help (but only help, by definition), ways of expressing intuitions of Ν into Σ, or vulgarize Σ into Ν. But Ν and Σ are none of AI's real business; they are the very core of human ideas, desires, viewpoints, and knowledge. And they work hand in hand:

[Ν <~~Δ+Α+Τ~~> Σ] --Τ--> C --Κ--> Μ

Σ is richer than English N. More compact, declarative, and precise than traditional code C (it focuses on what, not how).

In Musk’s world, companies will add value if they bring Ν in:

Ν --Α--> Μ

The more efficient they are in providing Ν and helping Α to translate, the more they will succeed. That's why we see numerous tutorials to help us speak to AI, in a sort of infinitely recursive (and sometimes absurd) loop. Just to improve the final Ν in the chain. Of course, the diagram goes far beyond something linear, and becomes indigestible (and costly).

But.

Us humans will still persist information within groups, and make tech companies, to produce Μ. In the FP chain, we can play on Σ, not Ν. That is necessary to add value.

Here, should we call Σ "code"? In my opinion, yes. Because it is not Ν, it is not C or Μ. It is technical, read on screen. It just not the traditional intermediary layer it used to be.

Eliminating code, in this respect, would mean reducing the added value. This is obviously not what the industry prefers.

Code as Expression

It is here that expression becomes central to the modern definition of code. Code is no longer just translation. It is the terrain for expressing particular ideas, with a strong epistemological dimension.

This is exactly what languages like Haskell or Rust enable: code becomes almost an executable specification rather than a mere sequence of instructions. The ability to model and formalize is far more resistant to automation than simple syntax writing.

The AI Wave

In other words, your "protection" against the AI wave lies in your ability to think and formalize a problem correctly. If your language gives you that power, this is the way to go.

Musk is both right and wrong.

He is right with the traductive flavour of code definition.

He is wrong with the expressive flavour of code definition.

The good news is that in this expressive sense, the role of developers remains central. It simply changes in nature. I am inclined to think that this reasoning can and should extend beyond FP.

The rules have changed. But human, expression and "code" are still at the heart of the game.

In the AI village, you'll never be the fool.

🪽 A quiet rewrite of the Web: PureScript on the rooftops of JavaScript

Kevin 心学 — Mon, 27 Oct 2025 13:14:11 +0000

JavaScript became more than code: a culture, a dynasty, a paradox. In the shadow of this legacy, a bold team embarked on an athletic, and deeply inspiring adventure: rewriting everything…

For over decades, web developers have lived in a love–hate relationship with JavaScript, and this has affected their own sense of community, with internal disagreements turning into verbal altercations, sometimes brutal and cruel.
These are the facts. We criticize it, we mock it, we reinvent it, and yet, we often (if not always) come back, partially or not.
Because, deep down, the web is JavaScript (or almost): the lingua franca of the browser, the keystone of everything that runs inside a tab.

And yet… between the endless undefined is not a function, the inconsistent APIs, and the jungle of an evergrowing ecosystem (which can sometimes be overwhelmed by his proposals), it’s hard to find a line of reasoning that makes lasting sense.
So we look for escapes: CoffeeScript yesterday, TypeScript today, Elm or Reason for the boldest.

And now… there’s PureScript, a quiet language (but one of rare elegance).

I know I know, you may be suffering from JS fatigue, like I was (“oh, more promotion from an official team member, infiltrating dev.to…”), and you’re thinking that it’s irrelevant to come up with yet another thing in this saturated universe.

But.

I am a freelance developer, and I do not do any promotion.

That’s when things start to take a turn toward something completely different. It’s not just a thing, a tool, a framework, a bundler… or even a mere language. It’s a parallel universe, both independent and connected, which stands on the shoulders of profound epistemological mathematics. We’ll get back to that.

JavaScript, the Dynastic Dystopia

Let’s face it: JavaScript has won.
It reigns over the web like a dynasty: (almost) uncontested, omnipresent, eternal.
From browsers to servers, from build tools to mobile apps, a lot of things eventually bends to its rule.

But it’s a dynasty with a dystopian flavor: a vast, prosperous empire, yet inherently unstable.
Each new framework promises order and simplicity, but also sows significant additional chaos. Nothing seems to be completely resolved. This is probably what contributes to such dynamism, but it is also what can unnecessarily exhaust some people.
Dependencies multiply, paradigms collide, and peace always seems one npm install away.

You can’t leave this empire, the web is its territory. It holds up, and it does the job, which is no small feat (far from it). And no one is rude enough to claim that there isn’t wonder in many places within this ecosystem.
So what remains?
The art of navigating it: creating your own bubble of confidence, and diving into it fully, without fear.

That’s where Purescript comes in.

PureScript: Haskell for the Great Web (and more)

PureScript is a purely functional language (strongly) inspired by Haskell, compiling down to plain and optimized JavaScript. As such, it encapsulates all the power of Category Theory (remaining dev-oriented), and still can run on browsers, desktop (e.g. Electron), backend (Node), etc.
N.b. Because the subtleties of Node's Event Loop are misunderstood or disliked by non-JS devs, Haskell is sometimes preferred for backend purposes. PureScript has now made these subtleties much easier to handle.

In practice:

Strong static typing, everything is checked before runtime. Functional purity, no hidden side effects.
Readable, efficient output, no black magic.
Powerful type inference, the compiler often knows your intentions before you finish typing.
Algebraic data types and pattern matching, express complex logic elegantly and safely.
Effect system, explicit control over side effects, concurrency, and async behavior.
Extensible records and row polymorphism, flexible data structures without sacrificing type safety.
Typed foreign function interface (FFI), seamless bridges between PureScript and JavaScript.
Ecosystem synergy, works hand-in-hand with frameworks like Halogen, React Basic, or Concur.
Small, composable abstractions, build large systems from simple, predictable parts.
Mathematically grounded, category theory isn’t decoration here; it’s the backbone.
Cross-platform by nature, browser, Node.js, Deno, Electron, Cloudflare Workers, it just runs.
And… so much more. It’s another world…

PureScript lets you reason about your code with mathematical precision, while still building modern, reactive, performant apps.

It’s the Hextech gem from the Arcane series, the philosopher’s stone, allowing clarity to emerge from a world saturated with conflicting forces.

Writing JavaScript without suffering from it

Take asynchronous effects, for example.

In JavaScript, Promises are convenient but quickly spiral out of control, nested callbacks, silent errors, ghost exceptions.
In PureScript, effects (Effect, Aff) are described and typed explicitly.
No more partial functions. The compiler knows when you’re touching the outside world, and makes you handle it properly.

And yet, you’re still within the JS ecosystem: you can import npm libraries, use React through Halogen or React Basic, or even handcraft JS interop directly. You’re not lost.

PureScript doesn’t flee the dynastic dystopia: it reveals islands of long-lasting structure within it, and ensures their sustainability, development, promotion, expansion, and scaling.

The Art of Compromise: Purity without the Ivory Tower

One of the most compelling aspects of PureScript is that it does not force you to pick a side.
You do not have to choose between the pure, safe, and elegant and the flexible, fast, and pragmatic.

PureScript offers a genuine compromise, perhaps the smartest one seen around this duality.

I’ll let you write everything you love about functional programming (strong typing, purity, composition…), but I won’t lock you in an ivory tower.
If you want to use JS libraries, APIs, or even write some JS yourself, you can.
Just declare a foreign import in one line.
I want you to do things because you understand why, not because I force you to.

This isn’t a weak compromise, it’s a collaboration between two worlds.
You don’t sacrifice native safety or pragmatic flexibility, you make them work together through anti-corruption layers.

There’s no need to throw away your JS experience or deny your love of functional purity.
You can do both, and this upward hybridization is deeply promising: the very best of both world is kept intact.
No downward mixing, no sacrifice, no ideological war between paradigms: just a fluid membrane, allowing the boundary to shift, sometimes to 100% PureScript, sometimes close to 100% JS, if you feel so.

Instead of turning the table upside down, PureScript ensures continuity, compatibility, and a transition without violence.
You could write X(< 100)% of your code in PureScript, and the rest in JS without guilt or pressure.

It’s a rare philosophy: a language that values not just purity, but maturity.

Conclusion: the Web as a playground, not a prison

JavaScript has become the universal runtime. You can’t escape it.
And that’s perfectly fine, as long as you can really choose how to enter it.

TypeScript tries to make JS less dangerous by adding safeguards. And we can thank it for that.
PureScript, on the other hand, comes from a different world, the purely functional one, and builds a bridge to JS. There is no interference, no hidden language design isomorphism, no subconscious mental pollution.

It took me almost 2 years to understand a satisfactory portion of these lands, even in its most remote regions. I read almost every night on this. This is not a small episode: it is an endless series, full of academic work in progress. In any case, the front door is now increasingly easier to open, thanks to high-quality courses made by enthusiasts, and what seemed impossible yesterday has become reality today.

PureScript offers a rare path to achieve your ends with JS: to harness its power without inheriting its potential chaos, to turn its flexibility in a plain quality, to create without betrayal, and to rediscover the joy of writing code where every line does what it says, and says what you think.