Ruby Slippers

The New York Times cited Terra Nova this past week.  They highlighted Dan's tongue-in-cheek poke - the 2006 in Review.  Yes, the internet is a murky place.  Don't understand the problem, surely you must get the solution?  Don't grasp the solution, just worry about the community, right?

Admittedly I've been sceptical of e-crowds of late [1.].  After all, who cares if the Mechanical Turk could be used as "a community substitute:"  if you can't aggregate enough wise friends to your site, just hire them  (see also [2.]). 

My grumble could end here were it not for another internet-driven excitement that is bothering me: Ruby On Rails (RoR, Fn1).  Sounds arcane.  Consider it as a metaphor for Web 2.0 and its symbiosis of people and technology, and I will explain my squeak. 

There is a programming language called Ruby.  It exemplifies (IMO) much of what is right about a programming language:  unpretentious, succinct, and above all, flexible.   Much like community it too embraces an openness in ideas and membership that serves it well.  In any case, who can argue with its increasing favor.

Now, somewhere along the way bright folks got this idea of bundling Ruby with a number of other components - a webserver and database, say - in a way that made it much easier to use in applications that seemed suited to the language and how folks were using it.  RoR was born and its attention was geared to those interested in rapidly creating interactive websites, that sort of thing.

When it comes to RoR, it is hard to quibble with the practicality of packaging Ruby with its commonly associated components.   What is not to like with Domain Specific Languages and Model-View-Controller (Fn2)?   Especially in this day and age, software development should be moving towards conceptualizing solutions in terms of a full-stack framework.  Future productivity demands it.

Yet after casually deconstructing Instant Rails one weekend I was struck by how deeply ingrained in the RoR view of the world the database and the limitations of object-relational mapping [3] played.  This leads to this question.  Given an efficient technical paradigm, for better or for worse does that paradigm eventually finds its reflection in the application to the exclusion of alternative solutions?

Or to state it with more subtlety.  If the advantage of an RoR type solution is that (using the lingo) it pushes the complexity of software to the edge cases (in other words, it is really easy to do the usual stuff and really hard to do the unusual stuff), then at what point need one worry about what they are missing by clipping the edges?

I suspect a similar issue with many virtual world implementations.  For example, by relying upon the database for all the persistence and transactional heavy-lifting, the game/world becomes shaped to its way of thinking.  How many times have you played an online game and thought - the reason why they structured an interaction or an object design in such a way was because it was easier to map into the server scripting and ultimately the database?

Think about those edges you are missing.  I'll think about the ruby slippers I wish I had.

---------------------------------------

[1.]  "Where's the catch."   (TN) On "Henry Jenkin.  Collective Intelligence vs. The Wisdom of Crowds. "

[2.]  "Games with a purpose." (TN) On Luis von Ahn, social algorithms.

[3.]  "Guess my game."  (TN)  On the "Vietnam of Computer Science" and the "Grammar of Gameplay."

Fn1.  Also rubyonrails.org.

Fn2. See also "A Java Parable" and "Tooling around" (TN).

Comments

[Matt Mihaly]

1.

Nate wrote:

For example, by relying upon the database for all the persistence and transactional heavy-lifting, the game/world becomes shaped to its way of thinking. How many times have you played an online game and thought - the reason why they structured an interaction or an object design in such a way was because it was easier to map into the server scripting and ultimately the database?

I can't follow some of the technical bits of what you wrote, but you seem to be asking if people have noticed that once an idea is mapped onto an actual, functioning system, the experience has to be limited by the constraints of the system.

Isn't this the case for every conceivable system, up to and including the system of reality? (Which has thus far failed to produce a dragon for me to fly around on, I can't help but notice.)

--matt

[Mike Rozak]

2.

It's a fundamental problem of all development platforms; a given platform will make some things easier to impliment, and others more difficult. Some platforms make some things REALLY easy to impliment, at the cost of others being REALLY difficult.

Thus, NWN2 and Oblivion make it really easy to create a virtual worlds, but all worlds created with the two toolkits will be essentially the same.

At the other extreme, C++ makes it difficult to impliment virtual worlds (as well as all other games), but also means that virtual worlds implimented with C++ can be radically different.

Database dependence is similar; When I play CRPGs (and MMORPGs), I feel like I'm wandering around a database, where objects differ by numbers. When I play text IF (or something like MUD I/II) I'm wandering around a program, where objects differ by code.

On a related note, worlds that have objects as fundamental units are different than those with verbs as fundamental units, which are different to those with plots/storylines as fundamental units.

[Cael]

3.

RoR is almost entirely a subjective experience depending on what exactly you want to build. If you want something that's easy to do in RoR then you really should use it but be aware that it will essentially be replicating a subset of features from [n]-billion other websites. That's fine if that's what you need.

What worries me is that Multiverse, BigWorld and other such platforms will do exactly the same and thereby fracture the MMO player-base without ever actually innovating.

[Tateru Nino]

4.

