Ruby Instead Of Smalltalk

What are the advantages of RubyLanguage over SmalltalkLanguage?

Depending on your POV, these might be advantages.

Deleting flamage it's still not clear what's being claimed here. If ruby/svn/darcs can match per-object versioning, great, explain how - it's not clear. If ST images, and their version control, are superior, great, explain what you do with them that leaves the rubyists floundering in your wake. These are both TuringComplete languages so there's no doubt you can do these things - but if you have to reimplement an ST compiler in Ruby to do it, or vice versa, no sale.

Explanation of Traditional (ex:subversion) vs Smalltalk (ex:Envy/Developer) version control: Envy uses a per method version control database that keeps track of all your changes at a per method basis. It also allows you to close a class from further changes and thus "releasing" it to the rest of your team. Integration developers can then pick and chose from the class database to select what version of the app to use. The UI is very slick and programmable. By comparison, filebased tools like subversion require you to do odd things like "branch" to work on concurrent versions of things and have a real file-based mentality to them. Envy knows about classes, methods, and "applications" and can help you build an app from several parts quite powerfully and easily. It handles component versions very elegantly. It is hard to explain if you haven't seen it. But clearly superior to anything I've seen in the file based world. (Java's Maven has some ideas that are similar, but the clumsiness of jars compared to ST's "applications" and versions makes it less impressive). --AM.

Likewise no one here is stupid and we'd all like to benefit from your experience whoever you are - if you can just explain same without carrying on like some kind of Tourrette's victim.
Deleting flamage, I'd like to start by taking a slightly different tack - a RubySmalltalkChallenge. Whichever language requires the larger amount of code to satsify this challenge arguably has the less flexible notation.
[Chiselling away more flamage ...]

Arithmetic precedence is incompatible with ST because ST precedence is based entirely on associative (partial) ordering. Consistent use of this permutative ordering contributes strength to the syntax that many other lack. But not all - cf. LISP, Prolog, Forth. In any case the first principle of design is to make your system internally consistent.

The first lemma is to not introduce rules from foreign systems. Ordinary human beings learn entire systems easily so long as they're consistent. AnswerMe: this feels intuitively correct, but can someone provide some substance / citations to this assertion? In fact, they learn entire systems more easily than minor deviations between systems. Such as, for example, the whole Algol family mess. Or the SQL family mess. From little compromises spring big ones.

Smalltalk's designers did such a good job because they conceived of Smalltalk as a complete self-contained system. Whatever rules they came up with, they knew would apply everywhere, and they knew that no other rules would be relevant. Smalltalk is Everything. But even in the case of incomplete non-contained systems, it's still better to design them as if they were self-contained.

But,

Consider the PrincipleOfLeastSurprise. If the language does not support infix notation, that's fine. But if it does, it must support the overwhelmingly most common OperatorPrecedence, that of everyday math, or the users will have problems. Should users be forced to conform to their tools, or should the tools conform to the users?

On TheGrippingHand,

Everyday math is a language. ST is a language. They're not the same languages. Me, I've always liked the old Peano precedence notation (ab is tighter than a.b is tighter than a:b is tighter than a.:b is tighter than a::b ... and feel free to whack operators in between the multidots). That's math notation too, just not an algolish one. There are many commonly used languages - forth, lisp, blitz libraries in C++ - that do not conform to the PrincipleOfLeastSurprise. This is no big deal, and ST's precedence convention is neither right nor wrong.

Ruby's precedence system is less terse than ST's, and conforms to the POLS, which is why you might want RubyInsteadOfSmalltalk for Algolish audiences. The purpose of language being to communicate, this is one reason why you might choose RubyInsteadOfSmalltalk.

(See RubyIsSmalltalkMinusMinus for opposing viewpoints.)
FebruaryZeroSix
CategoryRuby CategoryDiscussion currently

EditText of this page (last edited March 13, 2014) or FindPage with title or text search