> The principle of good design can be restated for languages:
> Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
A key statement for our budding language designers on HN.
However they do go on to state that LISP is about linked structures, and APL is about arrays, which is wrong really - or at least does not do full justice to the ideas behind both.
Sending messages between independently acting 'objects' sounds elegant and powerful, but in the large does not address (and perhaps exacerbates) the most critical problem facing software engineering - namely the control of complexity.
I think this is a fair assessment. I agree that Smalltalk is by far not a complete solution to the problem of building and maintaining complex system but "only" an attempt.
I found that message passing is an elegant approach to have interoperability on a very basic level. But when protocols and interactions between objects get more complex, it becomes more difficult retain control and comprehension of the evolving system, thus fundamentally better approaches and methods are needed than what is present in a typical Smalltalk system.
You might be interested in watching Alan Kay's seminar on object-oriented programming, in which he sketches some ideas on how to modularize an OO system, notably, using a kind of specification language to describe the functions/needs of components and letting the underlying system figure out how to hook them up and deliver messages automatically (as opposed to the direct message passing style in traditional Smalltalks). The relevant part can be found here [1], but I found the entire talk worth watching, since a whole set of issues with OOP and Smalltalk (difficulties in finding and reusing components, weak generality) is being touched upon.
Unfortunately, as far as I know, none of the critical ideas have been crystallized into a new kind of Smalltalk - which would be more focused on working on sets of components instead of individual objects/classes (or paraphrasing Alan Kay, making "tissues").
Instead of a bit-grinding processor raping and plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires … Examples of success in this area include LISP, which is built on the model of linked structures; APL, which is built on the model of arrays; and Smalltalk, which is built on the model of communicating objects. In each case, large applications are viewed in the same way as the fundamental units from which the system is built.
I think programming languages compose poorly. Monads and effects get nearer to problem we are trying to solve - tying specific behaviour to specific scenarios - but impose such as a high threshold of understanding that they are rarely used in practice.
If I want to take behaviour you've written and use it in my system I have to do lots of studying your APIs to work out how to represent my solution with your code and API.
I am inspired by message passing and Smalltalk but put off by the cache locality of object orientated programming. Making systems that compose is hard work.
> The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.
I have the sense that Bjarne Stroustrup and James Gosling were unaware of this document, or if they were, disagreed with it. It’s a shame they looked more to Simula for inspiration.
Back in the day, programming in Java, I always had the distinct feeling that the compiler was more important than me. Too much of my time was not spent creating. It was spent making the compiler happy. I’ve wondered what would have happened if Sun had Gosling build the JVM and someone else design the language (Bill Joy?). Would we have gotten a language that was designed for humans?
> Too much of my time was not spent creating. It was spent making the compiler happy.
I’ve seen this happen to some colleagues, and it has happened to me as well, not only with java.
It’s really… a skill issue. In most cases the user hadn’t read the documentation well if at all, or is trying to write in language X while thinking in language Y. It’s really your issue if you’re misusing the language and the compiler.
Bear in mind that the Java design was only half done when it got shipped - I would love to see what both Java and JavaScript would have been if their creators had been given the time to actually finish their respective designs.
> Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
A key statement for our budding language designers on HN.
However they do go on to state that LISP is about linked structures, and APL is about arrays, which is wrong really - or at least does not do full justice to the ideas behind both.
Sending messages between independently acting 'objects' sounds elegant and powerful, but in the large does not address (and perhaps exacerbates) the most critical problem facing software engineering - namely the control of complexity.