Scripting, scripting, scripting. Programmers love imperative scripting, because it
works for what they want to do, when they want to do it. Jah bless em. I script
all the time. Jah bless me.
Question: Is the Ruby-on-Rails + AJAX community committed to XML interoperability?
OK, so I believe that RoR beats PHP and JSP+EJB and perl for hand-scripting SQL webapp workflows.
But is there a stronger statement out there that the dynamically typed imperative program removes
the need for robust server VMs with package management and XML interop and WebServices and
ontologies? How does RoR fit into the space of declarative workflows? I'm a little shrill about
this because I see people running off to spend time, attention, money on this allegedly "fast and cheap"
approach when they might instead be learning higher order methods and facing the crunchy process
issues that confront their organizations (which is of course what makes ME necessary! See how my
mind works?).
I enjoyed Tim Bray's "shiny red rock" article on Ruby.
I agree with Stefan's assertion that RoR does not appear to solve the problems addressed by cocoon,
but then I haven't actually tried RoR so maybe I should shut my yap.
I like Stefan's new(ish) PiggyBank thing at SIMILE, too, though the javascript screenscraper paradigm
is not quite my cup of tea, at least so far. I did try it out on a non-critical machine and it kinda worked
for me, but I think my firefox is a little old on that machine. I'll probably upgrade and try again
sometime.
Back to RoR. What I'm concerned about is that content and author workflows are mixed, recapturing
process as well as technical ground for the programmers. Now, it's quite true that if the development team
builds a GUI content management application into the application (and manages to keep
it
up to date as the application schema changes), then perhaps the
workflow mixing can be eliminated,
at the cost of broadened engineering cost and
risk. But my experience is that in today's "agile"
organizations, these authoring needs usually get more lip service than budget.
And when the authoring/engineering distinction for dynamic content is
not properly recognized, then the workflows
are almost sure to be mixed, i.e.,
Programmers Own The System!
So, the money question here comes down to: What kind of workforce and workflow do you want in your
organization? If you want all dynamic content authoring to flow through your software programmers
who know what block closures are, then it does not seem reasonable to expect
the artifacts they produce to become integrated institutional knowledge for your organization. Instead,
the knowledge of how your systems behaves will be shared only among the programmers and
recorded definitively only as imperative machine instructions, as has historically has been true in
most organizations, but to a decreasing extent over the years as attempts to broaden the
set of people who can participate in the workflow (i.e. knowledge workers) have progressed.
I guess the mitigator I've been ignoring so far is the role of the SQL database in an RoR application.
The SQL artifacts seem destined to hold some value and provide for some authorability, although
there are many issues with the relationship between relational and imperative models that simply
cannot be addressed by shifting imperative programming idioms. That's what I've been saying
for quite some years now, but I guess I'm not very convincing ;-) The upshot being, your SQL
information model will almost inevitably become entwined with the scripted-object idioms in the
imperative code in a non-sharable way, leaving your app's concepts semantically isolated from other
applications in your enterprise. Sound familiar? The escape hatch is declarative ontology
based information dictionaries driving all other workflows with run time information processed
through standards-based logical message interpreters grounded in standards-defined
primitives (which are not the same thing as object-message dispatchers). I'm not talking MDA,
I'm talking MEA: model execution architecture, here "model" means a modal logic
model embedded in an ontology/frame model, not UML. Something not unlike this, when
seen through a microscope.
To build that world, we still need some imperative code, but not much. So to me, the discussion
about "best" imperative languages is kind of like asking which kind of pencils write the
best movie scripts. For the interoperable OO code we do need to build, and to fit with what's
already built, I still feel that the benefits of java strong
typing outweigh the disadvantages, though syntactic improvements are welcome. There's a
reason we type objects, and it's not for the convenience of
individual programmers. Unfortunately, I agree with Cedric and others that the Java 5 generics
syntax is unusably cumbersome for non-generated code (and I hate generating code). Not sure
about the C# style type inference he describes, though it looks promising.
Bottom line: Running to Ruby-on-Rails to get away from strong typing may be a risky move for
knowledge-centric organizations seeking to innovate across the enterprise. But it is a great way
to move beyond PHP or Perl scripted SQL websites in terms of programmer productivity, and can
be even more than that if your organization is committed to a strong ongoing programmer participation
in knowledge management workflows.
If there is a thesis about some kind of new knowledge workflow paradigm enabled by continuations-
based application definition (which would seem to be the newest element of RoR vs. established
web platforms), I guess I'd like to read about that. Until I see something compelling in this area,
I'm sticking to my wait and see attitude towards Rails. Ruby itself as a scripting language via JRuby
is fine, but I'm much more interested in logic languages like prova and flora. Anybody else dustin
those acres lately? I'm all hot and bothered about Fresenel Selector Language for RDF, too. Woo!
Comments