Why Smalltalk?

NOT COMPLETE -- ACCUMULATING MATERIAL

It would be easy here to fill 10 pages of abstract concepts, I don't want to do that. We will compare Smalltalk with another language, a popular one, a good one: Python. If you already know Python, why should you learn Smalltalk?

Let's start from a fundamental concept, almost all popular programming languages can solve almost all existing problems. So why learn more than one? Well, quoting Wittgenstein,  "My language is my world", this holds true also for programming languages. When you choose a programming language you mostly don't choose what is possible for it to do, but what will be easy to achieve according to you or your organization's taste and preferences. For example, in C you can directly access memory locations, in Python and Smalltalk you can't easily, therefore if you are working at a very low level, e.g. you are writing a driver, C is a more fit tool. On the other side, suppose your problem is to find the 10 largest files in your computer that were last opened more than 1 year ago. In C, to do this will take about 1 hour, minimum. In Python and Smalltalk you can do it in a few minutes.

Factors useful in deciding the programming language for your next task.

• execution speed. How fast does your code need to run? Here the fastest are C, Fortran, and C++. Python and Smalltalk can't even compare to them. TODO COMPARE Python and Smalltalk speed.
• cross OS portability. Can you run your code in a Mac, Windows, Linux, BSD? Here Python and Smalltalk are very good and C is very bad, your code is going to run on the major OS without changes or with little changes. For example in Windows the root directory is 'C:\' in Unix like systems it is '/'. These little things must always be fixed. In C you would need to compile a specific version of the program for every OS.
• cross architecture portability. Can you run your code in a normal PC as well as in a Raspberry Pi, in a BeagleBone Black, in a Web browser? In C this is a problem. Python is quite portable, and Smalltalk is the king - it can run in very different platforms, for example with SqueakJS you can run your program written for a PC right on the Web. You can't do this easily in any other programming language to my knowledge.
• library availability for your task. Here C is the king, there is a library for everything. Python is still very good, the library park is huge, especially since it got supported from Google. In Smalltalk we are far from the level of C and Python. If you need a very specialized library, either you write it or you call external code.
• community size and colleagues.  At some point you will get stuck. It is true, with open source you can read all the code and answer your own questions but it can take a lot of effort and if you are at a beginner-intermediate level this is just not possible. Therefore, an important factor to consider is: can you communicate with somebody who may answer your question, are there enough people using the technology. Not least, can you find programmers who know the language and work with you on a project? Here C and Python shine, in Smalltalk it is a bit of an issue but we do have our communities.
• development speed. Here C is really bad, writing programs takes time, debugging is hard. Python is a lot better - I would estimate you can be 5-10 times faster writing in Python. Smalltalk is the best, with its powerful tools and Platonic design not only is development fast, debugging is fast and not so tedious. I estimate you can be 2-3 times faster writing in Smalltalk versus Python.
• software maintainability. The moment comes when software must be changed to adapt to new circumstances. In C these are often hard times, in Python better, but still, it's imperative nature may require you to understand the conceptual workflow of the entire application. The change from Python2 to Python3 was an example of this problem - people are still getting paid to convert scripts to Python3. Here, Smalltalk shines. It is a system made for changes and evolutive software development. There is no difference from the concept of software creation and software change, you work in the same way and Smalltalk, by default, brings the entire development environment with itself, editor and debugger included. In Smalltalk you always work on the running program. There is no concept of switching it off, changing the code, and then running it again. See it this way, for a "Python is better than C" zealot you will hear this argument: "There aren't boring compile steps". A Smalltalk zealot laughs at that, he may tell you "There aren't boring shut down, correct, and restart the application steps", the application is always running.
• vendor support. Is there a company that sells an implementation of your language? This can be useful, if you get in real trouble you would know where to ask for help at any level. For C, sure, there are several compiler vendors. Python is a community-only language and as far as I know there isn't a corporate release of the language, there are though thousands of Python software houses so you can consider yourself kind of safe. In Smalltalk there are vendors with a private implementation of the system, for example VisualWorks. If you are in a corporate environment consider well the option of using their services. Also, their documentation might be far superior to open source projects. It is an option to keep in mind.
• self mutability. At times you may want to do something unusual. Maybe you would like to change the language a bit, for example a change in the standard library. Let's say I want to teach the String class to recognize Italian words, say i want a String to be able to answer the question 'isItalian'. In C there is not even the Class concept, in Python there are Classes but you just can't di it, the standard library is sealed you are not supposed to change it. In Smalltalk you can change whatever you want, you want to change the meaning of '=' between Floats? You can. Add a new operator '@=' to return true if two numbers are equal if their distance is less than 0.00000001? You can, and it is very easy, there isn't an arcane syntax, it is just standard procedure.
• the fun factor. After the birth of my first son I had to put a hard stop on Smalltalk coding. More urgent things popped into my hands and I had to restrict my coding to the minimum effort tool to get the job done. In my case it turned out to be a sh script or Python or Ruby. Let's restrict to Python, the most generic tool. I can be very productive in Python, I have all libraries for what I need and I can operate from the shell, I don't need a GUI, which for server people like me is a major source of problems. But programming in Smalltalk is really another life with respect to Python, even using Python as a Lisp, so REPL'ing all the time, testing all functions and objects and methods. There are 2 key points here: (1-observability) in Smalltalk, most of the time, you can see well the data structure going around your code since they are just objects. (2-correct-rerun-running-code) in Smalltalk when the program breaks it doesn't just tell you, "I found a problem in line 345" and spit at you the dead body of a stack trace. No, in Smalltalk the debugger opens and you are brought to the middle of the things while they are still happening. This is really, really the best experience. Lisp does kind of the same thing but inspecting live data structures in Lisp is a major source of pain.

