peterkelly

Now all the malware can move from the install script to the module itself where it will inevitably still be run

If only there were some kind of system for recording the version history and viewing what changes had been made to the code between releases.

PhD in Computer Science with 15+ years experience bridging the gap between the worlds of compilers/interpreters and scientific & business workflow orchestration systems. The world deserves better languages and developer tooling and it's my mission to continue exploring what's possible.

Location: Chiang Mai, Thailand

Remote: Yes

Willing to relocate: No

Technologies: Compilers, interpreters, language runtimes, distributed systems. Rust, Python, C, C++, TypeScript, Postgres.

Résumé/CV: https://www.pmkelly.net/resume.pdf

Email: peter@pmkelly.net

I've always been of the view that for a workflow language, you should use a proper, turing-complete functional language which gives you all the usual flexiblity for transformations on intermediate data, while also supporting things like automatic parallelisation of things like external, compute-intensive tasks.

I recommend checking out https://github.com/peterkelly/rex and also my PhD thesis on the topic https://www.pmkelly.net/publications/thesis.pdf.

The gap in flexiblity between DAG-only and a full language designed for the task is a significant one.

Every single one of them oversells their capacity

That sounds like their problem, not ours

Unless a violation of that contract can lead to a crash or security vulnerability...

The most important one in the context of 2025 is this one:

On the foolishness of "natural language programming". https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

Flagged because this takes you to a random website so everyone is going to be reading a different article.

I love Kagi as a search engine, and this is a cool idea, but posting a "random web page selector" without explanation on HN is just confusing.

For some people it's a job.

For others it's a calling.

Nothing wrong with either - I just think it's worth being aware that people have different motivations.

Why do all the AI agents on the services page have human names and profile pictures if there are "no humans in the loop"?

There was a post on HN the other day where someone was launching an email assistant that used AI to summarise emails that you received. The idea didn't excite me, it scared me.

I really wish the tech industry would stop rushing out unreliable misinformation generators like this without regard for the risks.

Google's "AI summaries" are going to get someone killed one day. Especially with regards to sensitive topics, it's basically an autonomous agent that automates the otherwise time-consuming process of defamation.

Create the problem, sell the solution.

I thought vibe coding tools did this already

If there's one thing I definitely don't want AI in the middle of, it's communication with other people. The potential for misunderstandings due to hallucination in summaries, both on my end and the recipient's, scares me. There were some pretty bad examples with Apple News.

Accuracy matters, especially when communicating with customers or between managers/employees, and I can imagine many kinds of scenarios where this goes wrong.

I'm honestly curious why Apple (and other OS vendors like MS and various Linux distributions) still feel the need to tweak their UIs many, many years after having reached maturity.

How many iterations does it take before you get it right?

I get that there's a certain sense of fashion to it, but so often these changes are either neutral or worse, and it just seems so pointless. I don't see any concrete benefits of this year's UI design over what was already there 10-20 years ago.

If AI coding agents were actually any good, you could preface your prompt with "attempt the following task four times in parallel" and that would be it.

The mystification section was my favorite part - you make some excellent points there.

Sounds like you need a better partner

The author is the co-creator of Go, Plan 9, UTF-8, and the first Unix windowing system.

Whatever you may think of his arguments or slide templates, I don't think "innocent bystander" is an accurate label.

There's certainly a tradeoff between the two approaches; a simpler representation (list of tasks or DAG) is easier to query and manipulate, at the cost of being less expressive, lacking features like loops, conditionals, etc.

In the workflow engine I described, state is represented as a graph of objects in memory; this includes values like integers/strings and data structures like dictionaries/lists, as well as closures, environments, and the execution stack. This graph is serialised as JSON and stored in a postgres table. A more compact binary representation could be added in the future if performance requirements demand it, but JSON has been sufficient for our needs so far. A delta between each snapshot is also stored in an execution log, so that the complete execution history is stored for auditing purposes.

