
Design Principles Behind Smalltalk (1981) - brudgers
https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
======
brudgers
I read the closing remarks:

    
    
        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.

[1]:
[http://www.youtube.com/watch?v=YX3iRjKj7C0](http://www.youtube.com/watch?v=YX3iRjKj7C0)

------
kevin
I've never thought about creativity in this way:

    
    
        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.

------
dschiptsov
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.)

~~~
pjmlp
I don't see it that much difference and I used VisualWorks for Smalltalk at
the university, right before Java was announced to the world.

Given my experience in OOP frameworks since the early 90's, I would say if
Smalltalk had won, we would nowadays have SmalltalkEE.

~~~
ExpiredLink
Java was heavily influenced by Smalltalk but written by and for old C/C++
hackers. Java's success meant Smalltalk's demise.

~~~
huxley
Not quite, the influence was mostly indirect.

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++.

Sources:

[http://cs.gmu.edu/~sean/stuff/java-
objc.html](http://cs.gmu.edu/~sean/stuff/java-objc.html)

[http://www.blinkenlights.com/classiccmp/javaorigin.html](http://www.blinkenlights.com/classiccmp/javaorigin.html)

~~~
jrochkind1
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.

~~~
pjmlp
Groovy also has its share of Smalltalk influence.

But no language can really claim the Smalltalk spirit without a similar work
environment.

~~~
jrochkind1
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.

~~~
vorg
> 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.

------
ExpiredLink
> _Messages: Computing should be viewed as an intrinsic capability of objects
> that can be uniformly invoked by sending messages._

"Computing ... as an intrinsic capability of objects" \- I'd call this the
basic misconception of OOP.

~~~
brudgers
Why would you call it that? I don't understand.

~~~
klodolph
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.

~~~
zwieback
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.

------
cmrdporcupine
This seems to get posted once a month if not more. It's a great historical
document, though.

------
verytrivial
Please fix the typo in the title. It does not appear in the original article.

