On ruby

Some of the perceived advantages over the java leading many folks to fall in love with the new
imperative-oo language on the block:

1. many problems can be solved with less code
2. dynamic typing allows greater individual productivity than static typing
3. easy relational database mapping
4. perception that "less configuration XML" is needed, because the system is configured in code, or something like that.

The first two are closely related and I've seen them in action.  Point taken.  We'll just note that there's
an upside to static typing for large projects.  Also, personally, I'm used to static typing, I think it provides good readability, and it doesn't bother me.  As it happens, I'm also not much bothered by the
other two "problems" ruby is solving, because I long ago moved from seeing my systems as piles
of java to seeing them as piles of declarative XML information describing an information space over
some stores (which might be SQL or RDF or whatever).    In such an environment, the advantages
are comparable to those of ruby; everything is taken care of by a magical environment. 

So, yeah, I get that part of ruby.  Magical environments are undoubtedly a good thing.  Prolog and
OWL are pretty magical, it turns out, and that's what I've been focused on lately in preparing the
Peruser 2.0, which is whatwe're leaving under the tree this year for the opensource Java/OWL
community.  I'm also pretty interested in how Obie Fernandez's ruby/OWL synthegration evolves.

The maturity, stability, and merchantability of the Java platform make me not want to abandon it
anytime soon.   Java packaging and jars work pretty darn well, and there are a lot of packages
and jars out there that can run on a lot of platforms.  It wasn't always like that, kids.
At the same time, I agree with the ruby crowd that there are better ways to
express software ideas than to hack java code in Eclipse.    I have never bought into java
code-generation, don't care for the huge oppressive IDEs, so there is no personal need to escape from
those.   I'm far less committed to SQL as a platform than most enterprise developers are,
so the "easy SQL mapping without XML" probably means a little less to me than it does
to a lot of other people.   I don't think the problem has ever been that database access is hard
in Java.  The issue is that configuring a large object-relational caching mechanism for efficiency
is hard no matter what OO technology you use, because OO is imperative and SQL is
declarative.    There's no isomorphism there.  DGMW, programmers definitely still need behavioral
programming languages, and OO-imperative is far from dead in importance, as is SQL.   So I'm glad
ruby+rails is awakening enthusiasm for building SQL backed systems quickly.

People like Ruby because it's dynamically typed like smalltalk, and it has some
nice conveniences for manipulating application types like lists and maps. 
Both of these choices save a lot of room in the source code.  And with a well crafted
VM that contains appealing default behaviors, dynamic typing can be a definite plus, as
long as everyone agrees on the appealing default behaviors across all situations.
That's where some discipline among the programmers is called for, and perhaps
this is why some debate occurs whether dynamically typed environments can be made
"large" in terms of  number of people participating in a project over a number of years.
(The "number of users" issue is an entirely different kind of "scaling", although one can
infer a relationship to the engineering scale).    I think the answer is, yes, they can,
given a lot of time and energy invested in documentation and standardization.  Sorry, boring
stuff, I know.  But the most important question for every project, as always, is:

What are we trying to achieve, and is this the right way to achieve it?

I think at this point it's important to recognize that there are at least 3 workflows in an a modern
web system:

1. Main workflow - end users
2. Librarian workflow - content developers and organizers
3. Engineer workflow - programmers and sysadmins

Now, consider this statement:
"The value I see in ruby is not as a replacement for java as a platform, but as a very promising
oo idiom for high level expressions of imperative behavior."   

Whether you agree or not, notice that this entire statement refers to activity in the #3 workflow
above.  See, it's great for people to try new programming idioms, but I feel like the real action is in
applying declarative semantics to allow the #2 workflow to better support the #1 workflow. 
That's where I've found a major expression gap since the web's beginning.    Diving into a
"quicker" programming idiom for #3 doesn't change anything about the way you represent the
#2 workflow, and if it takes you away from a proven approach to delivering a platform for that
#2 workflow, then maybe it's really slowing your organization project down overall.   This is why
I'm suspicious of the 4th advantage I cast so pejoratively above.

In reading the "what's ruby" page again, I'm struck by number three

• "Ruby's operators are syntax sugar for the methods. You can redefine them easily."

OK, never mind that this gives me cold sweats remembering C++ and perl readability
fiascos of the early 90s.  The important thing to note is that this embed a nonstandard
little-language with ease feature is an attempt to support more of #2 workflow within the #3
workflow.  Unfortunately, I think that's the wrong direction to be running in, architecturally,
if you want to bring lots of people into a well defined process.   If the latter is your aim, you
need to be focusing on declarative XML artifacts that can be exchanged by tools regardless
of the programming language they use.  If you do that, you'll find that you don't need that
much java or ruby.  What you do need is domain-specific declarative artifacts, managed by
appropriate tools, supported by a bare minimum of standards-oriented server side imperative
object oriented code.    No code generation, no embedded little languages, no code annotations
are necessary or really desirable.

Reading the rails blog what becomes clear to me is that Ruby on Rails can and should replace
both php and javascript (not J2EE + XML).  If all the PHP and javascript experts start working
in Rails instead, that's just gravy.  Then we can talk about unifying Java and Ruby via XML,
and the world can live happily ever after.

I always liked python, and I once loved perl.  I was engaged to Objective-C, which ruby emulates
with modules.  Gotta love that.    So, I guess, ruby is just alright with me, as long as people
don't forget my bride, the luscious XML, and our kids RDF and OWL, who are both above average.