Learning Smalltalk is not a waste of time
medium.com
medium.com
I believe I grasped the more interesting ideas in Smalltalk when I approached it not as just another programming 'language', but rather as a complete programming 'system' in itself - a virtual computer, if you will. Instead of files, this system contains 'objects', which communicate with other objects via messaging. The entire network of objects is transparently persisted and implementation details are themselves represented as objects-with-messaging (i.e. self hosting). The UI is just another mechanism to send messages (clicks, keypresses) to some objects, etc.
It's unfortunate that something like Unix with it's primitive notion of files, processes and 'stream of bytes' thinking has become the dominant environment, rather than something like Smalltalk - where the objects are reflective and communicate with semantically richer messages.
It feels like a nice way to break out of the bubble of that Rob Pike famously lamented in http://herpolhode.com/rob/utah2000.pdf.
Interestingly there is an Pharonos project (maybe defunct now?) http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos
Plus ignoring that the creator of Smalltalk, Alan Kay, is a fan of Lisp himself and on the early 70s these two were the main languages for OOP and had mutual influence. Not to mention that the early alma mater of Smalltalk, Xerox PARC, was also a center of innovation for Lisp as well.
No problem at all promoting Smalltalk, but when articles are just clickbait-y and have claims with no technical substance, they become articles for their own sake.
Like in ruby, you can code "in english" but once you're trying to find a bug, it's not easy to tell what is and is not possible to happen, you just have to run it and see where it dies.
This is to some extent similar to macros. They are also very powerful but should be used sparingly.
It's definitely great experience (I especially like the fact that what you see in browser is not code but actual object memory which get serialized to string) but you should be warned that this is not probably a good fit for production applications done by bigger teams.
That said, I think I differ in terms of what I believe a language offers, and given the criteria prescribed in the article, smalltalk is actually probably not a good choice. For example:
> Your first programming language will never be your only programming language
Yes, but for a first language, isn't it more pragmatic to learn a language at the intersection of more popular languages? If you knew you were likely to want to speak English, French, and Italian, would you really opt to start with, say, Swahili or Korean?
> The best way to learn how to program is with a good teaching language.
His argument here doesn't make much sense. I think a "good teaching language" is less about the language and more about the availability of teaching material. The language semantics are trivial to pick up once you have a good foundation, so why not focus on the foundation (and not the language), and pivot as you like afterwards?
> There is no better way to learn about object-oriented programming (OOP).
I'm going to call shenanigans on this one. Learning good OO design isn't going to magically come as a consequence of learning _any_ language, and smalltalk being the paragon (supposedly) is a silly notion. Tons of languages have delivered new paradigms as a result. By this argument, we should just learn every language as our "first" language to learn concurrent/functional/low-level/etc concepts best
> It’s a great hobbyist language.
It depends on your hobby! If you like making console games, uhhh you're shit out of luck with small talk aren't you. Or what if you enjoy experimenting with large datasets. Do you really want to work with a smalltalk-to-tensor flow API?
For the record, I'm not saying OP can't learn smalltalk. Just that in being defensive, it's not good to pendulum to prescriptivism.
I don’t think I grasp the idea of a “good learning language”. I don’t consider myself experienced enough to argue about which languages are better than others, but I do know something like Windows command line is a bad language and I would say it is also a bad learning language for that reason but not because it is bad for learning.
I would argue the best learning language can be determined based on:
1) Extensibility
2) Applicability - applicable to the student’s current motivation
3) Expressibility - expresses core programming concepts relevant to the student’s learning level
4) Community - community is actively inviting of those at the student’s learning level
It’s popular to say Python is a great learning language for beginners in that it’s easy to read and hides much of the intermediate/advanced functionality when doing only beginner operations. But, in my experience, that characteristic led to a slightly steeper learning process when I got to that point.
I learned to program with C# and have no complaints.
If I had it all to do over again, I would have started with C, but this is only a retrospective view because my initial motivation required C#.
Eh, I disagree. It may be trivial to "roughly know" the semantics of most languages, but some languages have rigorous semantics that are complex enough as to prevent beginners (or even most programmers) from learning the full rigorous semantics; this means they're forced to rely on the "rough semantics". For example, many gotchas listed at https://stackoverflow.com/questions/530530/python-2-x-gotcha... come from the "rough semantics" most people have in mind not being an accurate reflection of reality. (Not picking on python, I still think it's a great teaching language). In contrast I took a course designed to be a first CS course, taught in Racket, and while beginners will of course spend most of their time learning the "intuitive skill" of programming and knowing what a program means, it is nice to have something to fall back on when those skills fail.
Its simple syntax, within a logical and consistent language, makes it (in my opinion) the best way to pick up OO concepts. Being highly 'visual' is definitely an advantage that very few other languages can offer.
I agree.
But if we stretch the analogy to try and make it work, then certainly Algol was the de facto language used to publish algorithms, and it is the syntactic basis of many widely-used modern languages.
As for the "fiddly grammars", etc., Algol 68 did not have a simple grammar. Quoting Wikipedia's "Algol 68" page:
> ALGOL 68 has been criticized, most prominently by some members of its design committee such as C. A. R. Hoare and Edsger Dijkstra, for abandoning the simplicity of ALGOL 60, becoming a vehicle for complex or overly general ideas, and doing little to make the compiler writer's task easier, in contrast to deliberately simple contemporaries (and competitors) such as C, S-algol and Pascal.
and
> ALGOL 68 allows for every natural language to define its own set of keywords Algol-68. As a result, programmers are able to write programs using keywords from their native language.
Quoting Wikipedia's "For loop" page:
> Algol68 has what was considered the universal loop
allowing such constructs as
FOR i FROM 1 BY 2 TO 3 WHILE i≠4 DO ...
for index := 1 step 2 until 50, 60, 70,
80, index + 1 until 100 doI completely agree that the premise of the analogy is a stretch, and can accept that people want to reject the premise (it's not quite as bad as "What kind of vegetable are you?"), but I don't see why fractallyte's claim for Smalltalk is stronger.
Algol-60 did, and that's the basis for comparison when somebody qualifies a language as "Algol-like". Some languages that have extremely close syntax to Algol are Pascal and Go.
Algol-68 is a later language, really a very advanced language, even more advanced that some "modern" languages. The criticism of its complexity should be considered within the context (year 1968).
Smalltalk certainly belongs to that group of languages (others would be Scheme/Common Lisp). Smalltalk is the fundamental OOP language. Everything is an object. Classes, numbers, booleans, all can have methods. Actually another interesting property of Smalltalk is, that constructs like if/then or for loops are just methods on the boolean and integer classes respectively.
Being dynamically typed, Smalltalk also does not force you into inheritance just to satisfy a type signature. Java got that almost right with the interfaces, unfortunately too many libraries rather require you to inherit from a base class instead of implementing an interface - Go put that to extremes by only offering interfaces but no inheritance.
Finally, Smalltalk is always integrated into some sort of IDE and class/object browser, mostly doing image-based development.
So, even if one is never going to do a larger project in Smalltalk, I can only recommend getting familiar with Smalltalk and its concepts, it changes the way how one thinks about OOP in other languages too.
The author picked only those old language which still have great value.
The author did not include such languages as Algol, JOVIAL, MUMPS, SNOBOL, or TRAC. There are a lot of old languages with little modern value. (Then again, a lot of new languages have little value.)
Since the author did not include COBOL, should I infer that "great value" doesn't include "getting a job developing legacy systems"?
"Old languages shouldn't be discarded as valueless just because they're old. Some old languages have great value".
And not:
"Any old language still has great value".
But how many people really say that Smalltalk is a waste of time because it's an old language? My experience is that it's not a common argument against learning Smalltalk.
That said, I also object to the use of the starting dates as the date for the language when, for example, the C language from the 1970s is not "very commonly used for systems programming" - at the very least that should be ANSI C.
Similarly, I know it's not useful to study the Python of its first release for anything other than historical interest. For one, the __init__ convention hadn't yet been created, so objects were initialized manually.
I think a lot of people in the industry, especially younger ones in startups and fad-driven cultures, tend to discard older languages with similar criteria.
Not just Smalltalk, even something like Java -- "people still use that?".
And when I tried to learn Pharo (which is probably implementation of smalltalk best for learning today) I had impression that documentation is not very good, and there are few good tutorials. There are some big and serious books, there is Pharo MOOC, everything is so serious and academic that gives impression that the language is hard. There's no simple stupid tutorial like in other languages.
I still love Smalltalk but it's elegance (message passing FTW) and purity set a bar too high for me, and it still fell afoul of the fact that class hierarchies create a syntax/behavior that require you to re-learn a lot every time you join a new project (too many companies/projects rewired basic class functionality).
Back in the late 70s and early 80s, to use it you required a system with very big memory and fast processor speed (read: an expensive workstation), and the implementations/compilers were mostly propietary and expensive as well. Same reasons Lisp isn't more popular.
>What are its disadvantages?
There are really no disadvantages to Smalltalk. Although personally i'm not so comfortable with a language that only allows message-passing OOP as its paradigm; and Smalltalk is not the highest performing of languages. OTOH Smalltalk, in 2017, should run substantially faster than some other popular, well-liked programming languages such as Ruby.
I saw Smalltalk running on the Xerox Alto while in an advanced programming language group at Texas Instruments around 1978. Having some background in object oriented programming (from studying Simula-67 and working with MIT's CLU programming language) I was eager to read the excellent Smalltalk-80 books published a few years later. I actually got to use Smalltalk on my own PC when Digitalk came out with Smalltalk/V that ran on MS-DOS around 1986. I liked Smalltalk enough that I considered using it as the basis for a large commercial application I was designing in 1990, but ultimately I decided not to incorporate it in our system for a number of reasons.
Smalltalk is talked about because its design and implementation are very elegant. However, it was designed around the idea of a single user environment supporting a custom GUI architecture. Source code wasn't stored and loaded from files, instead a system image was maintained and each time Smalltalk was started the current state was loaded and started running. The runtime, editor, debugger, even the GUI itself were a part of this image and subject to change as as application was being developed. It was a system seemingly designed for a computer with one programmer working on one program.
This fluidity made working with the system fun and productive for a single programmer, but it wasn't obvious how it scaled up to larger multi-programmer projects. Furthermore, it was interpreted and that hurt back then when computers were much slower. Also, it's GUI graphics was designed around simple bitmapped black & white hardware, no grey scale or color. Again it wasn't obvious how this was supposed to work on different hardware.
These limitations have a lot to do with the history and original limitations of the early systems that Smalltalk ran on, not the language; nevertheless, like other early interesting and seminal programming languages (APL for example) its best ideas were incorporated in future programming languages. The so-called "message-passing" paradigm of Smalltalk can be seen in Objective-C. It's implementation of classes as manipulatable objects themselves with their own meta-classes is seen in Ruby and Python and Common Lisp meta-programming.
C and Pascal were contemporaries of Smalltalk and were both quite successful and influential. They had simpler, file based models for programs. Most systems used punched cards or simple CRT based terminals for construction of programs. This worked much better for C and Pascal than Smalltalk a language made for use with a GUI.
Smalltalk was an early object oriented language, but it wasn't the first. Simula-67 was the first object oriented language and these ideas were further explored by MIT's CLU. At this time O-O ideas in programming were being explored, and this led to the evolutionary development of MODULA (from Pascal), C++ (from Simula67, Algol68, CLU), and Objective-C (from Smalltalk and C) and Ada (from many sources). At the time, I liked the simplicity of Objective-C, but C++ had the important backing of AT&T, was the most efficient implementation of object-oriented ideas, and came out the winner.
C++ was complex being hampered by compatibility with C semantics; this gave Java an opening to become the other important Object Oriented language
Other important developments in programming languages were taking place while this was happening. Lisp (the second oldest programming language in wide use) was splintering into numerous dialects. This was addressed by taking the union of the best ideas and Common Lisp came into being. A reaction to this large language was a small elegant Lisp called Scheme (perhaps the intersection of the best ideas in other Lisps). Object oriented ideas were incorporated in Common Lisp, but a new programming paradigm grew out of Lisp: functional programming exemplified by ML and its derivatives SML and OCaml, Haskell (influenced by Scheme), and their newer offspring: Rust, Swift, and Scala. These and many other further developments in programming languages, sadly, leave little room for a rebirth of Smalltalk.