Natural Selection: Languages and systems that are of
sound design will persist, to be supplanted only by
better ones.
and thought of Bob Martin's What Killed Smalltalk Could Kill Ruby[1]. The technical merits of Smalltalk are such that few claims "to do objects better" are taken seriously. But the lesson of Smalltalk is that "better" isn't just in the technical details. It lives in the model of community that it's speakers adopt. People speak C and JavaScript because they rode along free with Unix and the browser. Even in it's darkest days, Lisp tagged along in AutoCad and Emacs. These languages had practical purposes that let them compete outside of the "what language should I build my next project in" marketplace and outside the segment of professional software developers.
Smalltalk was killed by its business models. Without runtime licensing, providing a REPL meant that every application would come with a free copy. Not providing a REPL meant knee-capping the application.
If a system is to serve the creative spirit, it must be
entirely comprehensible to a single individual.
As a UX designer and investor, I'm constantly worrying about creeping complexity in interfaces and companies. Cluttered thought and execution has always been the enemy for me, but always in service of better conversion, execution and flow. The limits complexity brings to creative potential...that's a new articulation for me and an exciting one to think about.
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.
I think you've got it wrong. The degenerate case of this is that you've one object, called a "Computer", which can "compute".
We live in a world. It has state. Something needs to manage, check, and hold the state. It's sometimes easier to conceptualize a problem by pretending that state doesn't exist, but it's an abstraction that leaks badly for anything that does not exist in isolation from the world.
The misconception that wrecks OOP in the eyes of many is that OOP == "Class Hierarchy". OOP = "Objects" and "Messages". Everything else is negotiable.
We typically divide programs into data structures and code. The problem with combining them into objects is that there is often code that does not correspond to a single data structure.
"Kingdom of nouns" talks at length on the subject. But basically, "object" as "code plus one data structure" is not a design panacea.
Of course it's not as bad in SmallTalk as it is in Java, to use those two as stand-ins for dynamic vs. static typing and I would change your comment to "The problem with combining them into classes is..."
In SmallTalk I would write code that operates on any object that can respond to some set of messages so the coupling is much looser.
Smalltalk was killed by its business models. Without runtime licensing, providing a REPL meant that every application would come with a free copy. Not providing a REPL meant knee-capping the application.
[1]: http://www.youtube.com/watch?v=YX3iRjKj7C0