Ruby Instead Of Smalltalk

What are the advantages of RubyLanguage over SmalltalkLanguage?

Depending on your POV, these might be advantages.

• Lightweight scripting language,

• Not image-based. Which means it uses files which means anybody can use their favourite editor to type up hello world and get going. Also means that you can use "normal" tools (the same ones you use for C / C++ / etc) to edit, do version control, search, etc.
  • Images are superior to files in most smalltalkers opinions, especially when it comes to version control.
  • AnswerMe: Why? I'd really like to know why, too!
  • For several reasons. First because dealing with an image means you're dealing with live objects, right here and now, and not an indirection. Second because dealing directly with objects which are all precompiled unshackles you from the edit-compile cycle. Third because tools built specifically to deal with code (eg, the RefactoringBrowser) are vastly superior to "your favourite editor" or "normal tools". Fourth because version control is much more sophisticated in image-based systems, like all code-handling tools. By getting the fundamentals right, whether images or references, you get paid back in useful and working high level features, whether IDEs or automated garbage collection.
  • ''Ruby objects work live - pull up a debugger and away you go. There's refactoring browsers for ruby too. There's even one in vim. Ruby ain't precompiled and who would care if it was? Version control cutting edge is SubVersion and Darcs, both of which play fine with Ruby. And GC works just great in Ruby too. So ... um, what are you talking about?
  • I don't understand how images provide superior version control, either. The answer appears to beg the question. I'm understanding from below that each object is versioned, and I can imagine this being a drawback. If I start to work on a feature accross multiple objects then decide to back it out, can I do that? Can I inspect changesets which cut accross modules, objects, and features to see what other developers have done? --JasonFelice

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.

---

• More "familiar" notation. i.e., it has Algol-like syntax
  • Far less flexible notation, ruby cannot cleanly pass multiple blocks {} to a method, a deathblow to the smalltalk mini language style of programming.
    • ''Actually, no, while multiple blocks is cleaner Ruby is famous for its domain-specific language support. The fact that you need an extra . now and then is hardly a deathblow. It's not even inconvenient.
  • Um, if ST notation is so flexible how come you can't get OperatorPrecedence right? In ruby 6 + 4 * 5 will give you the answer you expect, plus you don't end up having to implement basic stuff like short circuit evaluation using blocks.

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?

• Is the "infix syntax" in Smalltalk actually infix syntax which got added as a special case for arithmetic, or is it simply method passing which happens to look the same as infix arithmetic? In the former case, I would say they should have followed through all the way and added precedence. In the latter case, I think they should not be introducing special cases and leave it like it is.

• On a related note, LispLanguage has prefix syntax for everything, but if you really want to you can write a macro that allows you to use infix notation for arithmetic.

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.

---

• More web-oriented libraries (depending on which Smalltalk you mean).
  • Well, SeasideFramework is nice ...
    • RubyOnRails eats it alive. Sure SeasideFramework has the superior mechanism. But precisely because it's written in ST, its mindshare is miniscule.
      • Rails does not eat SeasideFramework alive, quite the contrary. Both are excellent frameworks, rails takes the traditional web architecture, makes it slick and integrated as hell, a joy to use in comparison to configuration heavy Java and .Net framworks, it is however, still the traditional request/response/stateless/html template/database web architecture.
      • Seaside however, is an entirely different beast. First of all, it only deals with the web side of the framework, persistence is entirely up to you, object databases are most common, because they pretty much rule the roost in the Smalltalk world. Keep in mind, you don't even need a database at all to build a Seaside application, because the Smalltalk image itself "is" a non transactional object database, so you prototype the entire application on live objects.
      • Seaside has no html templates, it's a control based framework where pages are, and are composed of live controls. Smalltalk's syntax is fully capable of expressing html directly, thus no templates, you write your html in Smalltalk, allowing you the full expressive power of the language without having to weave it into html.
      • There are no request response state issues, the entire request response cycle is hidden with the magic of continuations, your objects, pages, controls, all are written in standard OO style, as if you were writing a desktop application rather than a web application. Pages, which are just controls, can call and answer to each other and pass real objects back and forth between them, making Seaside far more capable of writing extremely complex applications than Rails with much less effort.
      • The simple example is a multi step check out process, a shopping cart for example, Seaside allows then entire process to be written as a single routine, rather than spread out across multiple pages passing state back and forth. That's the magic of WebTransactionsWithContinuations. Rails can't do this...

    • Um, yes, just as I said, SeasideFramework has the superior mechanism. Though check out markaby on the templating point. You've done a fine job summarizing SeasideFramework but you've failed to refute my assertion. SeasideFramework's mindshare, compared to Rails, is a couple orders of magnitude poorer. And the one and only reason for this is that it's written in ST.
      • No, I refuted the assertion that RubyOnRails eats SeasideFramework alive, clearly meaning it's a better framework, which it isn't.
      • You reserve the right to pull my comment out of context? Okay, then I suppose since our sentence includes the clause "RubyOnRails eats SeasideFramework alive", you agree with me. How incisive! You seem a most agreeable man.

      • RubyOnRails is more popular than SeasideFramework, sure, but if that's your point, then .Net and Java eat RubyOnRails alive. Mindshare means squat, if mindshare mattered, we wouldn't be talking about Ruby and Smalltalk, we'd be talking about .Net and Java, for they clearly dominate the industries mindshare.
        • Nice herring. But the world is not made of black and white. Since most of the java boffins seem to be hiving off to Ruby (per BruceEckel), we may anticipate the popularity stakes entering a state of flux. Or this may be merely wishful thinking. In any case popularity is a factor in language selection - or else I'd still be blissfully working away in PrologLanguage. The rise of the dynamic languages - led in .Net by IronPython and in Java by JayRuby, Groovie, and Jython, is an obvious and delightful trend. Why hasn't ST leveraged it? Answer: most STers have - and the majority of them are wangling RubyInsteadOfSmalltalk positions becaus Ruby is a living language and ST ain't.
          • Oh, and btw, could you do me a favour and rewrite this page in Latin? Or maybe LoglanLanguage is more to your taste. In any case, English, though popular, can't possibly be held up as technically superior ...

