580 karma · joined July 2, 2018
Another great introduction to Lisp is this blog post by Steve Losh: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
Not every program should be able to modify the compiler, the kernel, or the garbage collector :)
Hell no. Here is why:
1. The Common Lisp standard is brilliant. If your new Lisp is designed by anything less than a committee with people like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you will end up with something worse.
2. Common Lisp has one feature that people often forget about, but that is crucial for an operating system - you can rely on the fact that the semantics doesn't change. Lisp programs written in 1960 can usually be run on today's Common Lisp without modification, so there is hope that programs written today will still run properly even in centuries.
3. Common Lisp has the most powerful object system and the most powerful condition handling system. Both these features are invaluable for an operating system. This is actually my main motivation for contributing to this project. I want my programs to communicate via objects, and I want a system-wide mechanism for recovering from errors without crashing or unwinding the stack.
4. By relying on a very good existing language instead of reinventing this wheel, there is a chance that CLOSOS will actually get finished.
> I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system.
Probably. But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. And bolting that on top of SBCL without breaking existing things is about as painful as a full rewrite. The other big point is that SBCL values performance more than safety. But for CLOSOS, safety is crucial.
> Movitz
We intend to borrow some ideas from Movitz. But since we managed to bootstrap Common Lisp directly from Common Lisp, we hope that some things can be done more elegantly. The other project that should be mentioned here is Mezzano (https://github.com/froggey/Mezzano). We even borrow some code from Mezzano and are actively collaborating with its author.
I am one of the contributors, so please don't hesitate to ask questions or discuss ideas.
> other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers.
Common Lisp implementations don't need a JIT compiler to be fast. In fact, most of them don't use JIT compilation at all.
What makes Common Lisp implementations (especially SBCL) so fast is a combination of sophisticated static analysis, optional type declarations, and the fact that Common Lisp has been carefully designed to allow for high performance. I cannot stress how important the last point is. The Common Lisp standard is a contract between the programmer and the compiler writer that allows the former to write portable programs, yet gives the latter enough freedom to optimize.
In contrast, the language "standard" of Python doesn't clarify what portable programs may rely on. Instead, programmers tend to rely on the specific behavior of CPython. And reproducing the exact behavior of CPython is much harder than implementing a carefully designed standard.
> So it is a matter of having enough resources to throw at it.
No amount of resources can heal the design decisions of Python. The only way to get Python fast is by going through a painful standardization effort and by breaking some existing code. And I don't see that happening anytime soon. (Python 4 anyone?)
Common Lisp is probably in its best shape ever. There is finally a good package manager (https://www.quicklisp.org/), plenty of documentation (https://common-lisp.net/documentation), and active communities on reddit, #lisp and elsewhere (http://planet.lisp.org/).
There is and has always been a lot of FUD around Lisp, and Common Lisp in particular. You even mentioned a few examples. My explanation on why this is the case is that learning Common Lisp really takes some time and dedication, but our lazy brains try hard to avoid that and find silly excuses instead (Too many parentheses!).
> are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019?
If you manage to use Common Lisp in a project, you get an enormous boost to productivity. It is the best language for 'getting stuff done' that I know of. Even if you cannot use Common Lisp directly, knowing it will stop you from reinventing a lot of wheels. Greenspun's tenth rule is real.
In case you wonder how froggey managed to obtain a Common Lisp version of Quake, have a look at https://github.com/froggey/Iota.
1. It is ANSI standardized and mature.
2. Common Lisp programs are safe. Some implementations violate safety for performance reasons, but this one certainly won't.
3. Common Lisp has the best error handling mechanism that I know of (Conditions, handlers and restarts).
4. The language is programmable, both at the syntax level (Macros) and at the object level (CLOS with the metaobject protocol). So new ideas from other programming languages can often just be ported.
5. The language has been designed for interactivity and safe incremental redefinition.
6. Lisp has already been used very successfully for operating system development (https://en.wikipedia.org/wiki/Lisp_machine).
This makes it pretty much the ideal choice for such a project.
- We don't need separate processes if the language we use is inherently safe (e.g., modern Common Lisp).
- Without process isolation, it is possible to share large, complicated and possibly mutable data structures (graphs, arrays, user-defined objects) system-wide.
- Once it is possible to cheaply share and communicate arbitrary data structures, it is pointless to maintain designated 'file system'.
- Not having a file system raises the question of what data should be persistent and what shouldn't. But on a modern computer, it is feasible to just treat all data as persistent (maybe excluding the youngest GC generation).
The best news is that the author is actually working hard to implement this operating system. The first part - the Lisp implementation - is already in a pretty good shape and could be finished within the next two years: https://github.com/robert-strandh/SICL