HN Explorer

Ask HN: Examples of elegant, non-trivial Smalltalk?

47 points by Fr0styMatt88 ↗ HN
I've been on a bit of a Smalltalk / Squeak / 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.

I'm especially struck at the moment by what seems to me to be a bit of a contradiction. In this talk (https://www.youtube.com/watch?v=QboI_1WJUlM) from COFES, there's a clear push for a kind of simplicity and elegance that seems very opposite to the common criticisms I'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'm keen to look at some good counter-examples.

So, Smalltalkers on HN, what's your favorite Smalltalk-family code and why?

22 comments

[ 4.5 ms ] story [ 48.9 ms ] thread
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.
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), 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

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

qwertyuiop924
Seaside, Monticello, and the Smalltalk Kernel are all fairly large codebases. I haven't looked at them though...
enkiv2
XU92 (AKA "Xanadu Gold") was written in a dialect of smalltalk: 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)

enkiv2
Xanadu definitely is still around, but this particular code was written in the early 80s & released as open source in 1999.
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 and their papers: 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

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.

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

bencoman71
Having said that, coming to Pharo from a C programming background, one area that for "a while" I found over complex was use of the visitor pattern and double-delegation. This was facilitated by Smalltalk's duck typing over static typing. It took me a while "to get my eye in." But then... the only programming languages worth learning are those that change the way you think about programming.
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.
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.
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

then try the tutorial... 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://ci.inria.fr/pharo-contribution/job/EnterprisePharoBo...

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

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

hilaire
I like a lot this small code example http://math.stackexchange.com/questions/726369/when-does-the...

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.

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