The key ideas were message passing, isolation and polymorphism, not a hierarchy of classes - it is just one lesser aspect. Drop it, and you would have Erlang.)
Notice how original insights were so fundamentally different from this Java we have now.)
Isn't that trend gone since a few years ? Java EE was utterly bad in the early 2Ks, after years of industry remote and components love, then with added UML flavor and XML verbose redundancy, all allowed only by the relative authority of the companies in charge (IBM, Sun, ...). The same culture that gave Eclipse whose class graph was headache inducing. Since then, from the few articles I've read, EE was trimmed down significantly.
Java was most heavily influenced by Objective-C, Patrick McNaughton was really into NeXTSTEP and almost left Sun for NeXT but was given a carte blanche by Scott McNealy to create something new. Championed by James Gosling and Bill Joy, Stealth/Green/Oak/Java pivoted in a bunch of different directions, but very few of the developers were C/C++ guys, in fact, the project was largely a reaction to Sun's dependence on C/C++.
Of course, ObjC was very heavily influenced by smalltalk, but wanting to create something compatible with C led to some basic divergence, with C's "closer to the metal" level than smalltalk.
Of languages still in use, I think ruby is probably the most influenced by smalltalk. I don't know if I've read Matz actually revealing this (maybe I just haven't googled hard enough, or maybe it's there in Japanese somewhere), but the influence is pretty evident from the outcome.
Yeah, doesn't Groovy come about as trying to make something ruby-like though? I think it gets it's smalltalk influence through ruby, but I dunno.
I was never actually a smalltalk user, it's work environment is not the attractive part of smalltalk to me, in fact it makes me shudder in horror to not be able to use an ordinary text editor to edit code, ordinary unix tools to search it, ordinary source control to store it and diff it as text, etc. -- to need custom language-specific tools for all of these things. Although I understand actual smalltalk users did like it and miss it.
> doesn't Groovy come about as trying to make something ruby-like though?
Groovy's changed its direction many times. It was started by James Strachan in 2003 as a better Beanshell, with closures from Ruby and collections syntax from Python added. Its present PMC chair Guillaume Laforge came along in 2004 and changed its direction by focusing on the Ruby side only, translating Ruby's libraries into Java for Groovy, with the intent to build a JVM clone of Rails and chip into its market share. Tech lead Jochen Theodorou in 2005-2006 helped build the meta-object protocol that Grails also uses. Groovy's direction changed again in 2011 when Cedric Champeau duplicated the functionality of Alex Tkachman's Groovy++ addin for Groovy 2, enabling static type inference and compilation, thus becoming a language to compete with Java instead of complimenting it as before. And in 2014 Groovy suddenly branched out into targeting Android.
To top it all off, Groovy lost its sponsership and changed it governance only this year, so who knows what changes in direction that will all bring. The backers of the two primary apps using Groovy seem to be at odds with each other, viz, the Grails consulting group at OCI, and Gradleware which employed some of the retrenched developers.
The sarcasm behind the quote is in that instead of focusing on what is really fundamental - message-passing between share-nothing entities (actors) and message-based polymorphism, they take an "inverse" view and focused on class hierarchies and all these irrelevant particulars from C++ which suits a "packer's" mentality. This is precisely why we have all these famous 120-character long methods, Factories of Factories and design patterns. (Norvig has a whole lecture about how good languages doesn't need design patterns).
Of course, there were backed by big money marketing memes which helped to create Java cult - packer's fear of "evil" pointers, their strive for "safety", "guarantees", " standardization" without any understanding of underlying principles.
Actually, Java ecosystem is the best compliment to the Programmers Stone essays, while Erlang is the same for design approach focused on what is fundamental - the very ideas emphasised in the Smalltalk design principles described above.
>The sarcasm behind the quote is in that instead of focusing on what is really fundamental - message-passing between share-nothing entities (actors) and message-based polymorphism, they take an "inverse" view and focused on class hierarchies and all these irrelevant particulars from C++ which suits a "packer's" mentality.
What's "really important" for whom?
Message passing between share-nothing entities might be good for Erlang but it wasn't really what Java was intented to be used for.
You seem to ignore the discussion in the Smalltalk design overview about the natural modes of human communication which, arguably, should be at the core of a programing language.
The author might be wrong in a few details, but similar intuitions and insight could be found in writings of variety of thinkers, from Navokov to and J. Krishnamurti to Chomsky (who suggested that language acquisition process is, well, a processes) and the inventors of NLP (with the notions of the deep structure and the surface structure) to Marvin Minsky with his Emotion Machine book.
Notice how original insights were so fundamentally different from this Java we have now.)