5 ms·

Alan Kay has been asking this question for a long time now. His "Viewpoints Research Institute" is doing some interesting work in this direction. http://vpri.o

by apu 18y ago

Alan Kay has been asking this question for a long time now. His "Viewpoints Research Institute" is doing some interesting work in this direction. http://vpri.org/ http://vpri.org/ One of their projects is to see if they can build a complete software stack -- from the OS through the GUI and networking/graphics libraries to end-user software -- all in 20,000 lines of code total. They have already made some major progress in the past few years. I highly recommend reading (or skimming) their progress report from last year. In addition to being quite impressive, it also has several cool ideas that I had not seen directly before: http://www.vpri.org/pdf/tr2007008_steps.pdf http://www.vpri.org/pdf/tr2007008_steps.pdf

david927 18y ago
I really applaud they're effort, and I'm an incredible fan of Alan Kay, but I think they're jumping the gun. They weren't required to change the stack. It's helpful, sure, but I think they should have waited until they hit beautiful enough technology that would require such a change (as beautiful enough technology will). And focusing on code size is possibly misleading, as code size does not exactly equal orthogonality.
- apu 18y ago
  I have to disagree on all counts. In roughly reverse order: focusing on code size is possibly misleading It's not the best metric, but it's close enough in this case. The whole problem is that large commercial (and some open-source) systems are in the millions of lines of code. What is all that code doing? code size does not exactly equal orthogonality One implies the other, at least in the way they've phrased the problem. Their goal is to build everything using only 20,000 lines of code. This means they have a strict overall budget and therefore cannot afford any duplication anywhere. They weren't required to change the stack You can't go from millions of lines to 20,000 by making incremental changes. The whole system from the ground-up has to be rebuilt with the code budget in mind. they should have waited until they hit beautiful enough technology that would require such a change They would be waiting forever. At some point, you have to dive in. Nothing good ever gets built without several iterations. Combine this with the fact that frameworks and languages are best built simultaneously with the applications that will use them (so that the levels of abstraction are correctly tuned), and I think their approach is perfect. By being forced to consider all levels of the stack, they achieve all of these goals. Incidentally, they're not hoping to get the system built in one go. They're "building [at least] one to throw away", as Brooks said. They are building a rough version of the system (over-budget on lines) to see where the problems are. Then, they will use this first system to build the real thing. At its heart, this project seems like an ideal way to do research into computing systems. Take on a daring project which will require many innovative ideas -- some small, some large -- while making sure that you're always tied to reality by having concrete goals and need to have some sort of a working system at all times.
  - david927 18y ago
    Thanks, Apu. I understood that these were their reasons and I certainly find them valid; we're talking about an amazing group of people here. What I was trying to say was: to be brave, That it wouldn't be about waiting forever. Jumping in is important but keep a wide perspective and be able to throw it all out, over and over again. What they're looking for isn't going to come incrementally from code size. They've been given a golden chance here and I think they should consider being brave enough to lose site of shore -- to go for broke. I think the Alan of the 1970's would have done that.
rayvega 18y ago
Yes he does. He recently asked the question, "Significant new inventions in computing since 1980", on Stack Overflow: http://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980 http://stackoverflow.com/questions/432922/significant-new-in... I like how he refuted most of the responses usually stating that a given invention was already invented at Xerox PARC in the 70s.

by apu 18y ago

david927 18y ago

I really applaud they're effort, and I'm an incredible fan of Alan Kay, but I think they're jumping the gun. They weren't required to change the stack. It's helpful, sure, but I think they should have waited until they hit beautiful enough technology that would require such a change (as beautiful enough technology will). And focusing on code size is possibly misleading, as code size does not exactly equal orthogonality.

apu 18y ago
I have to disagree on all counts. In roughly reverse order: focusing on code size is possibly misleading It's not the best metric, but it's close enough in this case. The whole problem is that large commercial (and some open-source) systems are in the millions of lines of code. What is all that code doing? code size does not exactly equal orthogonality One implies the other, at least in the way they've phrased the problem. Their goal is to build everything using only 20,000 lines of code. This means they have a strict overall budget and therefore cannot afford any duplication anywhere. They weren't required to change the stack You can't go from millions of lines to 20,000 by making incremental changes. The whole system from the ground-up has to be rebuilt with the code budget in mind. they should have waited until they hit beautiful enough technology that would require such a change They would be waiting forever. At some point, you have to dive in. Nothing good ever gets built without several iterations. Combine this with the fact that frameworks and languages are best built simultaneously with the applications that will use them (so that the levels of abstraction are correctly tuned), and I think their approach is perfect. By being forced to consider all levels of the stack, they achieve all of these goals. Incidentally, they're not hoping to get the system built in one go. They're "building [at least] one to throw away", as Brooks said. They are building a rough version of the system (over-budget on lines) to see where the problems are. Then, they will use this first system to build the real thing. At its heart, this project seems like an ideal way to do research into computing systems. Take on a daring project which will require many innovative ideas -- some small, some large -- while making sure that you're always tied to reality by having concrete goals and need to have some sort of a working system at all times.
- david927 18y ago
  Thanks, Apu. I understood that these were their reasons and I certainly find them valid; we're talking about an amazing group of people here. What I was trying to say was: to be brave, That it wouldn't be about waiting forever. Jumping in is important but keep a wide perspective and be able to throw it all out, over and over again. What they're looking for isn't going to come incrementally from code size. They've been given a golden chance here and I think they should consider being brave enough to lose site of shore -- to go for broke. I think the Alan of the 1970's would have done that.

rayvega 18y ago

Yes he does. He recently asked the question, "Significant new inventions in computing since 1980", on Stack Overflow: http://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980 http://stackoverflow.com/questions/432922/significant-new-in... I like how he refuted most of the responses usually stating that a given invention was already invented at Xerox PARC in the 70s.