Every system provides constraints. It can be on what is possible within the system, the energy/resources available the system, what is hard/easy within the system, what is advisable within the system, or how we think about the system.

In practice, all of these, precise definitions mapped into the domain of your system.

"When all you have is a hammer, everything looks like a nail."

A new system only appears to be liberating when you wish to act beyond the boundaries of your existing system (whether that system is a virtual world, a programming language, a bounded environmental system, or a communications abstraction).

Knuth (I believe, correct me if I'm wrong) put forth that all second-generation languages were of equivalent power - but of course they are not of equal facility.

Ask any programmer with solid record of use of multiple languages, and - given a little thought - I think they'll agree that working with one over another places boundaries and constraints on design and implementation.

But, hey, what do I know?

[Cael]

5.

I disagree about placing constraints. More about imposing ways of working and those can tend to lead to imposition of ways of thinking.

When you learn another language (human or machine) you learn another way to think.

[Kami Harbinger]

6.

It's the Sapir-Whorf Hypothesis, applied to computer programming. The language you program in, and the platform you program for, determine the types of applications you will produce, not just in user interface, but in fundamental capabilities. While it's possible to fight against the limitations of your system, it's extremely difficult and usually fails.

Text games and VWs were initially limited by slow dialup bandwidth and limited clients. Even today most work fine on teletypes, not even using the capabilities of teletypes. Why? Because the original environments were all text, command-line systems. The VERB [OPTION...] NOUN command structure is a heck of a lot like any command-line OS shell. The implementation followed the platform's idiom. The curses library was taken from vi, then used to implement Rogue, so Rogue inherited vi's movement keys and user interface. The data structures for most of these worlds were just serialized C structs, so it was difficult to build long-lived interactive worlds.

Ruby itself is a mediocre Perl upgrade; it's certainly better for OOP than Perl, but has the same amount of line-noise syntax, and still has no serious Unicode support. RoR does a great job of scraping a database and providing CGI access to it. It's not fundamentally different than using Perl, though, and leads to the same kind of sites. I look at every RoR site I've ever seen and see Slashdot again.

MMORPGs vary. Meridian59's capabilities were directly determined by what raycasting engines could do; it always felt like a graphics engine with a world tacked on. EverQuest was very clearly DikuMUD, with the serial numbers filed off and a vastly better client. Most later MMORPGs do a varyingly job of hiding the underlying database, but it is obvious to any enterprise developer why some of the limitations exist.

Second Life's strengths and weaknesses are almost entirely a result of Philip Rosedale's background at Real writing streaming media code. Every facet of SL is touched by its origin as a streaming media app.

And within SL, the Linden Scripting Language directly determines the kinds of things you can build. Yesterday I wrote a train controller for a customer in 2 hours, and took another couple of hours to smooth out the ride. The workarounds for dealing with LSL's limitations, and the limitations of the physics engine, and the lag in interacting with distant objects, all influenced my design choices, or cut off useful possibilities. And yet, there's no other language or system that even comes close to LSL's ease of control over 3D multi-user VW objects; I'd be days or weeks doing that in anything else.

[Kami Harbinger]

7.

not even using the capabilities of teletypes

Sigh. Not even using the capabilities of VT-100/ANSI terminals.

[nate_combs]

8.

Related.

From David Brin (Salon) - "Why Johnny can't code" - BASIC used to be on every computer a child touched -- but today there's no easy way for kids to get hooked on programming.

Knowing the 'edges' is as important as knowing the mainstream design pattern?

Oh, today's desktops and laptops offer plenty of other fancy things -- a dizzying array of sophisticated services that grow more dazzling by the week...

Only there's a rub. Most of these later innovations were brought to us by programmers who first honed their abilities with line-programming languages like BASIC. Yes, they mostly use higher level languages now, stacking and organizing object-oriented services, or using other hifalutin processes that come prepackaged and ready to use, the way an artist uses pre-packaged paints. (Very few painters still grind their own pigments. Should they?)

And yet the thought processes that today's best programmers learned at the line-coding level still serve these designers well.

I'm not sure about Basic - no dis from here, however. That was *my* first programming language.

[greglas]

9.

Nate -- *this morning* I was just complaining to some friends about the absence of something like BASIC in most PCs -- hadn't seen the Salon piece.

The funny thing is that I was thinking "well, they've got all sorts of wacky Java puzzles that provide the same rush of complexity and interactivity that I got from tooling around in BASIC." But... it's not the same is it?

Maybe that's a partial answer to your Ruby questions -- yes, the interface matters one whole heck of a lot. The smooth, appealing, simple design (say WoW if you need to tie to VWs) is a design on rails. There are reasons to love it, but at some level, we'd really rather go offroad.

[greglas]

10.

Correction: re Java puzzles, I was being too specific about my kids -- what I meant to say is that Johnny is generally lost in various GUIs these days, not really building the virtual machine.

[greglas]

11.

Brin's article is dead on. Take that Steve Johnson. :-)

[nate combs]

12.

greg>
The funny thing is that I was thinking "well, they've got all sorts of wacky Java puzzles that provide the same rush of complexity and interactivity that I got from tooling around in BASIC." But... it's not the same is it?
-----------------------------

I don't think so, for reason of the final argument that Brin provides:

For all of their high-flown education initiatives (like the "$100 laptop"), they seem bent on providing information consumption devices, not tools that teach creative thinking and technological mastery.

Web access for the poor would be great. But machines that kids out there can understand and program themselves? To those who shape our technical world, the notion remains not just inaccessible, but strangely inconceivable.

Now, substitute "information consumption devices" with "entertainment consumption devices" and I think we're getting close to what games and virtual worlds have become.

[greglas]

13.

The interesting thing is that you, I, and Brin would all seem to agree that *if* there were something out there with all the flexible features of a BASIC -- in games or otherwise -- we would pay for it happily.

So, the problem isn't with our stars, it's with ourselves. It's difficult to build and fund the kind of tool that educates and entertains. Paradoxically, it is harder to do now than it was when the technology was at an earlier stage. But... if a good tool like that could be built, it would be successful in the marketplace (unless you, I, and Brin are not representative of some market segment).

[lewy]

14.

Kami Harbinger wrote:

"Ruby itself is a mediocre Perl upgrade; it's certainly better for OOP than Perl, but has the same amount of line-noise syntax, and still has no serious Unicode support. RoR does a great job of scraping a database and providing CGI access to it. It's not fundamentally different than using Perl, though, and leads to the same kind of sites. I look at every RoR site I've ever seen and see Slashdot again."

Hmm? One of the things Ruby proponents tout about it is the language's compactness. Here's an example from a Bruce Tate article for outputting a Fibonacci sequence at http://www.onjava.com/pub/a/onjava/2005/10/19/challenging-java-dominance.html:

x1, x2 = 0, 1
10.times do
puts x2
x1, x2 = x2, x1+x2
end

To me that code looks clean and concise. The languge looks like it makes it easy to write code that's clean and concise. And you sure as hell can't do something like "10.times" in Perl.

So far as web sites goes, I'm really not sure how the server framework is going to determine the look and feel of web pages. Surely any aesthetic shortcomings are the web monkey's fault? Anyhow, from what I remember hearing the guys who do the Prototype and Scriptaculous stuff are Rails committers now.

[nate combs]

15.

lewy>
So far as web sites goes, I'm really not sure how the server framework is going to determine the look and feel of web pages. Surely any aesthetic shortcomings are the web monkey's fault?
------------------------------

If you can get past the heavy-handed use of the Indochina analogy - Ted Neward has a good intro to the Object/Relational mapping problem. Just one example, though I think it has a pervasive impact in coloring how people interact with MMOs.

Read the section on "The Object-Relational Impedence Mismatch" and think about how "objects" in your favorite MMOGs are portrayed to you. One simple net effect, i believe, are flattened object models: weak on use of inheritance and polymorphism resulting in lots of containers and many types.

[nate combs]

16.

link (also in footnotes above):

The Vietnam of Computer Science.

[Kami Harbinger]

17.

While the style sheets change, the page flow and how you manipulate "objects"/database rows in RoR sites are always the same, and fairly limited. The fibonacci example isn't representative of significant Ruby code, and RoR code in particular is pretty close to nightmare fuel. Ruby fanboys like Tate go out of their way to show the most trivial cases in public, but what they actually write is far less pleasant.

As for a novice language to replace BASIC, Python is easy to learn, has turtle graphics, and has a good variety of books. Alice lets you build 3D graphics in Python with very little effort. Unlike BASIC, you don't have to discard Python when you grow up.

PHP is ugly and horrible... But PHP 5.0+ is an adequate language, it's installed everywhere, and it's trivial to make a web application in it, which most young people find much more understandable than desktop or (Cthulhu forbid) command-line apps.

[lewy]

18.

In response to both Nate and Kami:

The Vietnam metaphor was a little heavy handed, but the article was definitely written by someone who is intimitely familiar with the problems associated with driving a square peg into a round hole. My response was more geared to the "All RoR sites look like Slashdot" comment. If you want to criticize ActiveRecord, be my guest. I'm certainly not a huge fan. That said my limited exposure to Rails doesn't lead me to the conclusion that ActiveRecord is any more crippled than any other ORM, which makes me question just how different any other framework could be when it comes to the basics of retrieving from and inserting information into the backend database. A database is a database and I don't see why the fundamental constraints should change based simply on the framework.

As for PHP, the less said about it the better.

[Smials]

19.

Just in case anyone's interested: BASIC is alive and well. Several commercial variants, geared at making games and graphic applications, are quite popular among the indy and retro crowd:
www.blitzbasic.com
www.darkbasic.com
to name a couple. There are also free variants, like GNU's FreeBASIC.

Sure it ain't Python/Ruby/Smalltalk, but the above environments are easy to get into and provide a low barrier to entry.