
Ask HN: Examples of elegant, non-trivial Smalltalk? - Fr0styMatt88
I&#x27;ve been on a bit of a Smalltalk &#x2F; Squeak &#x2F; message-passing OOP deep-dive as of late and was looking for pointers to good Smalltalk codebases to study that are considered particularly elegant and compact.<p>I&#x27;m especially struck at the moment by what seems to me to be a bit of a contradiction.  In this talk (https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QboI_1WJUlM) from COFES, there&#x27;s a clear push for a kind of simplicity and elegance that seems very opposite to the common criticisms I&#x27;ve seen of OOP, that it too easily results in overly-complex software (one Reddit comment I stumbled across from someone that seemed to have experience working on commercial Smalltalk applications said Smalltalk encourages an explosion of complexity).  I&#x27;m keen to look at some good counter-examples.<p>So, Smalltalkers on HN, what&#x27;s your favorite Smalltalk-family code and why?
======
svc
Smalltalk is indeed so simple that all complexity moves to the implementation
level. This is good, because it allows all users to explore how things work,
given a learning curve.

Since a Smalltalk image normally contains all code for everything, it is its
own best example.

There are many cool Smalltalk code bases, some of them already many years old,
for example, Seaside (a web app framework) or Glorp (an object relational
mapper).

Pharo ([http://www.pharo.org](http://www.pharo.org)), the currently most
successful open source Smalltalk implementation, has many frameworks and
libraries that can be loaded that are each good examples.

To get you started, you could explore some of the articles in this
publication: [https://medium.com/concerning-
pharo](https://medium.com/concerning-pharo)

One article containing small examples is this one:
[https://medium.com/concerning-pharo/elegant-pharo-code-
bb590...](https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0)

------
norswap
My (admittedly limited) experience with Smalltalk: methods are very simple and
readable. On the other hand, units of functionality tend to be split in a huge
amount of methods across many classes, and so understanding a feature requires
stringing together these methods. Dynamic typing doesn't help here, and the
IDE is sub-par for code navigation, compared to the Java/C#/C++ worlds.

------
igouy
> particularly elegant and compact

Those aren't absolutes, so _particularly elegant and compact_ compared to
what?

> encourages an explosion of complexity

It's mostly about what priorities the programmers give to the different things
that need doing on the project this week.

These guys didn't do masses of re-work for "simplicity and elegance" but for
performance --

"A very large Smalltalk application was developed at Cargill to support the
operation of grain elevators and the associated commodity trading activities.
The Smalltalk client application has 385 windows and over 5,000 classes. About
2,000 classes in this application interacted with an early (circa 1993) data
access framework. The framework dynamically performed a mapping of object
attributes to data table columns.

…

Analysis showed that although dynamic look up consumed 40% of the client
execution time, it was unnecessary.

…

A new data layer interface was developed that required the business class to
provide the object attribute to column mapping in an explicitly coded method.
Testing showed that this interface was orders of magnitude faster. The issue
was how to change the 2,100 business class users of the data layer.

…

A large application under development cannot freeze code while a
transformation of an interface is constructed and tested. We had to construct
and test the transformations in a parallel branch of the code repository from
the main development stream. When the transformation was fully tested, then it
was applied to the main code stream in a single operation.

…

Less than 35 bugs were found in the 17,100 changes. All of the bugs were
quickly resolved in a three-week period.

…

If the changes were done manually we estimate that it would have taken 8,500
hours, compared with 235 hours to develop the transformation rules.

…

The task was completed in 3% of the expected time by using Rewrite Rules. This
is an improvement by a factor of 36."

…

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA
2002

------
enkiv2
XU92 (AKA "Xanadu Gold") was written in a dialect of smalltalk:
[http://www.udanax.xanadu.com/gold/download/index.html](http://www.udanax.xanadu.com/gold/download/index.html)

~~~
imglorp
Yow, Xanadu, nice to see they're still around.

On the downside, I looked at a few methods at random in one of the toplevel
.st's and, not knowing smalltalk, it was not what I would call clean.

~~~
bencoman71
> it was not what I would call clean.

That's given you a false impression. The .st file is only an the
export/transfer format to be loaded into another Smalltalk system. Smalltalk
code is best read using its System Browser. Think of opening a .docx file in
Notepad, and how clean you think it looks compared to editing the file from
within MS Word.

Yet not being able to use your favourite text editor is one of the common
arguments some people use against Smalltalk, but perhaps there's also an
element of them trying cast something "new" (Smalltalk) to them, back into
what they already know (as Alan Kay touches on after 1:04:00 in the OP video
link)

------
blihp
The best example that I can suggest is to look at the STEPS project (i.e. what
Alan was referring to in the talk):
[http://tinlizzie.org/updates/exploratory/packages](http://tinlizzie.org/updates/exploratory/packages)
and their papers:
[http://vpri.org/html/writings.php](http://vpri.org/html/writings.php). There
have also been a couple of attempts to reduce Smalltalk back to the key
concepts it was based on with projects such as Cuis: [https://github.com/Cuis-
Smalltalk/Cuis-Smalltalk-Dev](https://github.com/Cuis-Smalltalk/Cuis-
Smalltalk-Dev)

In general though, yes the Reddit comment you came across is probably a fair
description of what you're likely to run into in the wild (commercial or open
source) since most projects tend to prioritize the short term desires/needs at
the expense of the long term. As it's often used, Smalltalk will just get them
to the unmanageable mess faster. No environment/language/tool can prevent
someone from doing silly things with it despite how hard their designers might
try to.

------
bencoman71
> criticisms I've seen of OOP, that it too easily results in overly-complex
> software

With respect to other languages, many don't do OOP well ;] Indeed in the OP
video Alan Kay said "Object oriented programming never made it outside of
Xerox Parc - only the term did" (1:06:40)

> Smalltalk encourages an explosion of complexity

Smalltalk is a fantastic prototyping language. Its easy to explore a new
domain and get something working fast. Such an exploratory process can lead to
overly-complex software. I guess the trick is to have the discipline to go
back and do the "science" to distil and refactor.

~~~
richardwhiuk
Just because it isn't what Alan Kay intended doesn't make what emerged not
Object orientated programming. Usage defines the meaning of words, and when
people use object orientated programing, they do mean as implemented in
languages which did escape Xerox Parc...

~~~
mikelevins
On the one hand, you are of course correct that the meanings of words are
defined by usage.

On the other hand, that observation entirely misses Alan Kay's point.

~~~
richardwhiuk
My point was there it isn't necessarily particular imperative to move towards
a language which has a pure implementation of object-orientated programming on
a mere 'Alan Kay wasn't thinking of this' point, especially given in the real
world we have concrete evidence that such a language has never escaped an
academic setting.

------
hilaire
I like a lot this small code example
[http://math.stackexchange.com/questions/726369/when-does-
the...](http://math.stackexchange.com/questions/726369/when-does-the-newton-
raphson-method-fail/1766666#1766666)

It results in an interactive diagram of the Newton Raphson method to search
for a zero of a function. The user explores with mouse how the algorithm is
working.

It is only a few lines of Smalltalk code over the Dr. Geo interface. IMHO, the
Smalltalk message system brings well balanced expressiveness on the resulting
code.

------
bencoman71
Check out...

"Zinc" \- It used to be an external package later integrated into Pharo. To
check it out, download Pharo 5 from
[http://pharo.org/download](http://pharo.org/download)

then try the tutorial... [http://zn.stfx.eu/zn/build-and-deploy-1st-
webapp/](http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/). Debug some of
those examples and you'll get a look at Zinc's internals.

"Teapot" \- I haven't used it but seen others in the mail list describe it as
elegant. You can load it into Pharo 5 from Tools > Catalog Browser.

[https://skrishnamachari.wordpress.com/2014/08/28/teapot-
phar...](https://skrishnamachari.wordpress.com/2014/08/28/teapot-pharo-web-
rest-framework-it-aint-micro/)

[https://ci.inria.fr/pharo-
contribution/job/EnterprisePharoBo...](https://ci.inria.fr/pharo-
contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-
result/EnterprisePharo.pdf)

Please ask questions in pharo-users if you get stuck.
[http://lists.pharo.org/mailman/listinfo/pharo-
users_lists.ph...](http://lists.pharo.org/mailman/listinfo/pharo-
users_lists.pharo.org)

------
protomyth
I would imagine this is going to be a tough question to answer since so much
of the non-trivial Smalltalk code is implementing proprietary business logic
and thus locked away.

------
MarkMMullin
I'm surprised no one has mentioned this yet - The Smalltalk environment itself
is an excellent example of non-trivial Smalltalk - hey, you can even go in,
fiddle with the language parser, and watch your whole world implode :-)

------
jacquesm
[http://c2.com/cgi/wiki?GemstoneProject](http://c2.com/cgi/wiki?GemstoneProject)

------
pjmlp
Have you already read the Xerox PARC books?

[http://stephane.ducasse.free.fr/FreeBooks.html](http://stephane.ducasse.free.fr/FreeBooks.html)

------
pcunite
Theory: Successful projects always result in inelegant code until such a time
that it can be rewritten with hindsight.

Fact: There are more successful projects not written in Smalltalk.

~~~
igouy
_Assertion:_ There are more successful projects not written in X.

------
qwertyuiop924
Seaside, Monticello, and the Smalltalk Kernel are all fairly large codebases.
I haven't looked at them though...

