This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Language Innovation
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
What is the criteria for innovating programming languages. I've always had a desire to invent a programming language, right from primary school some of my brain power has gone in to it. In fact, in Highschool I was unwittingly designing Object-Oriented programming. Not at all like Alan Kay had already devised. His model is far more interesting.
So when I hear Alan Kay say that it's a shame he had to use Smalltalk for Croquet, that leaves me a very puzzled and confused individual. Is 70's technology really that bad? And if it is the best we've got right now - what hope does that leave us for the future?
If we back track to the original conception of Smalltalk. It was made to serve a purpose - to help create the Dynabook - to help making programming about individual machines, not individual procedures. There are some core concepts in here. Does it leave much wriggle room? - Not really.
Alan himself says Lisp is kind of the panultimate language, they took lisp and expanded on the closure idea, making it a core idea. He always said he thought AI languages would be much bigger than they are right now.
One difference between they way Kay and his group made a programming language and the way most "Computer Scientists" make one is that Kay evolved the language. They got a system running and let it suggest changes to them. Modern language invention seems to be done by imagining the best colour paint for the hover crafts we one day may have, instead of realising that hover crafts may not need to be painted at all.
What this tells me is thaf if I were to make a new programming language, I should begin from a living system and let it change itself as changes become relevant.
Some changes that have poked their heads up time and time again in Smalltalk are concepts such as Traits, or Roles - where objects are split up in to more decisive units of behaviour, which are combined together to form a complete Object. Each individual set of behaviour is, also, a complete object.
What happens to the core Smalltalk libraries when we have such a concept? What happened to the core Smalltalk libraries when we had Traits for example? - For one thing, Iteration becomes a very cheap thing to implement. Anywhere you put #do: you can have the complete Iteration API. Another idea I've heard of it so have every object iteratable.
Some strange things begin to happen when you move code away. Object, for example, becomes some what more powerful than it is right now. Object, right now, is the ultimate abstract superclass. You can instantiate it, but not do much with it from there. Therefore, you subclass it and give it behaviour.
In a capabilities based system, the majority of behaviour in the system would be placed on Object. Security, 3Dness, Transactional State - the majority of systems that cannot interact together right now would all live on Object. What does this do to poor Object?
Object shouldn't be thought of as the root of all subclasses in this case. It becomes the thing that you call new on more and more. Subclasses of Object exist to hold different shapes of state. On another note.. would you ever need is* methods? perhaps some, but a lot less than you have right now. Often, is* is used to test a capability.
But what if Object had lazy instance variables? Instead of declaring your instance variables, any attempt to access one is created within the scope of the capability code. Therefore, instvar 'foo' in Security and 3d-Graphics don't access the same instvar.
If this were the case, subclasses of Object would only exist to change the memory shape of a class. eg: changing what it does when it writes and reads from memory. This opens up plenty of scope for interfacing with other languages. But is this the right pattern? What if you want to keep several language memory shapes in sync at once? is this a language concern or a library concern?
Since the act of reading/writing from memory differently is a language concern, but how you implement it is a library concept, it seems that there needs to be a more open relationship between the libraries that run on the system, and the system itself. C achieves this nicely, while VM based languages often don't.
There is no doubting that a VM based language can give you some interesting advantages. Writing out memory structures in different formats is something most Smalltalks can do right now any way. Is this even a relevant thing to be thinking about when discussing a new paradigm of programming?
And when it comes down to it - would any of the above changes really increase programming capability.. increase our ability to interact with a computer.. augment the human brain and human reality for the better?
Alan has consistently shown that a -system- is the kind of outcome he desires, not a language. The languages in question are a means to an end.. but it appears for Alan that most modern languages do not provide the means to get to the end of a capable system. Most systems around today are very different from Self, Squeak or Croquet. Most computer professionals openly dislike such flexible systems like Squeak - or some of the higher loftier "everything is changeable" ideas of Croquet. They question the value of such a system.
When was the last time you bought a mobile phone that you could change the shape of? there are many aspects you can change though, such as the background image, the ring tones, the vibration, the colouring of the case its in.. but there are some properties that cannot be changed. Is this a practicality concern? Take winamp as a skinnable/changeable system. The skinning in Winamp lets you totally rearrange the program. Very few rearrangements were found to be better than leaving the buttons in their original positions.
What does all this mean? - it means, to me, that we know *very little* about "technology" - what it is, what it means, what it could be, what it should be. And programming languages should be flexible enough to let us explore these more important questions rapidly.
Previous Topic
