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.
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?
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.
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).
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...
C++ and Python
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.
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.
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.
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.
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.
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.
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.
>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.
> 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.)
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.
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.
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.
Yes, it is all just fashion, and relentless churning.
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.
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.
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.
If I may, I didn't like the "we the real OO man, look at our dispatch" feel sometimes. Hubris if you ask me.
It seems that NoScript plugin has stopped Firefox from rendering this page where no script is embedded/referred. Probably NoScript blocked XSLT in Firefox.
Sadly, Google is planning to deprecate and remove the feature.
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" />
<xsl:template match="lulu"> ... </xsl:template>
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.
It will also not show anything unless a monitor is connected.
Fast and native UI, wonderful refactoring support, builds to exe, great community.