For me a lone developer. I am very familiar with the tools available to me with Squeak. I can search, discover and find code. I have a history of all of my code. I have elegant version control with Monticello. Any time I even consider using something else because it is pragmatic. I have to think long and hard about all of the things I do within Squeak that I would have to find replacement tools and learn in those “pragmatic” languages.

I would have to choose an IDE or editor.
I would have to choose a version control system and potentially have to learn several at least to a certain point, depending on what projects I want to use or contribute to.
I would have to learn the pragmatic language.
I would have to learn the tools for which I am choosing said pragmatic language, ie: Rails, etc.
I would have to learn the debugging tools for said language and environments.
I would have to learn how to search for the code I need to accomplish whatever task is before me.
And these are just the simple things off of the top of my head that I am aware of. The list could easily grow larger.

For the legions of people who have already done all of the above and settled upon answers for these things, then yes, Ruby, Python, etc. can be the pragmatic choice.

But if you haven’t yet invested significant time in the above scenario. Then Squeak/Smalltalk could be a most excellent and pragmatic choice. And even if you have invested significant time in all of the above for your current pragmatic language. Squeak/Smalltalk can still be an excellent and pragmatic choice. All of the above is so elegantly a part of the Squeak/Smalltalk development environment that it is so very productive if you will spend the modest amount of time to learn it. I believe that once you do, you are amply rewarded with a very productive experience.

Basically, just wanted to add that the definition of pragmatic must be that of the individual. And that no single language has that defined for every situation or person.

Squeak/Smalltalk is a very enabling experience. And one you can enjoy the journey. :)

Anyway Ramon, thank you for your piece. Conceptually I completely agree with you, but pragmatically I go with the languages that I can bare to develop in at the time that have good traction and momentum. Unfortunately Smalltalk has neither currently except in a microcosm of the programming world.

Many good points for thought, which is greatly appreciated by this evolving Rubyist.

You can’t extend Ruby and keep the same syntax as Ruby itself, that sucks. There is no one file per method and one directory per class, there are no files, you clearly don’t really grok Smalltalk yet, all those things you’re griping about are features. Smalltalk is a very clean language where everything is consistent, Ruby is full of warts and exceptions for no good reason.

But if you like Ruby, use it. Use your text editor to edit your dead files, I’ll continue to use my browser to edit live classes, files suck. I won’t give up dynamic typing AND refactoring support, only one of which you have in Ruby, and it’s precisely because it still uses files.

How is this beautiful?

“False>>ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock
^falseAlternativeBlock value”

You say, we should not underestimate the power of purity.

I say, let’s not underestimate the beauty of the underlying syntax.

(And btw I dont want to use a GUI when I instead can use text. Ruby is the challengor to Perl, not to Smalltalk. Let the smalltalkers do all their GUI work they want to. And smalltalk has thousand warts built upon the core, how is it that one-file-per-method and one-dir-per-class? This SUCKS. In this case I would rather want to use a prototype-based language with a good syntax and go away with the forced class OOP thinking instead, if someone chooses to enforce such rigid rules without real clear advantages - my source files are highly ordered in a way _I_ chose fit)

We all know that!
Still, Ruby is much nicer than other mainstream languages.
If it weren’t for Ruby I would have never learned Lisp…
So… we’re getting there…

I will tell you that the only real thing that was hyped
is Ruby on Rails.

Ruby however is not. It has built its reputation
exactly for its clean syntax. Something
which Smalltalk isnt famous for.
And the same goes for DSL, which usually,
are cleaner than the underlying language.

You obviously prefer to program “in” a language, rather than “on” a language; good for you, but I subscribe to a different school of thought. I want to work a in malleable language that can be brought closer to the problem domain in order for the code to get simpler.

Paul Graham has a good simple example in his book On Lisp…

