Hacker News new | comments | show | ask | jobs | submit login
Computer Programming Using GNU Smalltalk (2009) (canol.info)
73 points by brudgers 44 days ago | hide | past | web | 56 comments | favorite



Wow, seeing this on hackernews made me shed a year.

I picked up maintenance of GNU Smalltalk when I was 19 and kept it going for about 11 years. In the meanwhile I wrote thousands and thousands of lines of C and Smalltalk code, a generational and incremental GC, a debugger, a documentation generator, a JIT compiler and whatever else. Maintaining GNU Smalltalk taught me so much about testing, release engineering, C programming, mentoring and almost everything else I learnt about programming during those 11 years.


My friend told me about this topic, wanted to say hi, nice to see familiar names again :) Thank you for your work. I kinda wish I released a revised edition of the book with typos fixed and some parts improved --canol


Thank you.


I looked at a number of Smalltalk books yesterday after reading a discussion here, but all of the ones I read of the following list were terrible books:

http://stephane.ducasse.free.fr/FreeBooks.html

I didn't try all of the books.

I also tried to read the Wikipedia article on Smalltalk. I consider trying to read a Wikipedia article about anything an act of desperation.

Is this book any better than the ones I found yesterday?


Since it is on the list, it cannot be better.

Probably the best book on Smalltalk is Smalltalk 80: the language (for some definition of 'best'). It is very readable despite serving as a specification for Smalltalk 80 version 2. It is a revision of the similarly titled: Smalltalk 80: the language and its implementation linked on the list.

The text is clear and professionally edited to a level consistent with the commercial sale of printed books by a reputable technical publisher (Addison Wesley). Used printed copies are widely available and often inexpensive. With the caveat that I vastly prefer dead tree books to PDF's, the physical book is a thing of beauty with the code for the running example printed on the backface of the front cover and the parser state machines printed on the last few pages.

On the other hand, what I appreciate about GNU Smalltalk is:

1. It is text based and while I consider the Smalltalk IDE to be historically interesting, it is the least interesting part of the language for me, today.

2. GNU Smalltalk integrates with Emacs (in Debian it is a separate package gnu-smalltalk-el).

3. I prefer tiling windows to overlapping windows and the keyboard to the mouse and other Smalltalk implementations follow the WIMP paradigm.

4. Though in fairness, I am just goofing around with Smalltalk and if I had production grade concerns, I might have a different attitude.


> 4. Though in fairness, I am just goofing around with Smalltalk and if I had production grade concerns, I might have a different attitude.

I'm curious, is Smalltalk especially good for any particular task? Or especially easy to use for something?

I'm always on the look out for something better as all the languages I use and know well seem inadequate or tedious in one way or another and a lot of those that I don't use seem intimidatingly difficult to get started with (often because ecosystem in which they live is difficult to handle).


I'm curious, is Smalltalk especially good for any particular task? Or especially easy to use for something?

Have a read of http://www.cincomsmalltalk.com/main/successes/financial-serv...

But then consider that they didn't choose Smalltalk for the next project...


What did JPMorgan use for their next project?



Yea, I often wonder about this kind of thing. Compared to Fortran, Common Lisp is a tower of power and sorcery, but compared to Python it isn't as impressive. Yes, it is a more powerful language, but the power isn't always worth the learning curve and mostly abandoned libraries. I think Python + C++ seems to be an easy spot marrying rapid prototyping & raw speed when you need it in addition to all the developers you'd get from 2 of the top 5 languages in amount of use. The Smalltalk and Common Lisp ecosystems are pretty similar to me. Both have a few commercial products and a few open source projects and a fairly small and fragmented community despite some commercial success.


A lot of Common Lisp libraries are done rather than abandoned [Clojure inherits this property]. Common Lisp is stable because the spec is about twenty-five years old. Hence new behaviors introduced by software updates are either implementation extensions or regressions. If a new version of a Common Lisp implementation breaks an existing library, it is more likely a regression than a library corner case...and because libraries are stable, it is practical to test against what people are using in the field.

I think Python and C++ are great languages, but when comparing them to Common Lisp -- or Smalltalk or discussing their merits in general -- there is the question of which Python and which C++ form the basis of comparison.


That is true in the sense that the fundamental algorithms and data structures and so on are maths and maths doesn't change.

But the vast majority of them are available in Python libraries, and if you need something right now say a library interfacing to a particular DB or protocol, there is a very high probability that in Python you can pip it in a minute and it will basically work, vs having to do it yourself in Lisp - and it's not cool fun stuff like a new algorithm, it's dull boring work of reverse engineering and hacking around the bugs in someone else's product, and Lisp doesn't give you any leverage there.


Architecturally, how often is there a slam dunk engineering case that the core business logic should handle an obscure protocol or oddball database directly rather than abstracting over the requirements and leaving the implementation details to another layer in the stack?

While Python is not Javascript, 'pip what?'

For SQL: https://pypi.python.org/pypi?%3Aaction=search&term=sql&submi...

For RabbitMQ?: https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&...

