Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

it doesn't have an if() construct and needs to define methods to dispatch on conditions.

Smalltalk is great (mostly for historic reasons these days) and definitely worth learning. But that bit is cognitive dissonance at its best.

It allows you to extend even the Boolean Logic of your system. With just an ordinary act of defining functions, you can implement something like:

    (condition)
        ifTrue: [ "true" ]
        ifFalse: [ "wasn't true" ]
        ifMaybe: [ "whoa, toy fuzzy logic!" ]
The same goes for looping and other control structures. This makes any DSL you write a first-class language construct equal to anything else in the language.


I know. What it is not is "clear", for any definition of the term understood by a working programmer who doesn't already know the language and grok the new abstraction.

The point was that this followed immediately an explanation of how much more readable (!) the OO syntax was because there was no separate operator (".") for method invocation. If the former is seriously a criteria for "being better than ruby", the Smalltalk condition trick is an abomination, and immensely inferior.

edit to avoid thread continuation: yet again the response boils down to "it's easy if you know it". So to be clear: 1.) I do know it; and 2.) Duh. But the previous point in the blog post seems to be predicated on the idea that learning the "." operator for method dispatch in ruby is somehow "hard" and that it's an advantage to Smalltalk that it has such a straightforward syntax. Those two opinions cannot logically be held in the same brain.


What it is not is "clear", for any definition of the term understood by a working programmer who doesn't already know the language and grok the new abstraction.

Browse menu, "implementors," select ifTrue:ifFalse:ifMaybe: and find yourself in a short method in under 3 seconds. (Most of that human menu-selection time.) Maybe another 5 seconds for someone familiar with the environment and its conventions to read and understand what they are seeing.

You have a different POV, because it's the POV of someone who doesn't yet know how to fend for yourself in a different environment. Once you learn a few tricks like this, it's very empowering. (And it's not an obscure trick. A seasoned Smalltalker lives by "senders" and "implementers")

Those two opinions cannot logically be held in the same brain.

I don't hold those two opinions. I don't think . is hard, and I don't think Smalltalk syntax is so much easier. What it is, combined with code blocks as literals, is a meta-syntax. I think it's more powerful in some ways.


I think the apparent contradiction is because you're subconsciously imposing your own ideas on the post, and those contradict what he's saying.

1. He didn't say Smalltalk's syntax was learnable — he said it was "readable". He'd probably agree that it's more learnable too, but his actual claim was more like "It's easier to mentally tokenize code that uses spaces to separate elements than code that uses dots." This is similar to how many Rubyists feel that using whitespace instead of parens can make code more readable.

2. He acknowledged that it will be awkward if you're already well-versed in languages that do things differently. But this is tautological. Attacking a programming language for being different from other programming languages is a lot silly.

3. It is true that Smalltalk's pervasive object-orientation will be unfamiliar for people whose experience is limited to Algolish languages, but continuing off 2, that isn't really a bad thing. Smalltalk's model is more consistent than Ruby's. There are basically two things in the whole language: message sends and variable definitions. Your objection here isn't that there's a new abstraction, but that there isn't anything new — it's objects all the way down. It's new to you because you know Ruby, but it's not really a new thing in the course of learning Smalltalk.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: