If We Can’t Push Smalltalk, Let’s Fix Ruby


Functional programming is an entirely different kettle of fish. It’s meant for those situations where you know (and by extension NEED to know) everything about the code you’re calling. Ruby, used properly, is like Smalltalk in that the most immediate answer to “how does that work” for a newbie should be “who cares/”. ‘Morphable’ classes (NOT mutable objects) is a means by which a language can become incredibly powerful via topology.

Functional programming, like most functional programmers, wiill never grasp the real power of topological design. Each has its place (iinterestingly that each HAS its place its itself something that a topological language can embody, but a functional language cannot) and I’m not getting into a Haskell vs Ruby debate, because it’s not much different than a Python vs Macro Assembler debate, albeit in a different sense. Ruby has the potential to be far more productive. Haskell has the potential to be far more precise, in the sense that the programmer knows precisely what the program is doing, Smalltalk or Ruby are more productive, since you most often don’t need to know precisely what it’s doing. Sometimes you need that precision, no question, but largely in general purpose apps the problem is not precision but productivity, whcih boils down to power vs effort.

Ruby’s not yet Smalltalk,  partly because the early versions misunderstood the point of strong object typing (let’s go beyond impilcit typing and make it more dynamic!). The point isn’t that programmers will stomp over a variable, they can do that anyway, albeit merely locally, and a developer at that tentative level of experience is going to make far worse mistakes until their experience teaches them to do otherwise.

The point is that strong typing allows for tooling that by and large a language developer (or a Haskell developer for that matter) would find irrelevant. But it’s those tools that allow reliable general purpose “Fortune 500 Million” software to be written efficiently (from the perspective of developer hours per feaure point). Ruby is nearly there and I expect if 3.0 goes the way predicted you will see a profusion of tools with capabiilities that can barely be acconplished in a language like Java without the complexity of OSG (and resulting phenomenal heft of Eclipse with the plugins you need for a given project) and even then it’s dicey, while they’re not conceivable at all in Haskell or LISP.

f this seems irrelevant to Ruby developers, consider that a number of top people on the Rails team abandoned Ruby altogether, preferring to go back to the “obscure niche” of Smalltalk since the tooling was simply that much better.

Do yourself a favour:

  • go to pharo.org, download the “one click image” and just look at the tooling for class/method browsing, refactoring, code critics, etc.
  • compare the actual code of a given method that does something similar to any given Haskell or Ruby code.
  • to make it even easier, go to pharobyexample.org and grab the PDF tutorial so that you don’t have to mess around figuring out where stuff is in the Smalltalk environment

At most it should take a Ruby developer 30 minutes to download, install the softwaer and complete the comparison.  It might take a little longer for someone only familiar with C or Java or Haskell, simply because the syntax won’t be as familiar.

The first reaction is usually “but it’s not DOING anything!”. Yet it IS doing all it needs to to accompilsh the functional task.

For kicks, take a look at the Smalltalk Image (VM) in whatever sysmon you have and compare resource usage to far less capable toolkits in other languages (Netbeans, although it’s a nice enough IDE to use as simple Java IDEs go, is really little more than a glorified text editor and project organizer with the addition of “hint” technologies for supported languages, and as such is a great example).  How is this discrepancy possible?  Largely it has to do with the massive use of frameworks in Java (and other similar languages, and Ruby’s getting that way itself).  More on the implications of frameworks and why they’re necessary to a language like C++ or Java but not to nearly the same degree in a language like Smalltalk later.  A second reason is a more involved one.  Most languages such as Java are written largely in another language, such as C.  This seems perfectely natural and at least for the loader that configures the initial VM/interpreter, necessary.  Yet higher level structures such as frameworks are almost inevitably going to be more efficient from a Java perspective if written in Java, but by and large they aren’t.  Most Smalltalks on the other hand, use a small bootloader that may be assembler, C, or in the case of Amber even JavaScript.  However, after that initial basic Smalltalk compiler/interpreter is booted, the rest of the language itself is written in Smalltalk.  The full implications of this as far as the power of the language is a more advanced topic, but the basic efficiency of the VM is almost inevitably improved.  There are exceptions where OS/machine native code is advantageous, graphics is one obvious such area, hence the existence of things like native boost in Smalltalk, often used precisely to get better graphical performance.  But things like colletions, ORMs and other language constructs are generally more efficient when written with the same notions as the langauge that is going to access and use them.

So where are we?

Smalltalk is niche, Haskell is niche, LISP is niche, Ruby is niche, though that niche is a little bigger, But niches doesn’t nessarily equate:

Haskell’s niche is, fundamentally, scientific software )the physiciist who invented it is someone I happen to know, through weird family connections, he’s my ex’s brother in law).  It can of course be used for other areas of development, but in most cases in doing so the specific advantages of the language disappear.
LISP is very niche, most often used where recursive, reflexive programming is ideal deespite its lack of intuitive ease as far as learning it goes.
Ruby’s niche is by and large relatively simple webapps that are not limited to CRUD, but don’t often go much fuirther, maybe a few calculations and aggregations but that’s about the limit and don’t have to deal with too many complication such as 45 year old legacy databases that just HAVE to be used as the base rather than a simple import source, or being too concerned that, at leaast if used with MySQL, Rake doesn’t put in any constraints or keys, so your DB is really a set of spreadsheets linked in code. (Granted, it’s been a year or more since I treid them together so that might have been fixed. It was easier for me to simply use PostgreSQL and not worry about any funkiness unique to Rake + MySQL.)