For Hadoop?: https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&su...

Having PiP (or Quicklisp) does not so much solve the problem as transfer it to a problem in a different domain. The new problem may or may not be easier to solve than the original one. Sometimes Nginx is a good answer. Sometimes SimpleHTTPServer is. Sometimes Sinatra. Sometimes Rails.


Sure, knowing your way around the ecosystem is a thing. But that ecosystem has to exist and be kept up to date. And you wouldn't want to hire someone who was too keen on reinventing the wheel anyway...

Plus, it is a slam dunk case that most organisations will not benefit from choosing a "best" language for every project or use case and should instead settle on as few as possible... One HLL (e.g. Python or Tcl or Perl) and one low-level (C or C++) is probably the best bet for 99% of organisations.


Agreed and what I was trying to convey.


Of course that's also true of Smalltalk, as the modern versions are different and evolving independently (Pharo actually doesn't call itself a Smalltalk but a language and environment derived from Smalltalk.)


I'm not sure whether or not GNU Smalltalk is a modern version:

gnu Smalltalk is an implementation that closely follows the Smalltalk-80 language as described in the book Smalltalk-80: the Language and its Implementation by Adele Goldberg and David Robson, which will hereinafter be referred to as the Blue Book. -- https://www.gnu.org/software/smalltalk/manual/gst.html

Then again, it is sort of designed to work with Emacs rather than emphasizing traditional Smalltalk IDE's like Pharo.


Smalltalk 80: the langauage is formally divided into three parts. The third part is devoted to simulations such as a car rental agency (one of the examples). I was a bit surprised, but then I remembered that Smalltalk's object oriented predecessor was Simula (as in 'simulation'). The code for the simulation examples is compact because Smalltalk includes 'primitives' that are suited for building simulations.

From a more mundane language design standpoint, Go's capital/lower syntax for 'public' versus 'private' identifiers in modules mirrors Smalltalk's public/private syntax for object methods/variables.


It's worth spending a few hours to get an idea of what Smalltalk looks and feels like, but I wouldn't spend any more time than that on it.

First of all, it's dynamically typed, which is not something we should seriously be using in the 21st century.

Second, the tool ecosystem surrounding Smalltalk is abysmal and antiquated compared to modern IDE's.


>First of all, it's dynamically typed, which is not something we should seriously be using in the 21st century.

Citation needed.

>Second, the tool ecosystem surrounding Smalltalk is abysmal and antiquated compared to modern IDE's.

Actually modern IDE's are abysmal compared to what Smalltalk offered even back in 1995.


> > Second, the tool ecosystem surrounding Smalltalk is abysmal and antiquated compared to modern IDE's.

> Actually modern IDE's are abysmal compared to what Smalltalk offered even back in 1995.

Perhaps more fairly than either of those characterizations, most modern IDEs are influenced by a different set of priorities than typical Smalltalk dev environments, and have different strengths and weaknesses, and most current developers are (whether this is inherently better or just an adaptation to the tools they use) attached to workflows that major modern IDEs support better than Smalltalk toolsets (OTOH, the exact reverse is probably true of most Smalltalk developers, though they are smaller in number.)


> Citation needed

Math. Look up the Curry Howard isomorphism and why it cannot be leveraged with dynamically typed languages.

> Actually modern IDE's are abysmal compared to what Smalltalk offered even back in 1995

I think you should spend some time with some of these modern IDE's to understand what true, guaranteed correct refactoring means, something Smalltalk can never hope to achieve because the language doesn't have type annotations.


>Math. Look up the Curry Howard isomorphism and why it cannot be leveraged with dynamically typed languages.

That's not Math. That's using math and then adding hand waving conclusions.

Whether a language can leverage the "Curry Howard isomorphism" or not, while verifiable, is a totally different claim than "we should not seriously be using [that language] in the 21st century".

>I think you should spend some time with some of these modern IDE's

And I think you should know that I have been using those for decades (if by "those" we mean Eclipse, Idea and XCode). Still find Smalltalk IDEs with the whole paradigm more powerful.


Curious what tools you consider suitable?


IDEA, Eclipse, Visual Studio, XCode.


Curious about languages as well -- I think of languages as tools, too.


That becomes a little bit more subjective so I won't name specific languages, but to me, the language being statically typed is a requirement.


In the 20th century we were big on static typing too. My first serious programming was in Pascal, in the 1980s. You have to understand that trends in programming are like clothing fashion, not like progress. My first Pascal was Apple Pascal, which was a UCSD Pascal. In UCSD Pascal everything was compiled to a virtual machine called the p-machine. In the late 1980s we all thought this was a stupid idea and for efficiency we should use native code. But by the late 1990s things went back to the idea of virtual machines, JVM and .NET. Now with Go and Rust we seem to be going back to native code. And with this whole obsession about static typing we are going back to the 1980s too.


> In the 20th century we were big on static typing too.

I don't think we were. I don't even think we truly understood the practical difference between statically and dynamically typed languages. But even so, back then, it was reasonable to claim that while statically typed languages have the advantage of performance and correctness, they are much more verbose than dynamically typed languages.

