HCI (Human-Computer Interaction), as an overall subject matter area. Keyboards and screen and mobile devices... they all grew incrementally from what came before, and people are used to it, but we can do better.
The AI-driven work these days has not actually re-imagined much. We're doing the same stuff, putting the same UIs on the same screens as we were before AI. It is faster, and the content is changing, but not the core interactions with devices. Do we need to output to screens? Do we need keyboards and mice and digital keyboards on phone as input mechanisms?
People are dabbling in VR and AR, and voice control. We're using watches a bit. And those are interesting directions, but some (VR and AR, mostly) of that hardware requirements comes with the baggage of awkward experiences and societal stigma, and often prohibitive costs for non-wealthy consumers.
I don't have the answers, I'd just encourage everybody to really ask yourself - is the goal I'm trying to achieve best solved by defaulting to the same "put it on a screen" UX as before, or can we do something completely new?
Like, all of it. People who decry it think of Wirth's original implementation but never the decades of (admittedly slow, Delphi was hardly blazing trails here...) improvements so they think it sucks. Pascal is great.
With AI, I think it's a future worth exploring. Great low-level and efficient string handling, unlike C.
Stupendously fast compiler and linker, and it generates code that's near C++/C/Rust performance with relative ease. Cram more useful features into it; keep the memory and pointer system as it is; add more useful language concepts from other places. Hell, strap an optional GC into it for things where you don't care.
Maybe I just got off on the wrong foot with Pascal. That was the one language I learned in school that I truly hated. At this point I don't really remember what implementation/compiler we used, but whatever it was definitely was pre-Delphi.
I am still in awe of Niklaus Wirth's Project Oberon: The Design of an Operating System and Compiler which includes source for everything from the hardware up and that too in a reasonable sized book - https://news.ycombinator.com/item?id=38869366 (this is the revised 2013 edition, get also the older 1992 edition which contains everything).
When browsers made their appearance as a "platform", i thought this is how they would be implemented, small, tight, fast, fully functional and everything running on a abstract machine. Instead we got the garbage that we have today.
“Space/time tradeoffs” I guess would be the name of it. Memory latency and bandwidth trails op/s of the CPU - operations beat fetches by ~2 orders of magnitude; memory complicates both SIMD and parallelism across cores which is another ~1 order of magnitude each. The back of the envelope suggests we left a 25,000x speedup factor on the table because our systems and tools and intuitions have converged on load-op-store-load-op-store, instead of load-op-op-op-[…]-op-op-store.
It is well past due time to revisit memory allocation from first principles. I recently finished my PhD on the topic, and realized that we have yet to agree on a consistent definition of fragmentation (see Wilson et al's seminal survey on "Dynamic Storage Allocation"), much less how to deal with it.
When I was in the trenches, I had constant cognitive dissonance against the fact that (i) "it's a solved problem" and (ii) low-to-no-malloc was often presented as a feature of low-level code.
My take is, train a SOTA deep learning system on solved static memory allocation instances (which is NP-complete already) and build a dynamic malloc on top.
Disclaimer: I've moved on past academia and I may have missed one or two breakthroughs. But the older the problem, the higher the probability of it staying open.
I'm not sure anybody has ever felt memory allocation was a solved problem. But more that it's a difficult one to do well for everybody.
You can build fancy balancing trees, heaps and all sorts to try and counteract fragmentation, but then you risk messing up cache coherency and you may spend a lot of time doing tedious busywork that can hold up real work.
What we have now is subobtimal for sure. Particularly if you come along and allocate huge swathes of memory in userland and then release it, only to re-alloc it. Huge page tables help a lot here, from the user/kernel side of things. But of course that is also not a perfect solution. Most apps don't want huge page tables as they don't map well onto normal things like browsing and listening to music. And so it goes; round and round.
I completely agree. In August I discovered the key to faster data transmission is better memory management. This allowed me to write a common protocol library in TypeScript that is about 35x faster than the current fastest implementation.
Due to a defect in my perf tool I eventually discovered that about 99.2% of processing time was spent on memory management, not instruction processing or network buffer. I was working in a high level garbage collected language, so I could not fine tune adjustments to pointers. Instead I got creative with call stack management and low level data frame header authoring. Now I am trying to replicate that success back to a low level http 1.1 implementation and it’s much more challenging.
Operating system design, and distributed operating system design (k8s falls well short of a distributed OS; it’s more like a toolkit that does the compute part)
Right. Before the web took off i believed distributed OSes (eg. Amaoeba, Plan 9, Inferno etc.) along with all sorts of OO middleware (eg. CORBA, DCOM etc.) would become the "standard" way to do distributed network computing.
Had that happened we wouldn't be wasting so much hardware today (old smartphones/tablets/laptops/etc.) but could have leveraged it all in a unified private network. Every single computer in my home would be now part of a distributed computing platform managed by a distributed OS.
The irony is that today the entire Cloud architecture viz. Docker, Kubernetes, REST etc. frameworks are actually recreating the above design!
Right, there is line of research that seems to have been nearly obliterated from memory, mostly for economic reasons. The cloud model is a more profitable flywheel -- it lets the platform keep control, charge money, and then use the money to develop more features.
And the open source cloud is a way for COMPANIES to collaborate, not people.
On the other hand, I would say there are still technical and fundamental reasons we're not using something like Plan 9, not just economic ones:
- Plan 9 was designed for LANs, not WANs. HTTP became the protocol of WANs, and the protocol of a (load balanced) client-server architecture, rather than something more peer-to-peer. So I believe that any of the systems you mentioned wouldn't be deployable that widely.
For instance, there's the NAT forwarding issue, and the fact that network deployment mechanisms like captive portals at hotels had to arise, which would limit a more peer-to-peer architecture.
(Though it's true that k8s is almost always deployed within a single fast cloud network.)
- The software world moves fast, and upgrading and compatibility are fundamentally hard problems. The cloud providers pay armies of SREs a lot of money to do this. The result is not what I like, but I have to admit they do a better job than what I do for self-hosted services!
So centralization does have inherent technical advantages. I'd like to think that there's some way around that :-)
---
A related point is that Apple invested in Bonjour / zeroconf back in the day, but I feel like a lot of the functionality and mindshare has been lost to the cloud.
I guess I do use this with Linux now! But in my case, it's fairly bare bones and doesn't feel that robust / debuggable. I'm curious what people with large, robust local networks do for naming.
Read: have FPGA-like reconfigurable hardware as a core feature. With the reconfiguring being as easy as starting an executable or changing a setting.
NOT: "stick an FPGA onto a CPU, upload 'kernels' to accelerate some task". I mean the platform itself being dead-easy to reconfigure, like change the workings of a particular CPU instruction on-the-fly, or have a # of processing elements encode/decode/process a data stream, reroute traffic from output A to output B by reconfiguring some multiplexer, etc.
Transistors are cheap now. Configuring logic as if it were a simple RAM matrix should be toootally doable.
Evolutionary programming. Very suited to goals and agentic stuff. I'd be surprised if it's not yet in production somewhere.
Procedurally generated content is also a lot more interesting. Without structure, you get slop.
You can set the beginning of a story and an ending, as well as a story contour. Then procedurally generate content that ends at these points, even if they seem to veer away.
Metaprogramming for similar reasons, things like writing scripts/languages for very specific problems.
There's good techniques for all these, but the ROI was too low compared to the returns. It was difficult to write tests for the output space, but now it's a lot simpler.
All types of unconventional/exotic computing. I think this has been criminally neglected ever since the ascendancy of the von neumann architecture digital computer.
Related: OSes based on persistent memory. As in: main RAM persists across reboots, distinction RAM <-> storage goes away, saving files & the whole concept of memory-mapped files can be tossed, code of any executable is always ready to jump to, etc.
I wonder if there are any modern languages that would be particularly interesting to make specific hardware for.
The only example I know of is the one that runs Java bytecode.
Add Forth to your list. There's 1 or 2 CPU's out there that came with a Forth engine in hardware (iirc). And there's some chips heavily optimized to run Forth systems (see eg. GreenArrays GA144. Sadly seems to be defunct these days?).
As for your original question: you might want to have a look at languages that overlap the border between 'traditional' PLs, and hardware description languages. Or hardware/software co-design, and tools used in that field. Edit: also see Oberon.
> The only example I know of is the one that runs Java bytecode
HCI (Human-Computer Interaction), as an overall subject matter area. Keyboards and screen and mobile devices... they all grew incrementally from what came before, and people are used to it, but we can do better.
The AI-driven work these days has not actually re-imagined much. We're doing the same stuff, putting the same UIs on the same screens as we were before AI. It is faster, and the content is changing, but not the core interactions with devices. Do we need to output to screens? Do we need keyboards and mice and digital keyboards on phone as input mechanisms?
People are dabbling in VR and AR, and voice control. We're using watches a bit. And those are interesting directions, but some (VR and AR, mostly) of that hardware requirements comes with the baggage of awkward experiences and societal stigma, and often prohibitive costs for non-wealthy consumers.
I don't have the answers, I'd just encourage everybody to really ask yourself - is the goal I'm trying to achieve best solved by defaulting to the same "put it on a screen" UX as before, or can we do something completely new?
Pascal.
Like, all of it. People who decry it think of Wirth's original implementation but never the decades of (admittedly slow, Delphi was hardly blazing trails here...) improvements so they think it sucks. Pascal is great.
With AI, I think it's a future worth exploring. Great low-level and efficient string handling, unlike C.
Stupendously fast compiler and linker, and it generates code that's near C++/C/Rust performance with relative ease. Cram more useful features into it; keep the memory and pointer system as it is; add more useful language concepts from other places. Hell, strap an optional GC into it for things where you don't care.
Maybe I just got off on the wrong foot with Pascal. That was the one language I learned in school that I truly hated. At this point I don't really remember what implementation/compiler we used, but whatever it was definitely was pre-Delphi.
Nice.
Brinch Hansen on Pascal Compilers - https://news.ycombinator.com/item?id=24913959
I am still in awe of Niklaus Wirth's Project Oberon: The Design of an Operating System and Compiler which includes source for everything from the hardware up and that too in a reasonable sized book - https://news.ycombinator.com/item?id=38869366 (this is the revised 2013 edition, get also the older 1992 edition which contains everything).
When browsers made their appearance as a "platform", i thought this is how they would be implemented, small, tight, fast, fully functional and everything running on a abstract machine. Instead we got the garbage that we have today.
“Space/time tradeoffs” I guess would be the name of it. Memory latency and bandwidth trails op/s of the CPU - operations beat fetches by ~2 orders of magnitude; memory complicates both SIMD and parallelism across cores which is another ~1 order of magnitude each. The back of the envelope suggests we left a 25,000x speedup factor on the table because our systems and tools and intuitions have converged on load-op-store-load-op-store, instead of load-op-op-op-[…]-op-op-store.
It is well past due time to revisit memory allocation from first principles. I recently finished my PhD on the topic, and realized that we have yet to agree on a consistent definition of fragmentation (see Wilson et al's seminal survey on "Dynamic Storage Allocation"), much less how to deal with it.
When I was in the trenches, I had constant cognitive dissonance against the fact that (i) "it's a solved problem" and (ii) low-to-no-malloc was often presented as a feature of low-level code.
My take is, train a SOTA deep learning system on solved static memory allocation instances (which is NP-complete already) and build a dynamic malloc on top.
To see where the static SOTA was a couple years ago, see this: https://arxiv.org/abs/2504.04874
And also my general audience-friendly presentation of it: https://cappadokes.github.io/jekyll/update/2025/07/16/welcom...
Disclaimer: I've moved on past academia and I may have missed one or two breakthroughs. But the older the problem, the higher the probability of it staying open.
I'm not sure anybody has ever felt memory allocation was a solved problem. But more that it's a difficult one to do well for everybody.
You can build fancy balancing trees, heaps and all sorts to try and counteract fragmentation, but then you risk messing up cache coherency and you may spend a lot of time doing tedious busywork that can hold up real work.
What we have now is subobtimal for sure. Particularly if you come along and allocate huge swathes of memory in userland and then release it, only to re-alloc it. Huge page tables help a lot here, from the user/kernel side of things. But of course that is also not a perfect solution. Most apps don't want huge page tables as they don't map well onto normal things like browsing and listening to music. And so it goes; round and round.
I completely agree. In August I discovered the key to faster data transmission is better memory management. This allowed me to write a common protocol library in TypeScript that is about 35x faster than the current fastest implementation.
Due to a defect in my perf tool I eventually discovered that about 99.2% of processing time was spent on memory management, not instruction processing or network buffer. I was working in a high level garbage collected language, so I could not fine tune adjustments to pointers. Instead I got creative with call stack management and low level data frame header authoring. Now I am trying to replicate that success back to a low level http 1.1 implementation and it’s much more challenging.
I think I have a very simple fix that solves fragmentation. Force the size of every buffer and every array to be a power of two. What do you think?
I think your fix suffers from severe internal fragmentation.
Operating system design, and distributed operating system design (k8s falls well short of a distributed OS; it’s more like a toolkit that does the compute part)
Right. Before the web took off i believed distributed OSes (eg. Amaoeba, Plan 9, Inferno etc.) along with all sorts of OO middleware (eg. CORBA, DCOM etc.) would become the "standard" way to do distributed network computing.
Had that happened we wouldn't be wasting so much hardware today (old smartphones/tablets/laptops/etc.) but could have leveraged it all in a unified private network. Every single computer in my home would be now part of a distributed computing platform managed by a distributed OS.
The irony is that today the entire Cloud architecture viz. Docker, Kubernetes, REST etc. frameworks are actually recreating the above design!
Right, there is line of research that seems to have been nearly obliterated from memory, mostly for economic reasons. The cloud model is a more profitable flywheel -- it lets the platform keep control, charge money, and then use the money to develop more features.
And the open source cloud is a way for COMPANIES to collaborate, not people.
On the other hand, I would say there are still technical and fundamental reasons we're not using something like Plan 9, not just economic ones:
- Plan 9 was designed for LANs, not WANs. HTTP became the protocol of WANs, and the protocol of a (load balanced) client-server architecture, rather than something more peer-to-peer. So I believe that any of the systems you mentioned wouldn't be deployable that widely.
For instance, there's the NAT forwarding issue, and the fact that network deployment mechanisms like captive portals at hotels had to arise, which would limit a more peer-to-peer architecture.
(Though it's true that k8s is almost always deployed within a single fast cloud network.)
- The software world moves fast, and upgrading and compatibility are fundamentally hard problems. The cloud providers pay armies of SREs a lot of money to do this. The result is not what I like, but I have to admit they do a better job than what I do for self-hosted services!
So centralization does have inherent technical advantages. I'd like to think that there's some way around that :-)
---
A related point is that Apple invested in Bonjour / zeroconf back in the day, but I feel like a lot of the functionality and mindshare has been lost to the cloud.
https://en.wikipedia.org/wiki/Bonjour_(software)
I guess I do use this with Linux now! But in my case, it's fairly bare bones and doesn't feel that robust / debuggable. I'm curious what people with large, robust local networks do for naming.
Reconfigurable computing.
Read: have FPGA-like reconfigurable hardware as a core feature. With the reconfiguring being as easy as starting an executable or changing a setting.
NOT: "stick an FPGA onto a CPU, upload 'kernels' to accelerate some task". I mean the platform itself being dead-easy to reconfigure, like change the workings of a particular CPU instruction on-the-fly, or have a # of processing elements encode/decode/process a data stream, reroute traffic from output A to output B by reconfiguring some multiplexer, etc.
Transistors are cheap now. Configuring logic as if it were a simple RAM matrix should be toootally doable.
Evolutionary programming. Very suited to goals and agentic stuff. I'd be surprised if it's not yet in production somewhere.
Procedurally generated content is also a lot more interesting. Without structure, you get slop.
You can set the beginning of a story and an ending, as well as a story contour. Then procedurally generate content that ends at these points, even if they seem to veer away.
Metaprogramming for similar reasons, things like writing scripts/languages for very specific problems.
There's good techniques for all these, but the ROI was too low compared to the returns. It was difficult to write tests for the output space, but now it's a lot simpler.
- https://en.wikipedia.org/wiki/Ternary_computer
- https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System
Plan 9 was cool.
The plan involving the raising of the dead?
Computer Lib / Dream Machines
Xanadu
Asynchronous digital design!
GUIs, quality, digital garbage: every version of a program is incompatible with the one before and require a new toochain to build and run, bloat
All types of unconventional/exotic computing. I think this has been criminally neglected ever since the ascendancy of the von neumann architecture digital computer.
1) The Zen of Exotic Computing by Peter Kogge - https://epubs.siam.org/doi/10.1137/1.9781611977295
2) Handbook Of Unconventional Computing in 2-vols (Vol1-Theory, Vol2- Implementations) by Andrew Adamatzky et al. - https://www.worldscientific.com/worldscibooks/10.1142/12232#...
Related: OSes based on persistent memory. As in: main RAM persists across reboots, distinction RAM <-> storage goes away, saving files & the whole concept of memory-mapped files can be tossed, code of any executable is always ready to jump to, etc.
Lisp Machines. And if you're a real freak, Forth Machines
I wonder if there are any modern languages that would be particularly interesting to make specific hardware for. The only example I know of is the one that runs Java bytecode.
Add Forth to your list. There's 1 or 2 CPU's out there that came with a Forth engine in hardware (iirc). And there's some chips heavily optimized to run Forth systems (see eg. GreenArrays GA144. Sadly seems to be defunct these days?).
https://en.wikipedia.org/wiki/GA144
As for your original question: you might want to have a look at languages that overlap the border between 'traditional' PLs, and hardware description languages. Or hardware/software co-design, and tools used in that field. Edit: also see Oberon.
> The only example I know of is the one that runs Java bytecode
https://en.wikipedia.org/wiki/Jazelle
Probably implemented in billions of ARM cores out there. Unsure how much use it sees though.
The Architecture of Symbolic Computers by Peter Kogge - Detailed Notes at: https://github.com/hlopko/architecture_of_symbolic_computers...
Languages not made for people that are optimized for tuned LLMs
What year does this forgotten concept come from, the 80s?
Analog computing
what fast and performant really means.
Love
How about giving a shit about efficiency?
That ship sailed when 64 bit OS took over!
Coding without LLM AI.
tech debt