It may sound neat to allow developers to modify the language, but having used Smalltalk for more than 20 years, I have had to deal with the chaos that can result when different developers modifications conflict. I would rather have a controlled and organised process.So an ordered and controlled process is seen as desirable. Ok but controlled by who exactly? The truth is that most people feel more comfortable being lead. I can wax lyrical about the technical superiority of languages like Self, Smalltalk and Lisp as compared to lesser languages like Java and C# (and even Ruby and Python), but this doesn't matter a jot if people just aren't 'comfortable' with these supposedly 'superior' languages.
With Java there is minimal degrees of freedom. If you want to iterate, there is one (non-deprecated) way. Want a call back there is one way. You do things the 'Gosling way'. It is all pre-packaged and rather assuring. I must admit when I first used java I found it's simplicity re-assuring too. It was definitely welcomed after the explosion of constructs that accompanied the transition from C to C++. C# has used the same formula, after all it worked for Java. Java has taken "the shrink-wrapped approach" further, beyond the base language. The whole J2EE application stack was supposed to result in "one way" to build enterprise applications. Reducing software development to painting by numbers.
This all works up until the point where the 'one way', just isn't the best way for you. What do you do then? Well you live with it, like the EJB community did for years, or you jump to something better suited, like pico-container or Spring.
Many Java developers are now jumping to Ruby and Rails for precisely the same reason. For many web apps, the full J2EE stack even with Spring and Hibernate, is just seen as overkill. Interestingly though, very few have moved to Squeak and Seaside, and even fewer to Lisp. Why?
Well in Matz and David Heineimeier Ruby and Rails respectively, have strong leaders. Benign dictators that prescribe "how things should be done". Ruby developers can model themselves on the approaches recommended by these leaders. Better still these leaders are developers, themselves, so there is an instant bond of trust. The Python community has demonstrated this phenomena even more so, with a single all knowing leader Guido van Rossum. Rossum even dictates how code should be laid out and how tab spaces should be used!
So in contrast how do languages like Lisp and Smalltalk compare? Well let’s start with Lisp. I like to think of Lisp as a Meta-language; a programming language for writing other programming languages. A good example of this can be seen at the Vista Smalltalk blog. Peter Frisk is using Lisp to build a Smalltalk interpreter on top of Flex. So as far as Lisp is concerned, Smalltalk is just a DSL, created using Lisp macros.
With Lisp you deal with fundamentals. The smallest construct in Lisp is called an atom. An atom is a single character and you can combine atoms to produce symbols, and symbols to produce s-expressions (lists) etc, all the way up to a full class hierarchy of objects and associated functions. You can even determine how s-expressions are evaluated with Lisp macros, so basically you can do what you like!
This power puts a great deal of control and responsibility in the hands of the programmer. Of course there are established patterns to help guide you, but there is no benign dictator making a bunch of design choices upfront. You have to make your design decisions yourself. You are on your own!
Some people will revel in this power and flexibility. Others though, are likely to find it daunting! Smalltalk follows Lisps lead, but provides a lot more pre-defined structure. It has a small syntax, just like lisp, and like lisp has a meta-model built to support meta-classes, classes, and object instances. Unlike lisp though, all objects interact through message passing and are fully encapsulated. Many objects in Smalltalk are part of the language, such as the Context object used as a stack frame, Block closure object used as a lambda expression, and compiler objects used to turn strings into byte code. So Smalltalk gives you a lot of structure.
Smalltalk wears it's heart on it's sleeve. With Smalltalk all this structure is written in Smalltalk, so as a programmer you can change any part of it as you see fit. So this is fantastic if you want to create your own specific Smalltalk dialect. But if you do, Dan Ingalls or Adele Goldberg won't be there to help you out. And you won’t be able to turn to the Smalltalk-80 "Blue Book" either. You will be in the same camp as the Lispers, on your own!
When I first came across Smalltalk I saw all the dialects as a concern. All these semi-compatible versions surely can't be a good idea? As I have become more experienced as a programmer though, I have come to see diversity as a good thing. Two analogies come to mind. The first one is biological. In nature animals ensure that there is sufficient diversity in the gene pool. Each individual is not a clone of all the others, so if a sudden virus attacks, some of the species will be wiped out, but hopefully, others will have immunity, so the species as a whole survives. I think Smalltalk has this strength. Depending on what is important, there is a variant of Smalltalk to fit the bill, and if there isn't, a dialect can be readily mutated to meet the need (in most cases). Languages that can’t adapt in this way, face the risk of dying out through natural selection (something I believe Java is in danger of).
The other analogy is spoken language. Spoken language is a living and changing thing. We do not speak the same way today as we spoke 300 years ago. Also we have regional dialects, a Scoucer for example, sounds very different to a Cockney, yet they both claim to speak English (the Queens English, not US English :^)).
In their own domains Scoucers and Cockneys get on fine speaking their own dialect. But in situations where they may have to communicate with each other, like with written English, they both fall back to 'Standard English". For Smalltalk, "Smalltalk-80" is the equivalent of Standard English.
So that's the language landscape as I see it from a cultural perspective. Where I think I agree with Steve, is that change is slow in software because of a number of reasons, many of which are cultural. Where I believe things are inevitably heading though is into a pluralistic world containing many languages and dialects, but also sharing a common base, a lingua-franca. I see the lingua-franca as being based on late-binding and message passing, but I’ll save a detailed discussion of this for a later blog. In this new world I see many domains with leadership being dispersed across them, and with several individuals taking a leadership role at different times and in different circumstances.
For this to occur, developers will need to be more comfortable taking the lead themselves, and getting rid of the "training wheels". Technically, there are tools on the horizon that could help here, protecting the less self-assured. I see Language workbenches as described by Martin Fowler as perhaps helping here. A language workbench could provide a reassuring wall between the meta-language and the domain specific language, providing reassurance and safety for domain language programmers.
Supporting tools aside, with the rise of open source and open source languages, I believe there is strong evidence of this cultural change happening already! I see this change as inevitable as the industry grows up and matures.