The interpreter is written in such a way that all object allocation, object manipulation, and garbage collection is under its control, and all the data needed to represent execution state is stored in a manner that can be easily serialised. In particular, we avoid the use of pointers to memory locations, instead using object ids for all references. So the persistent state, when loaded, can be accessed directly, since any time a reference from one object to another needs to be followed, the interpreter does so by looking up the object in the heap based on its id.

Non-deterministic and blocking operations (including IPC receives) are handled outside of the evaluation cycle. This enables their results to be explicitly captured in the execution log, and allows for retries to be handled by an external mechanism under control of the user (since retrying can be unsafe if the operation is not idempotent).

The biggest win of using a proper language for expressing the workflow is the ability to add arbitrary logic between blocking operations, such as conditional tests or data structure manipulation. Any kind of logic you might want to do can be expressed due to the fact the workflow language is Turing-complete.

Durable execution is best done at the level of a language implementation, not as a library.

A workflow engine I recently built provided an interpreter for a Scheme-based language that, for each blocking operation, took a snapshot of the interpreter state (heap + stack) and persisted that to a database. Each time an operation completes (which could be after hours/days/weeks), the interpreter state is restored from the database and execution proceeds from the point at which it was previously suspended. The interpreter supports concurrency, allowing multiple blocking operations to be in progress at the same time, so the work to be done after the completion of one can proceed even while others remain blocked.

The advantage of doing this at the language level is that persistence becomes transparent to the programmer. No decorators are needed; every function and expression inherently has all the properties of a "step" as described here. Deterministic execution can be provided if needed. And if there's a need to call out to external code, it is possible to expose Python functions as Scheme built-ins that can be invoked from the interpreter either synchronously or asynchronously.

I see a lot of workflow engines released that almost get to the point of being like a traditional programming language interpreter but not quite, exposing the structure of the workflow using a DAG with explicit nodes/edges, or (in the case of DBOS) as decorators. While I think this is ok for some applications, I really believe the "workflow as a programming language" perspective deserves more attention.

There's a lot of really interesting work that's been done over the years on persistent systems, and especially orthogonal persistence, but sadly this has mostly remained confined to the research literature. Two real-world systems that do implement persistence at the language level are Ethereum and Smalltalk; also some of the older Lisp-based systems provided similar functionality. I think there's a lot more value waiting to be mined from these past efforts.

I dream of a world in which more investment is put into creating better programming languages and runtime environments than trying to use LLMs as a way of coping with the complexities of current systems.

And that's how you lose good developers

How do you persist execution state? Does it hook into the Python interpreter to capture referenced variables/data structures etc, so they are available when the state needs to be restored?

A PhD is a program to compete for academic prestige

That's true for some people but others have different motivations, such as learning useful skills so they can gain the ability to work on interesting problems in a given field.

Doing a PhD in PL can also help you get the kind of jobs you mentioned, and achieve more once you're there. For me, the most valuable I thing I got out of the process was extensive exposure to the literature, which has been useful in a range of contexts.

One of the most important papers in software engineering, which I believe everyone in this profession should read and internalize.

Every time I see another startup trying use LLMs for code generation I sigh in despair. As AI technology improves and becomes better at producing code, what looks like a win in the short term will end up creating more and more code that has been created without a human going through the necessary thought processes and problem solving steps to build the theory of the software as described in this paper.

It's also why its critically important for companies to do what they can to retain the people who built the software in the first place, or at least ensure there's enough continuity as new people join the team so they can build their mental model by working alongside the original developers.

Another great Dijkstra essay:

On the foolishness of "natural language programming".

https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

"Virtual Machines: Versatile Platforms for Systems and Processes" by Jim Smith and Ravi Nair is a great book on the topic.

Why not debate the points in the article on their own merits? Which parts do you agree or disagree with, and why?

The React team should have done their own language, rather than making it a framework/library. Then they could ensure the absence of side effects in rendering code, and had a better way of detecting updates. The knowledge about how to do this was already out there for many years before they started: https://en.wikipedia.org/wiki/Functional_reactive_programmin...