I don't understand your last sentence. Things can be made simpler than possible?
If you focus just on inner loops, this kind of simplicity is widespread and essential for performance. APL and its derivates are great specification languages for array manipulation.
If you are writing a networked window system, on the other hand, a "high ceremony" language is more appropriate because you need to cope with protocols and abstractions. Right?
My point is that it's wise to challenge assumptions about what "simple" means. Self-imposed constraints often yield more novel, more optimized solutions than when you have all the freedom in the world. Maybe flat files interacted with via fopen() works better; maybe we just don't need our layers to accrete until we have AbstractSingletonProxyFactoryBean.
A networked window system — perhaps not the best example. With that one I think the assumptions are flawed (ie., that you can make one without introducing painful leaky abstractions) to begin with. ;-)
Well, in terms of whether the example is a well-posed question, a networked window system isn't too different from the WWW, which as we know by now works pretty flawlessly.
Perhaps the key contrast here is between the tendency toward static mathematical perfection of the APL family and the notion of dynamic languages for building systems that Alan Kay et al would propose.
"APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can’t add anything to it. If you try to glue on another diamond, you don’t get a bigger diamond."
--Joel Moses
There's a talk by Ian Piumarta that tries to get to the core of what the VPRI guys feel is important. I'm not sure about it but it seems worth mentioning in this context:
Ian Piumarta "Building Your Own Dynamic Language"
http://www.youtube.com/watch?v=cn7kTPbW6QQ
If you focus just on inner loops, this kind of simplicity is widespread and essential for performance. APL and its derivates are great specification languages for array manipulation. If you are writing a networked window system, on the other hand, a "high ceremony" language is more appropriate because you need to cope with protocols and abstractions. Right?