Can Learning Smalltalk Make You A Better Programmer?

Slashdot reader horrido shares an article that "has done more for Smalltalk advocacy than any other article in memory." It was the second-most popular article of the year on the Hewlett Packard Enterprise site TechBeacon (recently passing 20,000 views), with Richard Eng, the founder of the nonprofit Smalltalk Renaissance, arguing that the 44-year-old language is much more than a tool for teachers -- and not just because Amber Smalltalk transpiles to JavaScript for front-end web programming. It's a superlative prototyping language for startups. It's an industrial-strength enterprise language used by businesses both big and small all around the globe... Smalltalk's implementation of the object-oriented paradigm is so excellent that it has influenced an entire generation of OO languages, such as Objective-C, Python, Ruby, CLOS, PHP 5, Perl 6, Erlang, Groovy, Scala, Dart, Swift, and so on. By learning Smalltalk, you'll understand how all of those useful features in today's OO languages came to be.
The article also argues that Smalltalk pioneered just-in-time compilation and virtual machines, the model-view-controller design paradigm, and to a large extent, even test-driven development. But most importantly, Smalltalk's reliance on domain-specific languages makes it "the 'purest' OO, and one of the earliest... It is often said that programming in Smalltalk or Python is rather like Zen; your mind just flows effortlessly with the task. This is the beauty and value of language simplicity, and Smalltalk has this in spades... Smalltalk, by virtue of its object purity and consistency, will give you a profoundly better understanding of object-oriented programming and how to use it to its best effect."

Comments

Well rounded.

[Anonymous Coward]

Smalltalk, Forth, LISP, and FORTRAN.

Re: Well rounded.

[the_mushroom_king]

Cretin, I do my interfaces in PCL 5! Wastes a lot of paper though ...

Re:Well rounded.

[admin7087]

These are quite nice and powerful languages, although I'd personally like Forth more if it was a bit less low-level. For startups, I recommend CommonLisp (SBCL).

Re: Well rounded.

[ls671]

java

Re:Well rounded.

[lgw]

Well learning any language makes you a better programmer.

Only if you're totally new to programming. Once you have your head around the basics: pointers, recursion, and lambda, you're not going to learn much from just toying around with a language.

The only breadth that's useful to a professional is depth multiple times. Spend 3-5 years getting to know the ins and outs of a technical stack, everything the common libraries have to offer, how maintainable code really is, vs what looked cool at the time.

Then do it all again with another tech stack. And another. This is how you become a senior engineer.

depends

[Osgeld]

on how far down the rope you want to go

if you want to learn the core original idea's of modern programming as some academic / archaeological adventure, yes small talk has a lot to offer as its a very influential language

if you think you are going to magically going to get 100x better at C# or java just by reading some generic summaries of how it works, then no you will not benifit in any such way ... cause the best of such an old language has already been extracted and implemented decades before hand and you already us it

Re:depends

[Darinbob]

You probably will learn why newer languages are trying to emulate Smalltalk but also failing and how they could have done better. Smalltalk is a high bar that very few other languages can reach. Smalltalk works because it never started life with the implicit goal of being compatible with older languages or paradigms. C++/C#/Java all screw up because they attempted too hard to be C-like, to be familiar to existing programmers, and to not rock the boat too much. Other scripting languages seem better at this but still have some major flaws in places (code blocks not being first class objects, not underlying object structure, trying to be just a language instead of a complete system, etc).

Re:depends

[serviscope_minor]

Anything you know today is just a bad implementation of Smalltalk (or Lisp.)

That's just utter garbage. If you can't replace $LANGUAGE with Smalltalk/Lisp for technical reasons then $LANGUAGE is actually superior to Smalltalk or Lisp in its niche, not a bad implementation thereof.

So, let's start with the basics. I'd like to see you try to get a smalltalk or Lisp implementation on two of the microcontrollers I use. They're both 8 bitters. One runs at a swift 32MHz (2-5 cycles per instruction) has a generous 2k of RAM and 128k of flash. The other runs at a more sedate 16MHz, but with mostly single cycle instructions (no hardware divide though) but has only 32k flash.

The former I program in C, the latter in C++.

On the larger end I've yet to see anything even hinting of replacing C, C++ or FORTRAN for numerics and scientific code, especially back-end performance intensive libraries, because nothing can touch them for speed. Actually, Rust is about the only thing that could because it's got the same kind of memory/machine model as C and C++, but it ain't there yet.

Even if you move on from strictly technical reasons, there have been lisps available FOSS for donkey's years (dunno about smalltalk), and it's frequently been taught in universities. Yet despite education and availability it's yet to set the world on fire. I think it has something serious missing compared to those "bad" implementations.

Re:depends

[admin7087]

This kind of hatred is of no use. You need to learn to face your fears and deal with them, rather then projecting them onto others.

