How many LISP books until...

[mrdelurk]

...one starts to have a clue how to program an OS?

OK, so I am a n00b. I went through the 600 page "gentle introduction" book, finished the vending machine simulator. So I could code a vending app now, but I don't really need one, Ebay is already invented. So I asked myself, "what I'd like to use this LISP knowledge for now"? Of top top of my head, only two uses hit me.

The first, writing a program to predict financial markets to make myself a kajillionaire would be a non-sequitur. What is there I couldn't predict already? The markets will keep going down, with the Fed announcing nebulous imaginary gain statistics. Do I need a program to tell me this? No. Chart the exact amount fibbed? 1% more than the last time. Done, still didn't need a program.

OK, let's try idea #2. How about writing an OS that doesn't suc... erm, vacuum attract? Like, an universal OS that would run on any bit-depth processors because before slinging the first bunch of bits anywhere, the OS would spend a couple of microseconds to determine (compare with yesterday's saved result) how many bits the processor uses and at what speed, and work from there. Same deal with all devices / peripherials / programs (as long as the CPU bit depth > program bit depth) so adios "drivers" and the need to update to a new OS just because new faster hardware. Learn the OS once, use it 40 years later on 1 million times faster machines. Running the same 40-year old program, if you want. Bill Gates would so hate me.

Except... having read the first book, I still have no clue how to start coding this idea #2. So realistically, how many more LISP books it will take before the fog starts to lift off? Thank you for all helpful insight.

[David Mullen]

I doubt anyone would get that far just by reading books. Learning a programming language is one thing, but to 'get' Common Lisp is to internalize the thinking that drove the evolution of the language in the first place. You do that by writing code, while familiarizing yourself with the standard and how it's implemented in compilers and interpreters—including how it relates to the operating system and the underlying hardware. (ANSI CL itself has no concept of an operating system, only the hardware and software configuration.)

As for writing an operating system—say, one that's more extensible, more habitable, whatever, thanks to Common Lisp—I guess there just isn't any money in it. I doubt anyone could get the GNU people, for example, on board with a Common Lisp operating system. The funding for a grassroots effort doesn't appear to be there, and in the industry it looks like all the money's in surveillance applications—I imagine that's probably the kind of thing AllegroGraph gets used for. Any big corporation (or intelligence agency) has piles of data about people and things and events, and they can analyze it with Common Lisp or declarative languages implemented in same—that's why these Lisp consulting firms are still in business. (Some of them, anyway.)

Recently Donald Fisk suggested in a post that it might be better to "dispense with the operating system altogether, and run languages and applications on the bare metal." That strikes me as a good starting point for thinking about this. Why do we need an operating system at all? What do we expect from it, and why? Is it feasible to build a "universal OS," or is an operating system inevitably something that's written specifically to take advantage of the features of particular hardware architectures? I don't have the answers—since I haven't been tempted to write an OS—but these are questions that don't get asked enough.

[mrdelurk]

Thank you for your reply, David. My issue with surveillance software is that there is only money in it as long as it doesn't give a clue.

Imagine if one actually did. And it would print something like: "You now hold 3000+ data points on every human, you are fighting ~12 wars, and losing all 12 for a yearly $2 trillion spent on things like me. My calculations suggest, for $1,999,999,999,999 less you could buy a little white $1 flag and just wave it at the outset at whatever country or social problem you thought of fighting. Exact same end result at significant savings." One could hear the "Screeeeeeeetchtssssssst!" as the software vendor contract is torn up.

My objective with the OS wasn't wealth, I was hoping for a work environment that can handle the inevitable bits, Hz's, flops growth without updates. IMHO "bare metal" could easily devolve into inconsistency where each program has a different UI for basic operations. I experienced that already at the dawn of the computer age, it did not seem very amusing.

[David Mullen]

While the "bare metal" approach wouldn't preclude adopting a standard library of interface elements, this whole concern about UI inconsistency never excited me much. Why shouldn't different applications look different? It never bothered me that (say) Mentor Graphics on Solaris doesn't look like XEmacs on Windows. The superficial differences between systems wouldn't matter so much if there were more communication and interoperation going on beneath the façade than there is now. But there's no question that people like consistency. They've voted with their wallets—so they'll stand in line some mornings outside the Apple store, just so they can have the same tribal fetish object that all their friends will have. That's the problem, though. Tastes change—collectively or otherwise—so although it may be possible to write a universal OS that will still work 40 years from now, I couldn't predict what people will expect an operating system to look like 40 years from now, even superficially.

[mrdelurk]

As far as people's expectations go, most users seem to prefer familiarity. So the UI people will prefer 40 years from now is likely to be a variation of today's windowing UI, derived from the Xerox PARC windowing UI of 40 years ago. "If it ain't broke, don't fix it" at work.

The real OS innovation would be to write a bit-independent kernel. Which provides bit-independent hooks to any element (devices, peripherals, programs) to get their 1's and 0's in and out, and converting bit depths and speeds between elements on the fly.

Want to use a 48-bit A/D converter to feed a digitized stream to a 32-bit program which processes a part through a 64-bit plugin under a 256-bit CPU? An OS that does this without the user even knowing anything special went on, now that's non-sucky in my book. Today's "buy new matching x-bit everything just because the OS bit depth doubled to x bits" status quo seems just... ripe for a redo.

[David Mullen]

Since that would amount to self-rewriting code, it's just a question of how you might take compiled code and convert each instruction to a higher-bit version. I don't know how far that could be automated, since I've written assembly language but I'm not familiar with the details of byte-level instruction coding. Either way, if newer hardware provides completely new instructions, then wanting to use them would require altering the translator itself. IBM's operating system has a virtual instruction set that allows translating compiled code to the underlying hardware's instruction set—but they still need to alter the TIMI translator in order to take advantage of new hardware features.