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.