There is a first factor which is very important which is execution speed. Some languages are faster than others for example C is faster than Python and Smalltalk, so if speed is of paramount interest, let's say you are writing a new matrix multiplication algorithm, it is better you just do it in C.

Pure v.s. Mixed languages. Python is an imperative programming language which borrows some Object Orientation principles, some functional style and tries to make everybody happy. Consider this l = [1,2,3] you made a list, you can't say l.len() as it should be if Python was reasonably object oriented, no, no, you must do len(l). This is just arbitrary. There is not a global plan in the Python language, it grows to accommodate new fashions. Smalltalk is completely different. In Smalltalk there is a plan, a view of the world and it is inescapable, everything is an object and the only thing you can do is send an object a message. Therefore if I tell you that the format to send a message to an object is OBJECT MESSAGE then you already know that if L is some kind of list object and size is an available message for it, for sure, you can just do L size. Do you want to upcase a string? what if S is a string you just do S upcase.

A programming language v.s. an operating system. ...

Closed languages vs. Open languages. Suppose you want to teach a Python string how to do something. That is, for example, you read a CSV file or are receiving data from a web form, you are parsing fields and you have one for phone numbers. You may have prepared a proper PhoneNumber class to deal with this kind of data but when you read the CSV it will arrive to you as a String. So you would like to do something like this: '+39425805040'.toPhoneNumber()   well, you can forget about it, you can't do it in Python, built in data structures are untouchable. In Smalltalk instead it is a very simple process, you add the toPhoneNumber to the String class and that's it, your program now knows how to transform String into PhoneNumbers.

Chained v.s. unchained languages. Suppose you are dealing with a very special problem and you need to redefine a builtin method.... no tail call regression ...

Live programming environment vs. Write-Run-Stop-Write-Run loop. This will seem like magic to you, it was for me. The way we are used to programming a computer is this: we write a program, run it, see what does not work, stop it (if it does not die by itself due to a bug) write in a correction, run again. Repeat the loop, this is your programmer day. If you are unlucky there is also the compile step, if you are really unlucky add the reboot step. Well, forget about this horrible situation, the Smalltalk programming environment is always active! Smalltalk never stops, when a strange condition happens a debugger pops up and asks you 99% of the time "This object does not know how to answer to the message you sent it, what do we do?" . It is nothing dramatic, you teach the object how to answer the message and the program goes on. It seems unreal, but it is just like that. Your programmer day is now building nice objects which are able to understand messages. It could be that you are a scientific programmer and you need to teach the object Matrix how to deal with a message eigenvalues, it could be you are into web programming and your WebServer object has received a message getPriceItemWithCode:231231231 it does not matter what you need to teach your computer, the scheme is fixed, it is just objects and messages.

HackableSystems vs. LockedSystems. Suppose one day you want to change your control structures, for example, in your application, you would like to define a different kind of for loop, let's call it the forgettyFor, that on each loop if forgets to iterate over one element taken at random. That is not going to be easy in Python. In Smalltalk it is trivial, because the for loop is achieved with a message, if you want to define forgettyFor it is just matter of defining a new message.

Maintainability. The order spurs from the object system. ...

Live inspectable and changeable objects. This concept does not exist in python.

The magic of the event system.

Programming by simulation.

The image. In Smalltalk there is the concept of the image. This does not exist in Python. The image contains all your program and state, always. At some time you can tell Smalltalk to save the image to a file and then, another day, recover to that exact point. You can send the image to a remote colleague for him to see what you are seeing right now, no differences. This can be extremely helpful in at least a few circumstances, you found a bug, you would like to make a proper correction but for the moment the program needs to just run, so you save the image into a file, make a quick fix then send yourself the broken image to produce a better quality code patch. Consider another case, you are doing a simulation, there are several random variables, and the simulation took hours or days to complete. You see some incredible results, you need to think about it, show it to your colleagues, so you save the image into a file and when you will be ready you can inspect whatever you wish. Isn't that fantastic? A few other languages have images, like Common Lisp and R, but in Smalltalk the image is even more interesting because with its integrated environment looking into variables (which for us are objects) is a pleasant activity compared to digging into data files, core dumps or JSON structures from the command line.

ease of code hiding. If you are not running an opensource project soon enough you will hit this problem: "If I leave my code open my software will be copied and I can't sell it to anybody". This is an unfortunate truth. So, if you need to hide your code, at this moment in time, Cuis-Smalltalk is not the tool for you. AFAIK the same goes for Pharo and Squeak. You may wish to try some commercial Smalltalk, for example Cincom.