But what’s Smalltalk’s niche? It’s a general purpose language which can be used for most programming tasks even in the open source variants such as Squeak and Pharo that have had relatively little development effort,put into them compared with other languages.  the people who work on them do plenty, and do it very well, but there simply aren’t very many of them.) There are of course commercial dialects such as Cincom VisualWorks and VisualAge that have had more development over their lifetimes, since they predate the open source dialects signficantly, but at least in the latter case the costs involved tend to weigh against it unless you’re already certain it’s what you need, and that’s never going to increase adoption.

If you look at where Smalltalk is used, and in the corporate world this largely means the commercial dialects, it includes areas such as high precision fab control software, high speed production automation, control systems in complex machinery such as aircraft, naval vessels, etc.

This “niche” is a in itself a very odd niche. It might be summed up as whereever it HAS to work, every time, but we don’t have the time to carefully code it all in assembler/ Yet how many non-niche projects are precisely in need of that, given the failure rate not merely of projects but of real-world software in the field?

Ruby has the chance to be the Smalltalk that Smalltalk should have been, but circumstances prevented it being. Unfortunately, that window closes further every day.

Strict typing (it can remain implicit – if you really need to declare a variable type other than by it’s assingment you might be a little simple minded to be a developer anyway, perhaps project management would be a more sutable career choice, that allows for the kind of tooling the majority of developers need, and the ability to take a simple, Fortune 500 million type program, and if it becomes necessary scale it to that degree without throwing what works away, would be a huge boon in an industry where the failure rate is too high, and gets rapidly higher the more complext the software. The ability to shape change classes that already exist as well as those written atter the class that accomplishes such is something that is completely other than the precision of a Haskell or the recursivity of LISP, and results in huge productivity gains (Smalltalk was estimated at 34x the productivity per developer of assembler, compared to 1.2x for Javascript, 11x for Java, and 14x for Ruby.

Ruby has nearly all the attributes to achieve an equivalent productivity, let’s doi it rather than succumb to confusion by conflating structures in languages that are not Smalltalk-like, and no matter how useful those structures, all you can really wind up with is something like Python where the object features prevent much useful recursivity and the recursive features undermine the object sructure..  It’s lacking a proper ORM that goes beyond what can be done with Active Record, but one that doesn’t make the simple use of Active Record unnecessarily more complex.  The additon of the Active Record concept to the much more comprehensive Glorp ORM is a great example of how to do precisely that.  It needs the idea of a development “image” or VM that can then be statically analyzed, cerating a runtime VM for a specific app that has nothing not actually needed by the program.  The JRE is huge, and if you count all the native libs Ruby requires its VM is not much less so.  The Smalltalk development versus runtime image is a far more versatile and efficient idea.  The last thing that immediately comes to mind is a Monticello/Metacello repository system to replace the complex and disaparate repos that currently include git, github, svn, gem, etc.  The implementation of Monticello ON git is a great demonstration of how to use a basic tool like git to do much more useful and advanced things, such as versioning methods as well as classes.

What this could accomplish:

Smalltalk is not and was NEVER “object-oriented”, it is “entelechia-oriented”, or to put it in more vernacular, system-oriented. The original Greek for system had three meanings:

1. a random arrangement, i.e. random actuality or energeia in Aristotle’s definition
2. entelechia, which has a fundamental internal jointure or structure that makes it one thing as systemic
3. what lies between the two – in German “Gestell”, since no Greek word really corresponds to it, in English – “Enframing” or, less accurately but mroe comprehensibly, “framework”.

The proliferation of frameworks in languages like Java and to a lesser degree Ruby imply it hasn’t achieved full systems-orientation (Java never will, since even with the addition of complex frameworks such as OSGi you simply can’t assume anything about another Java “thing”. Since systems aret we are trying to build, it makes good sense that the notion be embedded in the language itself. There are other languages with this notion, it’s not confined to Ruby and Smalltalk, such as Self, but Ruby ahs the best chance of, perhaps still remaining niche (at least compared to the behemoth of Java, in which more code has been written than all other programming languages combined, and yes that includes “C”), but it could be a much more significant niche, and one that provides more signficant advantages for those with the nerve (or polyglot ability, either one 🙂 ) to not choose the path of absolute least resisteance. We all have limits to our resistance, the biggest being “am I going to actually get paid for this?” But if we can answer that in the affirmative more minor resistances become easier to overcome, especially if they buy us more.

Apologies for the length of this ranting and rambling, but productivity isn’t simply a matter of efficiency, cost or money for me, ti’s a matter of enjoying what I do. I simply don’t enjoy reinventing the wheel every time I sit down to code, and I especially don’t enjoy not having the time built into the project to make anything better than an oblong wheel.

And if anyone who thinks JavaScript, Node, Backbone and Kraken are the greatest thing since sliced bread (oh, am I referring to the so-caled “architects” at Paypal/? Of course not, I wouldn’t be that nasty or crass, how could you think such a thing?), and you managed to read this far, forget that you bothered. If you think a language with no decent tools, horrible syntax, no decent debuggers after 20 years and only passable development environments, nearly all of which work better with other languages, is “great”, you might just as well go back to 3270 assembler on the mainframe in an case.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s