Introduction
NOT READY, ACCUMULATING MATERIAL
About in year 2000, after studying C for one of the few computer exam I had in my curriculum and having a lot of fun with it, I started to learn Python and it seemed to me a great great language. A big step forward respect to C and Visual Basic. It was a lot easier than C and a lot cleaner than VB. I wrote quite a few programs in Python and for a while I was quite happy with it.
With time I started to become a little bored by the amount of vertical space I needed in Python to write the most trivial stuff, also by 2007 I was system administrator at INFN in Florence and it was necessary for me to run a lot of Unix programs to automate various things. Python was not invented to be a Unix scripting language, I came in contact with Perl and it was friendship. Perl was the system administrator best friend. With Perl I learnt about Regular Expressions and from that moment I literally start to love them.
Time passed, I left my place as system administrator and I was in Madrid to getting a PhD in applied mathematics / statistics. There I did my computer business mostly with R, Mathematica and Matlab. Still Perl was my glue language. With Perl I was running complex chains of scripts where Mathematica was doing the symbolic computations, Matlab the numerics, and LaTeX finally was producing a nicely formatted output.
Some more time passed, in 2016 I was in a startup developing a Bond Portfolio app which never took over. I was again in need to write automation scripts but, by that time I had forgotten all of the Perl kung-fu, and most of my old scripts seemed gibberish to me, I could understand what they did only because I left in them a good amount of comments. In that moment I thought I needed something similar to Perl, born for Unix automation, but a little cleaner and more readable. I found Ruby and for a few years to follow it was my favorite scripting language.
Ruby is really cool, it is all objects, it has Regexp incorporated into the language, it is compact, you can call shell commands in a breeze, you can add methods to String (you can't in Python). It comes with a feeling of power similar to Lisp but with much less typing. It is really a nice language and if I hadn't discovered Smalltalk I would be writing a book about Ruby now. With Ruby I developed most of the scripting part in my next job at Stanford SLAC. Till, one day I saw a video, this one, which was saying something like, "hey, yeah, Ruby is great but you should really try Smalltalk". I didn't understand at all the content of the video at that time but It was enough to light up my curiosity and I started to get info about Smalltalk.
Smalltalk it was the hardest language for me to learn. Harder than C and Common Lisp, harder than Mathematica and R. In retrospective I see there is one main reason why it was so hard. I learnt all these programming language alone, by books. For Smalltalk, in about 2020, The documentation is really inadequate. If you read Common Lisp the Language Ed.2, a book from the '90, you can easily start programming in a modern Common Lisp. For Smalltalk it is a completely different story, most of books are all about minimum 20 years old but you can hardly apply what you learn to any existing Smalltalk implementation.
The thing also get worse because there are three main open source Smalltalk implementations, there are a lot more indeed, but these three have the largest communities: Squeak, the father of all, Pharo the business oriented cousin and Cuis, the cousin oriented toward small and clean code and improving graphics. The fact is, these 3 implementations are similar but you can appreciate the similarities and dissimilarities only when you are experienced enough, before that, to you they will just seem different languages. You try to run a Squeak piece of code in Pharo and it does not work! You try to run a Squeak code from a year 2008 book and it does not work in Squeak in 2019. The debugger pops up very frequently and you just don't know what to do. The impression is nothing works.
More, as a programmer you know, when you are in trouble first thing is to go copying snippets in StackOverflow, we all do, more or less cautiously. Surprise, you just can't copy a 20 lines block and solve a problem in Smalltalk, it is not the way we do it in this language. You will need to use the Browser to build classes but again, if you don't know you will insist copying longer and longer code chunks in and out of the Workspace . Wrong! Then, for the final cherry, people can become quite pissed when you ask "how do I uppercase a String in Smalltalk?" or "how do I open a file and write into it?" and they tell you something like "hey, do the digging, it easy to discover". But again, you don't know where to dig and looking for what. In the end, the experienced users are right and they are pointing you in the right direction but your total ignorance blinds you.
NOTE. the Browser and the Workspace are specific Smalltalk tools. There is nothing similar to the Browser in other languages, whilst the Workspace is more or less similar to a Python REPL, that is why you probably love it, it is one of the few things it works as you expect.
...
We came to the reason why I wrote this book. Smalltalk is a fantastic language but it is also an alien language for year 2020. It is so different it is puzzling for a beginner to get started without a guide. I wrote this book to let you be able to get started doing stuff, the same problems you are able to solve in Python you will see how to solve them in Smalltalk. With that you will get familiarity and you will start to learn the superior tools this language provide you. Tools you don't have in Python, in Ruby, Java or anywhere else. You know print and we will start straight from that, even if, frankly speaking, it is not terribly important in Smalltalk. Solving little problems like writing into files and grabbing web pages or finding prime number we will go deeper into the language and you will see how beautiful it is.
Why call this kind of text a "cookbook" ? This is a reference to a book I red when i was learning Linux in my early 20s. I still remeber quite clearly there were directions to resize images, convert files from *.mp3 to *.wav .etc. All recipes were to be copied in the shell. No tedious description of which button in which windows you have to push. Those code chunks just worked, they were little but important. I want to be the recipes of my book to be the same.