Small is Beautiful (was Re: Immutable things)

[Fare Rideau]

Here are my top 7 reasons why Small Is Beautiful for an OS kernel:

(1) the OS can be semantically cleaner, which is most important for
 correctness proof, debugging, automatic program translation,
 performance (freedom of using nifty implementation hacks),
 portability, scalability, extensibility, upgradability, maintainability,
 documentability, learnability, etc
(2) Having a small kernel and lots of features implemented as modules above
 allows faster, finer-grained, more-reliable, parallel
 implementation and maintenance of the features.
(3) the OS can run on cheaper, smaller, simpler hardware,
 which is most important in markets such as poor man's computer,
 portable computer, palmtop computer, wraist computer,
 embedded computer, space-born computer, military computer,
 redundant computer, parallel computer,
 reversible computer, quantum computer, etc.
(4) Reflection is beneficial to the whole system,
 by trivializing issues of security, extensibility, and more,
 in a *performant* way.
 Reflection does require a small, semantically clean kernel.
(5) when features are put in modules instead of being builtin,
 the way they interact with each other needn't be overspecified,
 which is most important for performance, as well as all the above.
 Modularity allows for multiple implementations to be available
 with different interaction behavior.
(6) we will annihilate the last argument of C-pushers,
 that their lame language produces smaller executables ;->
(7) people who don't want a reflective system just not use it;
 everyone in the LispOS list will do what one wants anyway.
 Be constructive, do your own work,
 instead of whining and being doubtful about other people's.


Let's also answer a few messages on the topic:

>: David Gadbois
> I think the LispOS should cater to making it easier to write
> ambitious applications rather than making it easier to write the
> hardware support.
Reflection makes BOTH easier.
A non-reflective kernel also makes application writing more complicated,
because anything that ain't supported by the kernel
become a hell to implement, let alone implement efficiently:
let's say, orthogonal persistence; resource quotas and security
in a multiuser framework; GC guardians; real-time constraints;
linear typing; unification with arbitrary foreign VMs and languages ILU;
various language extensions; decoupled interfaces (braille, voice); etc.

> The payoff in applications for doing the hard work
> to make the system as a whole correct, consistent, and usable
>
This to me is an argument FOR reflection, not against it.

> vastly outweighs the one-time costs of system implementation.
System implementation is NOT a one-time cost.
You must constantly port the system, debug it, maintain it,
add new drivers, add new semantics, conform to new standards,
support new features, etc.
A monolithic kernel just makes that hellish. Reflection is needed.
Even Linux uses some reflection-like tricks in C to achieve some modularity.

> By making the kernel small, you make everything else huge.
That's a ridiculous claim!
I'd rather say that by making the kernel large,
you force every programmer to take lots of unwanted parameters into account,
and make programs larger.
A small kernel with lots of modules
is not intrinsically (much) larger than a monolithic kernel,
but allows smaller, better factored, applications.

Your example comparison of a 200MB linux system to a 30MB Genera image
just doesn't back up your claim. The real Linux kernel (OS+/lib+/etc+/bin)
isn't anything like small, modular, reflective, or integrated.
A fair comparison would be size of a modular Lisp system against
a non-modular Lisp system, both with the same user-level applications.
We'll see when we have such systems.


>: Kelly Murray
> the OS it is all shared by every application,
> so the size is not relevant anymore.
The OS is on each processor, so the size is important.
See those i960 clusters where half of each CPU's 16MB RAM is taken by OSF/1;
imagine a cluster of F21 processors, each limited to 1MW of DRAM;

> As I've said before, let's not try and refight the last C vs Lisp war
> (small and fast deliverables)
Why not? CL loses already. A Reflective Lisp will win.

> What it buys you is an easier job
> of doing porting and writing a correct compiler, and less time
> debugging/maintaining the core system.
Yes, among other things...

> If you're building from scratch, this is critical.
We are.

> But from my point of view, we already have ACL
> running, ported, debugged, so I'm not convinced.
As a Franz employee, you do have. We still don't. Unless, of course,
Franz is willing to release the source for free software use...

>: Dwight Hughes
> As has been pointed out by others, the various data structures of CL
> are powerful but most are quite heavy-weight, not a good match for
> working near the hardware. I think Henry Baker would call it "abstraction
> inversion" - the representation of lower-level, simpler structures
> using higher-level abstractions - quite inefficient, both in memory
> required and in performance.
>
I couldn't agree more. Nice expression: "abstraction inversion".

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"