(defmacro aif (test-form then-form &optional else-form)
  `(let ((it ,test-form))
     (if it ,then-form ,else-form)))

Where he adds a new anaphoric if that evaluates an expression, and if the output is not null, introduces a new variable binding called “it” into the scope of an if, greatly simplifying that common pattern of code.

Minimal languages such as Lisp and Smalltalk that allow you to extend their control structures via the library are simply obviously better than those that reserve such power to the compiler writer. If you don’t see the value in such abilities, so be it, to each his own. I however, see obvious value in such and think no further explanation is necessary.

A Dr. Dobb’s article illustrates the basics, including DSLs:
http://www.ddj.com/184404172

To make robust DSL’s REBOL makes use of grammars-based parsing. For more on that, see http://www.REBOL.com for docs, or:

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

Why would you need to, you already have an if. You have not presented any example of control structures where they are needed.

Reading the comments we see the following: ifNil:, ifEmpty:, ifNotNilDo:, ifSpam:, and ifNotSpam:

Each one of those can be just as easily implemented such that

if object.nil? #which you already have
if object.empty? #which arrays have (use .any? for enumerables*)
unless object.nil? #also, already there
if object.spam?
unless object.spam?

*yes, I know .any? doesn’t have the same exact semantics as empty? with regard to nils

I see no case presented where you couldn’t simply do:

def Object.spam?
false
end

and then override the implementation where you need to to get real spam detection.

The whole article is useless, you provide no justifications for _why_ it is better. Just because you can do something doesn’t mean it should be done. Tell us why again control structures should be in the library?

So objects and methods are necessary in any language you want to make up with lambdas?

Blocks are just Lambda’s, well, they’re more than that, but they’re used just like Lambda’s and serve the same role within Smalltalk. I made no broad claims nor do I pretend to be an authority on such matters, as with all things on this site, these are just my current opinions and understandings.

The authoritative tone of your article is at odds with over-reaching you do in statements like this.

SKI combinators. Lambda. Self-Calculus. Rho-Calculus. Concatinative Combinators. There are _many_ possible foundations for computational languages. Most of them do not have anything resembling objects, methods, or blocks. By your reasoning we should not call these languages, since they lack the necessary building blocks. Absurd.

Even a passing familiarity with computer science would inform you of this and guide you away from such a broad claim.

I feel like I could have enjoyed the topic of your post, but as it is, it’s too drowned in sophistry.

I’m a Ruby programmer, at least a bit, I use it for unit testing my web apps, and as far as I know, you can’t make a native looking “if” like control structure of your own. If you know otherwise, show me.

As for the polymorphism, I clearly stated “which may or may not be important, just something to note”, so please don’t rebut it like you’re making some point I didn’t already address. You seem intent on misunderstanding, misinterpreting, or simply disagreeing with everything I say, whether true or not, the conversation is no long enjoyable, so I’m done.

Also note, that by not doing it like Smalltalk, and placing the if first, it’d no longer be polymorphic (unless Ruby has multiple dispatch aka Lisp, but I don’t think it does), which may or may not be important, just something to note about the Smalltalk version. In the Smalltalk version, #ifSpam might use different algorithms for different receivers, maybe an e-mail is spammed differently than a blog post, who knows.

I chose #ifTrue:ifFalse: precisely because Ruby does it without using its own facilities for building DSL’s, making it a great case of Ruby’s lack of consistency with itself.

Smalltalk DSL’s look just like Smalltalk; Ruby DSL’s look nothing like Ruby, that’s an important thing to notice.

aComment
     ifSpam: [aBlog blackList: aComment author]
     ifNotSpam: [aPost publish: aComment].

See… #ifSpam:ifNotSpam:, same syntax style as built in #ifTrue:ifFalse:, you the programmer can make up your own mini language that works for “YOU”. The compiler writers could later choose to optimize this, if it ever became so popular is needed to be part of the base language, like #ifTrue:ifFalse:.

So one last time, I’m not talking about #ifTrue:ifFalse:, I’m just using it as an example of a common mini language, because it’s the smallest one I could think of that every programmer knows.

Stop trying to be “right” and start trying to understand what I’m saying, I’m starting to think you’re misunderstanding me on purpose.