Design Principles Behind Smalltalk (1981) | Hacker News Reader

Design Principles Behind Smalltalk (1981)

cs.virginia.edu

61 pointsbrudgers38 comments

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

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.

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

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.

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

When people complain about JEE, I usually say they should have experimented CORBA.

Two wrongs don't make a right unless you are Microsoft's roadmap.

Right, the point being that the enterprise culture that created CORBA, will make anything similar regardless of the programming language.

Too true.

Q. How much will this cost? Q. How much computing power will it take?

A. How much you got?

Nope. It means a completely different thing.

  Java: the elegant simplicity of C++ and the blazing speed of Smalltalk. – Jan Steinman

Basically, they got it all wrong. Erlang got it right.

At least it got the Smalltalk JIT. :)

Actually I think it got Self's JIT, at least that the story that the Self people tell. Squeak and Pharo's Morphic UI also came from Self.

http://www.selflanguage.org

I was simplifying. As Self roots are in Strongtalk, wich had as goal making a faster Smalltalk implementation.

Now the closest we have to Self is JavaScript, damaged by DOM and its UI hacks to bend documents into applications.

Java the language is much simpler than C++. I sincerely don't understand how anyone could think otherwise.

And it also has blazing speed -- and why its much faster that it initialy was, it was fast enough from the beginning too.

The quote sounds funny, but it's actually BS.

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.

What is 'a "packer's" mentality'? I don't think I've heard that expression before.

http://the-programmers-stone.com/the-original-talks/day-1-th...

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 struggle to understand how any of this somehow makes it true that the Java language is as complex as C++.

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://www.blinkenlights.com/classiccmp/javaorigin.html

I read somewhere that the inspiration for Java interfaces came from Objective-C protocols.

Patrick McNaughton thought so too:

"I'm pretty sure that Java's 'interface' is a direct rip-off of Obj-C's 'protocol' which was largely designed by these ex-NeXT'ers"

http://cs.gmu.edu/~sean/stuff/java-objc.html

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.

Groovy also has its share of Smalltalk influence.

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

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.

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.

Yes, JEE is quite nice nowadays.

The culture that gave us J2EE has moved on to:

- SOA

- micro-services spaghetti dependencies

- JavaScript frameworks and build tools (each month a new one)

- MVVM

- From XML everywhere into JSON everywhere

Yeah, JavaScript is new Java.)

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

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

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.

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.

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

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

Reply on news.ycombinator.com