---

• Only one implementation (now JayRuby is coming along...)
  • How would this ever, in and of itself, be construed as a good thing?
    • One implementation means that every single library, tool and book you find is useful to you. You never have to face the risk that you'll choose the a particular implementation and end up on the wrong side of some internecine war between vendors.
      • There's hardly ever really only one implementation. Even when there's only a single project that provides implementations, they usually provide different versions for different platforms, and these tend to cause incompatibilities.
      • Also, having multiple implementations doesn't necessarily mean that _not_ every library, tool, and book is available to you. And even if it does, it doesn't follow that you're the worse for it - as long as enough of them are available for your chosen implementation.
      • The argument can even be turned around completely: it usually isn't until multiple implementations exist that languages become stable and standardized, and it's only then that you can fully trust a library, tool, or book to be useful to you.
      • To put it more succinctly: the availability of only a single implementation could be an indication that the great compatibility problems are yet to come.

• First-class continuations
  • Smalltalk has continuations also. And ST continuations are far more efficient - you can actually use them for real things.
  • This is regrettably only too true. Continuations are probably the worst implemented feature in standard Ruby. But with all the YARV/Zen/Rite optimization going on that won't be true for long.

• Imperative and functional programming styles are as natural as OO

• True lexical closures (depending on which Smalltalk you mean)
  • Most smalltalks do as well

• No commercial vendors. So the language's destiny is in the hands of its userbase and not some company's grand strategy.
  • Use Squeak Smalltalk
  • IsSqueakDead? Oh, wait, they're porting SeasideFramework soon ... maybe not quite dead ...
    • No, Squeak isn't dead, and no, they aren't porting SeasideFramework, Squeak is SeasideFramework's primary platform, and someone maintains a VisualWorks port. The Squeak community is highly active, and is the place where most cool stuff in Smalltalk is going on. Frameworks like SeaSide, Magritte, Pier, the new Traits implementation, many other things, Squeak is the place to be. Don't let its out of the box ugly UI scare you, it's very little effort to make it look quite professional, it is as far as I'm concerned, the best development environment I've ever seen, way better than Java, .Net, Ruby, Lisp, you name it.

• It's relatively new so it hasn't picked up an aura of infallibility which means it's still possible to get things changed in the syntax, semantics and libraries.
  • There seem to be some changes of that sort coming with Ruby 2.0

• Easy to use it as merely a superior shell scripting language. This gives people a low-risk way to learn it on small things before trying more ambitious projects.

• MixIns in RubyLanguage are very similar to what is proposed for SmallTalk in the TraitsPaper. Except they exist already.
  • Except they are different. Id est traits try to remove the warts of mixins by 1) prohibiting internal state variables, 2) in the case of multiple mixins, providing a syntax to allow programmer's to choose which method to mixin, etc...

• Maybe I haven't grasped Smalltalk yet, but I find that, because of its decent object browser, it seems not much documentation is done in Smalltalk classes except through code comments. I might be wrong about this. I know the best documentation should be the code, but for someone who is just starting out, step-by-step tutorials and summaries of each class really require the use of external documentation.
  • Oddly enough, this is what made Smalltalk so easy for me to learn when I was starting out and slowed me down in learning Ruby and Python. It's so easy to right click and browse a class, find implementers, find method calls, etc and see examples of how to actually use a class or API without having to go searching. That was my experience, at least!

• Plays nicely with C. It is trivial to interface Ruby to a C library, thus you can get all the benefits of all that CeeLanguage code out there. Plus there's ongoing work to implement a Ruby to C translator, so you should be able to write your entire app in Ruby, and then optimize the bottlenecks in C, which should make AlternateHardAndSoftLayers really easy to do. This means speed, flexibility and power, all at once.
  • I don't suppose ObjectiveCee is relevant on the pro-ST side here?
    • In the absence of an ObjectiveCee to SmalltalkLanguage bridge (which would admittedly be a cool thing), I'd suggest Objective-C is irrelevant here.

• Plays nicely with CeePlusPlus using the SimplifiedWrapperAndInterfaceGenerator to build the code needed. There is also RubyEmbed which enables a middle layer of Ruby to be contained within C++ and call back to the main program.

• There are RubyCoerce, DistributedRuby, EmbeddedRuby?, ModRuby?, FunctionalRuby and MonadsInRuby.

(See RubyIsSmalltalkMinusMinus for opposing viewpoints.)

---

FebruaryZeroSix

---

CategoryRuby CategoryDiscussion currently