Today, this is no longer true. We know how to design languages that have the strengths of both statically and dynamically typed languages (see Kotlin and Swift for the best incarnations of these concepts).

There is really no good argument in favor of picking a dynamically typed language.


> You have to understand that trends in programming are like clothing fashion, not like progress.

Yes, it is all just fashion, and relentless churning.


> First of all, it's dynamically typed, which is not something we should seriously be using in the 21st century.

While I disagree that the second half is valid as a blanket statement, if that really is a problem for you, there is always Strongtalk.


> Since it is on the list, it cannot be better.

It might be better, since I did not try all of the books, and I did not specify which of the books I had tried.


I assumed that the referent for 'the ones I found' was the list. My apologies for the confusion.


Pharo By Example was recently updated for Pharo 5: http://files.pharo.org/books/updated-pharo-by-example/

As for that list, Smalltalk-80: the Language and its Implementation (the "blue book") is phenomenal. One of the co-authors is Adele Goldberg herself, and the last few chapters (26-30) contain the blueprint for a basic, canonical VM using Smalltalk itself as the implementation language (referred to as the "blue book VM").

I think The Art and Science of Smalltalk is quite good also, but outdated and VisualWorks-specific. The section on MVC is particularly interesting, especially if your understanding of it was shaped by RoR and other web frameworks.


I haven't read many books on or using Smalltalk, but I can definitely recommend Kent Beck's "Smalltalk Best Practice Patterns"

https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent...


Yes, this book is very good, although its contents does overlap somewhat with Fowler's Refactoring.


I found the pharo books to be lacking as well in addition to the YouTube videos. It's nice they're there, but I expected more. I wish Richard Eng (Smalltalk evangelist doing a lot of marketing blog posts) would add some videos of creating some simple/small projects using Pharo as well so I can get a better gist of what it's like developing in it. There is a lot there, but I have no way to get at it efficiently. I may have to look at the environment's built-in tutorial again.


If memory serves, the GNU Smalltalk manual is not a bad introduction/tutorial to the language.


I found your suggestion valuable.


Which books did you find, and what did you find "terrible"? It's very hard to suggest books which you might find subjectively superior when you don't identify what you've tried or why you didn't like it or what, specifically, you are looking for.


Smalltalk with Style (one of the books in that page) is actually a really good book on coding style in Smalltalk. I remember reading it and taking its advice about twenty years ago when I was using Smalltalk heavily.


Not a book, but there was a Pharo MOOC on the FUN platform (france université numerique); which was as interesting for the theoritical and the pragmatic side of ST like languages.


Not sure if this is the same course, but:

http://files.pharo.org/mooc/


Yes it is. Didn't know they published it this way.

If I may, I didn't like the "we the real OO man, look at our dispatch" feel sometimes. Hubris if you ask me.


I seem to remember VisualWorks had a builtin tutorial which was kinda awesome, but I might be having rose tinted memories, it was many years ago.


This site would not render until JavaScript was enabled.

EDIT:

It seems that NoScript plugin has stopped Firefox from rendering this page where no script is embedded/referred. Probably NoScript blocked XSLT in Firefox.


Interestingly, the page doesn't claim to be HTML or even XHTML --- it's served with "application/xml" content type, and is pure XML with an XSL that transforms it into HTML in the browser. I don't see that very often.


I also use pure XML/XSLT for one of my production sites. In theory, XSLT is th nicest templating language I've ever used (even the 1.0 version). But, in practice, there are too many inconsistencies among browsers (e.g. in-page JavaScript is difficult because IE’s CDATA handles escaping “<” and “>” differently than Chrome, Firefox, and Safari).

Sadly, Google is planning to deprecate and remove the feature[1].

[1] https://groups.google.com/a/chromium.org/forum/m/#!topic/bli...


Because XSLT is Turing Complete, Chromium may be removing it to reduce the browser's attack surface...at least in part.


That's amazing :D

I browsed the source code and found a lulu tag (?)

  <lulu url="http://www.lulu.com/content/paperback-book/computer-programming-using-gnu-smalltalk/7746227" />
Apparently it's declared in www.canol.info/xsl/default.xsl

  <xsl:template match="lulu"> ... </xsl:template>


Yeap, I was looking for a method to seperate content from design without using server side technologies and found this XML + XSL method. It worked quite well actually and still works till this day :) --canol


Same with uMatrix under Palemoon. Had to enable something in "other".

The root page doesn't require it. Yet another instance of I don't know how to take a screenshot so I'll take a snapshot of the screen and email that Internet Of Madness.

The more we get, the more we waste.


>This site would not render until JavaScript was enabled

It will also not show anything unless a monitor is connected.


I know it's Windows only, but Dolphin Smalltalk is really much more impressive than GNU Smalltalk or Pharo.


For a long time, Dolphin Smalltalk was a very good Windows development tool, and probably the best Smalltalk.

Fast and native UI, wonderful refactoring support, builds to exe, great community.


It is now fully open source and on GitHub, too!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: