Hacker News Reader

Comment by heisig | Hacker News Reader

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.

View on HN

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".

Exactly. The output is indeed pure Lisp, but it isn't very human readable when transpiling anything more gumptious than Hello World.

It demonstrates that Quake could well be written in Lisp.

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.

There is a Portuguese company that does most of their products in Common Lisp, they have been in business for a couple of decades now.

https://www.siscog.pt/en/

https://franz.com/success/customer_apps/scheduling/siscog.lh...

> be written in a Lisp without garbage collection.

Gensym G2 is also written in a Lisp without GC. The Roomba software was written wit static memory allocation in a Lisp... it probably still is.

> I think he may be the only productive Lisp programmer in the world.

There are a bit more...

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.

Interesting! Do you have a link? A cursory search yields nothing for that, but I found this: Squeak Makes a Good Python Debugger[0]

https://www.timfelgentreff.de/public/uni/NiephausPX2017.pdf

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.

That depends on your definition of "written in."

The point being, that someone could code up a similar game and expect similar or better performance.

"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.

Or brainf*ck. Who's going to do that though, right?

I mean, sure why not? CL can be about as fast as C if all you care about is performance.

Also macros might get you faster than C, for the same reason that C++ can be faster than C (compile time metaprogramming).

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 think you forget just how old Quake is. I remember playing it on a 486DX 66Mhz, a P2 would have been total over kill for that game.

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.

P2 sounds about right for Quake2

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.

Are you thinking Quake III Rocket Arena?

*Quake III Arena

Rocket Arena is/was a mod

I sadly tried to run Quake on my 486DX 33, and it was not up to the task =(

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.

https://github.com/froggey/Mezzano/blob/master/gui/blit-x86-...

Unless you're playing it on a 75MHz Pentium, I think those people are right.

Quake? That's your reference point? That game came out in the 90s. My Samsung washing machine could probably run that.

Your Samsung washing machine probably runs Linux though. Can you run it on a non-UNIXy OS?

It’s amazing that this OS also has its own compiler and runtime capable of running Quake translated into Lisp.

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.

I don't know about you, but I rewrite all of my appliance firmware in chicken scheme.

That's basically C though ;)

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.

Better virus check that thing.

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.

from https://github.com/froggey/Mezzano/releases :

"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.

I’d imagine it’s more for driver support than anything.

Reply on news.ycombinator.com