The suggested gains (transparency, mostly) would not really be achieved, I think, because even if you get an 8:1 reduction in line count, it will still not look very transparent. It is still a very complicated problem.
And even if the performance of lisp approaches hand-crafted C, there will still be
More interesting is to design a different OS based on lisp using today's hardware. But what would you want it to do differently than Linux?
This is a refreshing change from the "The Linux kernel should use C++ more" that crops up every so often.
Despite it's refreshingness, it's still tiring to see these kinds of questions/goals. The Linux kernel is written what it is written in, by the people who wrote it. If you think it's a worthwhile thing to have it written in something else, patches will be entertained, and baring that, forks are acceptable.
Comments
The suggested gains (transparency, mostly) would not really be achieved, I think, because even if you get an 8:1 reduction in line count, it will still not look very transparent. It is still a very complicated problem.
And even if the performance of lisp approaches hand-crafted C, there will still be
More interesting is to design a different OS based on lisp using today's hardware. But what would you want it to do differently than Linux?
This is a refreshing change from the "The Linux kernel should use C++ more" that crops up every so often.
Despite it's refreshingness, it's still tiring to see these kinds of questions/goals. The Linux kernel is written what it is written in, by the people who wrote it. If you think it's a worthwhile thing to have it written in something else, patches will be entertained, and baring that, forks are acceptable.