There are still people explaining to me why you need a 'system programming language' like C or Rust for certain tasks. Meanwhile, I'm playing a game of Quake on Mezzano, where everything from drivers to the actual videogame is written in pure Common Lisp.
In case you wonder how froggey managed to obtain a Common Lisp version of Quake, have a look at https://github.com/froggey/Iota.
That version of Quake is written in C and ran through a C->LLVM->CL transpiler. This is "written in pure Common Lisp" in the same sense that Emscripten applications are "written in pure Javascript".
Naughty Dog games (up to Uncharted) used to be written in a Lisp without garbage collection. The same guy then wrote the ITA flight search system. I think he may be the only productive Lisp programmer in the world.
Back in the 2000's, someone wrote a game debugging tool in Squeak Smalltalk which ran concurrently with the game (written in C++) it was debugging. It "cheated" on its garbage collection by shutting GC off. At the end of each game loop tick, it was modified so it just disposed of all objects which weren't manually marked "to keep."
That sounds like the best way to do GC in a game. Another way is to use explicit memory pools, remember to allocate from the right pool, and throw it all out at once.
General GC is really overrated I think. Automatic retain counting is nicer because it's deterministic and you never have to scan memory. Compaction can be nice but you can live without it.
I consult for a company that uses Common Lisp to design state-of-the-art network router chips. An e-commerce system that I wrote in CL powers my web site.
That depends on your definition of "written in." The transpiled Lisp code isn't at all what a human would or probably even could write. Don't forget about all those optimizations that get directly translated.
Its not unlike the 90's disasms. They compile. They work. But no human writes that kind of code that results when disassembling an optimized high level language's output.
"Someone" means a human, and that's where you are probably quite wrong.
The same point would then be that Overwatch or Assassin's Creed could be written entirely in Assembler "by someone", because a disassembler can output asm code that compiles to the exact binaries needed to reproduce it.
Yes, it can just like every other Turing complete language. Even Qbasic can do it this way. Let's get back to what a human "someone" can program in the language instead of these high level computer generated abstractions through Turing complete languages.
Waterloo Basic with all its crazy line numbers could do it entirely using PEEKs and POKEs with the logic you are clinging to. And it'll be just as unreadable as the interpreted LLVM is. And exactly as fast.
LLVM can be interpreted in Brainfuck. How far down the rabbit hole can we go before you interpret the whole thing in 1's and 0's? Crazy thought!
Try the conversion yourself and look at the results. It isn't anything like what a human could be expected to read and write. I use it often enough, and I can assure you I'd never want to be the chump who hopes to refactor it into realistic / maintainable Lisp code. What makes this useful at all is the already long-standing CLOS.
It serves its purpose. But you are over-glorifying the merits of the fact that Lisp is Turing complete like so many other languages that came after it.
Other people have already pointed out a speed penalty that I won't cover here. It works, but its not the OG... with enough time and effort, it could be. But for now, it isn't even close.
As a datapoint Quake is quite old. When it was released it used software rendering on a Pentium2. While is nice that everything from the ground up is written in lisp it sounds as if you are only achieving the performance of a P2 on modern hardware. What is the performance gap between Mezzano and an OS/application written in C/C++?
Folks are missing the point with performance. The Mezzano compiler + translating LLVM into Lisp wont be very efficient. That’s not the point. It’s crazy that a game like that runs on a non-Windows non-UNIX machine that is written from the ground up in Common Lisp, by way of compiling an application into a bunch of Lisp source code first.
I built it (circa 1996) on HP PA-RISC workstations, like HP-715's. There was no assembly code for those, just portable C. The frame rate wasn't great, but it played.
Both Quake 1 and Quake 2 ran fine on my Pentium MMX (and i guess regular Pentium since they didn't use the MMX stuff) using the software rasterizer and Quake 3 also ran fine on my Pentium 2 with a GeForce 2.
The reason it is slow is not because it is written is Lisp but because of how it is implemented, primarily because it is a hobby project. Graphics are rendered on the CPU for example.
I don't think it runs Linux, there is tons of embedded OS's.
It could be Nuclus, RIOS OS, or most likely, some sort of proprietary OS which was shipped with specific MCU they are using.
OS writing is pretty simple, as long as you do not need a ton of device drivers and networking. There are over two dozen of them listed there: https://en.wikibooks.org/wiki/Embedded_Systems/Common_RTOS and that is not a complete list.
My Samsung washing machine runs on (I believe) an mc6800 variant (not mc68000). It's admittedly not a surf-the-net/watch-tv-while-you-watch version, so no Quake, but on the upside, no viruses.
Curious, is this your main machine or a hobby machine? Regardless, I remember reading about this years ago (linked elsewhere for previous discussions on HN). Has it advanced to being more usable since? Interested to try it.
"Running on real hardware:
The hybrid image can be burned to a CD or dd'd onto a USB drive, and booted directly.
It requires a 64-bit x86 machine, 2GB of RAM, and a PS/2 keyboard and mouse."
I wonder if they can use this approach to convert and generate tons of tools for this OS. Build a POSIX layer, convert tons of useful unix tools using LLVM.
In case you wonder how froggey managed to obtain a Common Lisp version of Quake, have a look at https://github.com/froggey/Iota.