Re:depends

[Darinbob]

C++ is basically not very object oriented, especially with later incarnations which focus on generics instead of real objects. And because it explicitly wants to be compatible with C, you're stuck with a machine oriented model, memory management (too hard to bolt this into a language that has pointers), and so forth. Trying to be a C++ killer is the fault of those languages, C++ generally gets used in area that Smalltalk is not used for. Smalltalk is great for rapid prototyping, C++ gets used by people who want somewhat efficient (though it fights against itself here). The C++ killers aren't trying to be great for rapid prototyping, they instead want to be the C++ replacements and grab the same market share. Smalltalk also has a model where it is a full system, not a language, its objects stick around after a reboot. This adds complexity but not much different than C++ and a DB plus UI.

Re: depends

[horrido]

Ruby is missing two of the most important "good parts" of Smalltalk: 1) its absolute simplicity and minimalism of syntax; and 2) its live coding/debugging environment. Ruby syntax can be a bit gnarly, esp. its "Perlisms."

Re:depends

[geoskd]

C++ is basically not very object oriented

That is *not* a bad thing. OO is not a good solution for every problem. Neither is procedural programming, nor functional programming. A good language is whichever one allows you to solve the problem at hand in the most optimal way. The kinds of problems that Lisp is good a solving, C is not. The kinds of problems that C is good at solving, Smalltalk is not, etc. C++ is an extremely capable language because, while it is not optimal for solving most types of problems, it is workable, and not badly suboptimal. This means that as a programmer, if you are choosing a language for a new project, and you don't fully understand the project, you are almost certainly not shooting yourself in the foot by choosing C++. The same cannot be said for the majority of languages out there. If you are not working close to the metal, then choosing C is going to make your life miserable down the road with no real ebenfit, especially if you have to do any higher level work or UI work. If you need performance at all costs, and you have chosen Python, Lisp, Smalltalk, or the vast majority of other languages, you have made a very serious error. With C++, you can achieve excellent performance, rivaling, and in some cases even exceeding C, but you still have the *option* of using an object oriented model, if that turns out to be useful.

Re:depends

[TechyImmigrant]

on how far down the rope you want to go

