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.
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.
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.