Hi, I'm not sure this is such a big mistake —if at all.
Many people today believe software is as simple as it can be. They say "no silver bullet", see that the latest fad doesn't make things much better, and accept that most complexity is essential. Then the STEPS project gathers enough silver dust to forge *several* bullets, demonstrating that over 99.9% of software complexity is still accidental. This just sounds too good to be true. The most common objections are drivers and performance. Drivers are easy to brush aside, since they represent less than 1% of a complete OS. Performance however is not so easy: history (GCC, LLVM, JavaScript engines…) tends to show that performance requires complexity —lots of it. If you didn't push for acceptable performance, Frank would have been more feature-complete, but also less convincing. We *need* that conviction if we're going to make the future of computing happen at all. My model of you agrees with all of this, and should be happy with this choice. So I'm a little confused. Besides, you're not done, are you? Loup. On Sat, 2016-04-30 at 12:26 +0000, Alan Kay wrote: > Hi > > > > My major error in this project -- it turned out to be interesting, but > hurt one very important part -- was to switch goals in mid-project > from "running in real-time on a super computer" to "running in > real-time on a laptop". > > > "Real-time" meaning that all the interactive parts were within the > range of what humans expect when they deal with a user interface -- > i.e. a completely usable system. > > > This decision change happened because Dan Amelang's "Nile" graphics > was surprisingly efficient as well as being super tiny (< 500 lines of > Nile code). This got me thinking about doing live demos in talks, and > that some of this could help the design of the system. > > > However, it moved the pragmatics from "paying money for HW" and > working on the semantics (which was the original aim) to imposing > pragmatics in the software. > > > > We did get something quite impressive on a laptop, but ultimately I > think we didn't have enough cycles to both design/invent and optimize. > > > We had this problem at Parc when we couldn't replace the Altos in a > timely way. This led to some excellent software engineering, but the > new design and invention part got blunted. > > > Mea culpa! > > > Cheers > > > Alan _______________________________________________ Fonc mailing list Fonc@mailman.vpri.org http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org
