A conversation with Alan Kay (2004)(doc.ic.ac.uk)
doc.ic.ac.uk
A conversation with Alan Kay (2004)
http://www.doc.ic.ac.uk/~susan/475/AlanKay.html
11 comments
They're putting out annual reports: http://vpri.org/html/writings.php
Recent HN discussion: http://news.ycombinator.com/item?id=3878661
Recent HN discussion: http://news.ycombinator.com/item?id=3878661
Thanks for the link to the recent HN discussion -- I missed that and it's very interesting.
The problem is scaling and complexity: if you have 100 interacting entities, and add one more, it increases complexity by a factor of 100x.
The solution is to subdivide it into modules that can be treated as a single entity. The complexity within each module is much less because there are fewer entities within it, and there is less complexity between modules because there are fewer modules (which can be seen as entities at a higher level - and we can nest modules, to further reduce complexity).
The problem with this is that it is hard to find the right modules, that minimize interactions within them and between them. It takes a lot of data, a lot of insight and a lot of trial-and-error to find modularities that work well - it amounts to a theory of the data. In science, most theories take a long time to be discovered and a long time to be improved on - but we expect to do this routinely on each individual software project...
[ One way this is done in practice is when someone decides to tackle a generally needed problem, and wrap it up as a component (e.g. 3rd party library). To the extent that this is the right modularity, it will not only reduce the work a user needs to do to use it, but also reduce overall complexity in the total system (including for the component designer). ]
Instead of expecting it to be easy to find the right modularity, we should expect it to be hard; instead of insisting on a simple theory that explains everything, we should celebrate every small step towards better theories. This is what all practitioners facing empirical complexity in the real world end up doing.
> I feel like my answers are quite trivial since nobody really knows how to design a good language, including me.
The solution is to subdivide it into modules that can be treated as a single entity. The complexity within each module is much less because there are fewer entities within it, and there is less complexity between modules because there are fewer modules (which can be seen as entities at a higher level - and we can nest modules, to further reduce complexity).
The problem with this is that it is hard to find the right modules, that minimize interactions within them and between them. It takes a lot of data, a lot of insight and a lot of trial-and-error to find modularities that work well - it amounts to a theory of the data. In science, most theories take a long time to be discovered and a long time to be improved on - but we expect to do this routinely on each individual software project...
[ One way this is done in practice is when someone decides to tackle a generally needed problem, and wrap it up as a component (e.g. 3rd party library). To the extent that this is the right modularity, it will not only reduce the work a user needs to do to use it, but also reduce overall complexity in the total system (including for the component designer). ]
Instead of expecting it to be easy to find the right modularity, we should expect it to be hard; instead of insisting on a simple theory that explains everything, we should celebrate every small step towards better theories. This is what all practitioners facing empirical complexity in the real world end up doing.
> I feel like my answers are quite trivial since nobody really knows how to design a good language, including me.
The idea of using those things has a common origin in the hardware of a machine called the Burroughs B5000 from the early 1960s, which the establishment hated...The problem was that the DP managers didn’t want to learn new ways of computing, or even how to compute. IBM realized that and Burroughs didn’t.
A good summary of many of the cultural impedance mismatches of Smalltalk. Even today, Smalltalk is weird. However, many of the things developed there now have widespread traction. Java, Python, Ruby, .Net -- these communities have adopted many of the great things from the Smalltalk world.
A good summary of many of the cultural impedance mismatches of Smalltalk. Even today, Smalltalk is weird. However, many of the things developed there now have widespread traction. Java, Python, Ruby, .Net -- these communities have adopted many of the great things from the Smalltalk world.
"Now we get around the efficiency stuff the same way Barton did on the B5000: by just saying, “Screw it, we’re going to execute this important stuff as directly as we possibly can.”
We’re not going to worry about whether we can compile it into a von Neumann computer or not, and we will make the microcode do whatever we need to get around these inefficiencies because a lot of the inefficiencies are just putting stuff on obsolete hardware architectures."
We’re not going to worry about whether we can compile it into a von Neumann computer or not, and we will make the microcode do whatever we need to get around these inefficiencies because a lot of the inefficiencies are just putting stuff on obsolete hardware architectures."
It's always a treat to hear Alan Kay go on about how smart Alan Kay is. Those were the days, I guess? Sorry about this whole PC-internet revolution thing.
I can see how he can come across that way. The progress that was made before 1980, of which we're entirely still surfing on, has to be connected with the simplicity and lack of patterns. It was like the 60's in music; no one knew what to expect so everything was possible.
On the other hand, considering the PC-internet revolution is all based on technologies that he and his colleagues developed, you should check yourself. Maybe if our industry had an ounce of history and a modicum of respect, we wouldn't be swimming in the mess we're in.
In my opinion, there's no one alive in this field that you should respect more than Dr. Kay.
On the other hand, considering the PC-internet revolution is all based on technologies that he and his colleagues developed, you should check yourself. Maybe if our industry had an ounce of history and a modicum of respect, we wouldn't be swimming in the mess we're in.
In my opinion, there's no one alive in this field that you should respect more than Dr. Kay.
Also, the PC revolution exploded so quickly that it fractured the hacker community which had fostered it. It took on a life of its own, and the very people that invented it have often publicly questioned the various directions it has taken since. While it could be taken as similar to saying, "I liked the Internet before it was cool", Kay's remark about Pop phenomena struck me as utterly insightful.
Ethernet was invented at parc. Viewpoints has both vint Cerf and david reed on its board...
I haven't seen anything come out of Alan's VPRI group for a while. Does anyone have an update?