I used to program in BASIC, then assembly on an Apple ][

30 years later I've regressed to making new CPU instructions.

In another 30 years I've be making new types of logic gate I guess.

Mind blowing

[Santana]

I was surprised, maybe shocked, by how much Smalltalk has contributed to the world[1], how far we have deviated from it[2], and how slowly we are converging to it again[3].

[1] object oriented programming, virtual machine, just-in-time compilation, test-driven development, Model-View-Controller design pattern, object databases
[2] inventing problems by trying to coerce static typed programming languages to behave like dynamic ones (Java, Go, et cetera, I'm looking at you)
[3] by slowly incorporating Smalltalk features into current popular programming languages. Ruby for instance is heavily based on Smalltalk.

Re:Mind blowing

[Darinbob]

Ruby is pretty good, just ignore the Rails crap. It has a big flaw in that it did not make code blocks into first class objects, and then another flaw that it tried to patch this in after the fact with very heavy weight code block objects. So it superficially feels like Smalltalk until you use it enough that you start wanted to just have Smalltalk instead.

Re:Mind blowing

[Dog-Cow]

I watched a presentation given by Kevlin Henney (videos on YT), in which he quotes someone (don't remember who) who claims that COM is one of the purest implementations of OOP ever. COM objects can't interact except through published interfaces, and one cannot even find out what kind of object one is communicating with.

MS has all sorts of faults, but they do actually understand computer science. They also have a very pragmatic side.

Re: Mind blowing

[Malc]

COM came with cross language ABI compatibility; separation of interface and implementation. From this perspective it was a very practical and useful technology. It got pretty damn complicated with ATL and I worked somewhere that created lots of custom objects defined in C++ rather than IDL derived from Microsoft ActiveX controls, but that's a different story. It remains a useful technology on Windows that sometimes makes integration of components from different places easy, especially if you've only got a legacy 32-bit library and want to use it in a 64-bit app.

Re:Mind blowing

[lgw]

Ruby is terrible for server-side code. It's a toy language with crappy support for exception handling and multi-threading.

Real production code requires structure for maintainability. And you're generally better off when that structure comes from the language itself, rather than coding conventions. Static typing is always going to be more maintainable than noting parameter types in comments. Finding problems at compile time is always going to be better than finding the same problem at runtime. Duck typing makes it easier to write that first line of code, but is the bane of code maintenance.

Uh...

[ckatko]

While Smalltalk clearly has plenty of influences in later languages, from everything I've ever heard or read, the language to learn is LISP--not Smalltalk. I've heard countless stories of people saying it retrains your brain and opens your eyes to new ways of solving problems and that "It's the best language to learn that you'll never actually use." (Because it helps in your normal life.)

It's like learning Latin in school, to help you appreciate English.

Re:Uh...

[Anonymous Coward]

> LISP is a brilliant language for learning about core ideas in that domain

Actually that has not been true for a while now.

Lisp was innovative back in the day for its ability to easily manipulate data structures. After all, Lisp's homoiconic syntax and macros meant that you were essentially manipulating thinly disguised ASTs. AI back then was symbolic in nature (think natural language processing), so Lisp fit the bill really well.

However, the symbolic school of AI has not been dominant for years -- the current trend for AI is statistical and data-driven. Also, other languages have caught up in terms of rich data structures. It's still worthwhile learning Lisp to understand a subset of functional programming constructs (with the qualification that Lisp is not a fully functional language -- people don't realize this). But it is no longer useful to learn it for the purposes of AI. One would be better off learning Python.

Re:Uh...

[serviscope_minor]

It's like learning Latin in school, to help you appreciate English.

And much like Latin, it probably encourages large numbers of people to inappropriately coerce things into an inappropriate mould. For example insisting on things like not splitting infinitives.

Re:"prototyping language for startups"

[horrido]

Smalltalk has been commercially used for over three decades. It’s not some esoteric, academic language but a truly practical, industrial tool. Cincom’s and GemTalk’s websites list some of the companies they’ve served from all kinds of industries, including JPMorgan, Desjardins, UBS, Florida Power & Light, Texas Instruments, Telecom Argentina, Orient Overseas Container Lines, etc.

Yes, this was my experience as well

[robert bitchin']

I started off with Turbo Pascal 3-4 back in the 80's (had OO before anything else back then) then moved to Smalltalk. It was a true mindfuck at first, wasn't able to do the simplest of tasks. Where are the files? How do I get a library for X? !@#$ But eventually the fog lifted and I got productive. It was still hard to explain its virtues to everyone else and deployments were a challenge (VM? what?) but then Java came along and I moved to that in 97. Most of my contemporaries doing the same were coming from C/C++ and their experiences adapting to that were hilarious compared to what I was experiencing. In short I was the quitessential nickel-get-yourself-a-new language neckbeard, disgusted with the compromises made to entice the C community: lame syntax, files, primitive types, overstrong types, etc. Still bringing home the bacon with Java but its been painful having to watch the industry reinvent all the same core concepts over the last 20 years. Its not surprising that the GoF came from the Smalltalk community, the language effectively voids all the useless baggage that comes with other languages, forcing you to confront and identify all the core concepts in your problem domain.

One of the most interesting things I've been seeing is being able to identify the mental origins of developers who've drunk the Smalltalk Kool-Aid so long ago, it shows up clearly in their designs. All domain concepts as first class objects, no data-only structs, effective pattern use, quality name choices, tight and effective hierarchies but most of all semantic clarity. You can only beat junior devs on the head for so long in code reviews to have them put these things into practice before you realize that they're coming from a wholly different perspective. As we move into a post-OO world with functional programming I can imagine the Haskel et al folks gritting their teeth in the same manner.

Re:Yes, this was my experience as well

[Cederic]

no data-only structs

Hasn't that war already been lost? I thought RESTful APIs pretty much killed it off.

No data-only structs is a beautifully purist vision but also pigeonholes all data into a specific object type. Separating data from the code that does the work with the data means you can easily do different work with the same data.

Shit, look at the whole Big Data arena. Wrap all that data in behavioural constructs and you'd flounder.

I went through this whole design debate/cycle between 1998 and 2000, and haven't looked back since. Rather surprised to see it suggested here now.

Re:Yes, this was my experience as well

[faragon]

Turbo Pascal 3/4 had not object oriented stuff. "Object Pascal" was introduced in Turbo Pascal 5.5 (link).

Yes it can, but that doesn't mean it will

[mark-t]

Learning *ANY* programming language can make someone a better programmer... offer them a new way of looking at how to solve certain types of problems and innovate new and elegant solutions that hadn't occurred to them previously as they learn the idioms of a new programming language.

But like any other programming language, learning it will *NOT* necessarily make you a better programmer, and there's certainly not anything unique to Smalltalk that might make becoming a better programmer after learning it especially likely.

Smalltalk was ahead of its time

[jonwil]

Its too bad the money men at Xerox at the time (who mostly came from places like Ford and didn't know the first thing about computers or technology) didn't realize just what they had with the Alto, Ethernet, Laser Printer, Smalltalk etc and actually allow the PARC guys to get it out of the lab and into the real world much earlier than they eventually did...

Yes, but who has the time?

[tgibson]

Though I came to Smalltalk after C++, there is no doubt it informs why all things OO are the way they are. However, who has the time to attain this insight? I programmed in C for three years before learning C++ in the early '90s and there is no doubt that my knowledge of C makes many design decisions behind C++ clear (e.g., how many "young" C++ programmers actually know why the designers of C++ foisted the Rule of three onto the language). But I was too busy keeping up with endlessly changing technologies to learn, say, BCPL, to better understand the design decisions behind C.

Run forward, nascent programmers! Your knowledge of (choose your modern language) today will inform the design behind the language you learn ten years from now.

Re:Yes, but who has the time?

[DrXym]

The Rule of Three was not a design intent of the C++ language, it was an after-the-fact bodge to fix the terrible default byte copy that C++ helpfully adds whether its safe or not. Entire books are written about writing effective C++ and most of them are working around really poor, unsafe behaviour that you get by default or bad language choices. Even if someone fastidiously follows Rule of Three, it's still easy to screw up in subtle ways, such as not checking if an instance is being assigned to itself.

The correct design would not support any default copy / assignment operators on any class. Make it an explicit programming intent before adding support, e.g. require the class to have a pure copy constructor / assignment operator as a hint for the compiler to fill in or actual implementations supplied by the programmer .

C++ has tried to retroactively add stuff like move semantics (causing overload resolution to become ridiculously more complex than it already is) and now has some scoped / shared pointers that can catch copy problems but the reality is its still unsafe-by-default.

It may explain why languages like Rust that take the opposite approach are gaining such popularity.

Re:Smalltalk also had major failings ...

[Anonymous Coward]

Having developed applications in Smalltalk I can say it had some major failings too. Serious development absolutely required Envy Developer otherwise it was impossible to deploy into a team environment (there are no files to share).

It also was nearly impossible to deploy standalone applications. You had to strip out the development environment, and other objects not necessary for production. Take out too much and sometime later you get a "not implemented" error.

All of its deficiencies could have been fixed eventually but very few companies outside of educational incubators really bothered. The Smalltalk industry was rife with overpaid contractors.

Re:No.

[angel'o'sphere]

Is that an attmept to be funny or are you retarded?

The fact that no other system adopted the 'image' idea of SmallTalk clearly shows how less the people writing the article and the comments in this story actually have comprehended about SmallTalk.

And Smalltalk does not use special punctuation for its syntax, you must mix it up with something other (C++/Java?)

Except for being OO â" more or less â" the other languages have not really adopted much from SmallTalk. There are still 'programmers' on /. that debate the usefulness of lambdas in Java 8 ...

The good things of SmallTalk besides being OO:
- seamless melding from runtime to language system and OO, global dictionary etc.
- all majour language constructs are represented as objects
- can be queried, augmented, inspected used in reflection etc.
- 'bytecode' can be inspected, transformed etc.
- everything is in the 'image', the IDE is included in your program, unless you strip it
- oo database included, files only used for data exchange

You don't need 'constructors' to set up a complicated UI, you simply create them in the REPL of the IDE, move them where you want them, save the whole running program as an image, next time you 'restart' it, the UI is 'just there'.

SmallTalk is still light years ahead of any other programming system ...

Re:Wow, another paid-for article

[doom]

This site used to be a respite, A place for techies to go to get away from those evil advertisers.

Look, what makes you guys think this lukewarm whining is even going to register on the slashdot editors? They've been listening to programmer's bitcing and moaning for decades, you're going to have to amp it up if you even want to begin competing.

(You think you've got it bad now? You have no idea what kind of stupid shit Commander Taco could come up with.)

Re:No.

[Billly Gates]

It could be worse. Can you imagine a language that would require invisible white spaces as syntax to ever become popular? lol ... Oh shit wait

Smalltalk today is a dinosaur

[SoftwarePearls]

Sure, Smalltalk is a great language to know.. if only to understand some of CS history. But it is a horrendous technology to use today, or for the past 10 years. I speak from experience. I've worked with Java and Smalltalk as a professional, and the Smalltalk experience pales into insignificance. The tools just haven't kept up with the crazy pace of technological evolution. The Smalltalk "IDE" I had to use professionally was Cincom's. I couldn't believe how primitive, clunky and programmer-hostile that system was (if you've ever spent a few years with any Java IDE). Since working professionally with Smalltalk, I've also kept an eye on the marketplace for the skill.. in Belgium (which is a small sample, I agree), the demand is very, very close to non-existent. I only know of two companies that still cling on to it, against all rational arguments.

Re:object oriented programming

[lgw]

Messages are fundamentally the problem with OOP. Duck typing is the very thing that makes code maintenance hard. Oh, sure, it can make code easier to get started with, but easy to maintain trumps easy to shit out code any day.

Re:object oriented programming

[lgw]

I don't care about academic arguments. I just know what sucks to maintain, and code without compile-time type checking sucks to maintain.

Sure, no argument, static typing is just the wrong choice for elegant toy programs that no one uses.