For myself, I don't see this as a "vs" as much as an "also".
When I need to put an app inside of a browser window, I use whatever the
project requires to do that, and old-school tech like AJAX often gets
the job done well.
But for everything that lives outside of a browser window, for me it's
all Rev, all the time.
As for the "sole source" question, in practical terms I wonder if
language choice is really so big a factor.
Replacing a critical team member is always expensive to any substantial
project, regardless of the language it's written in. Code is
disposable, replaceable, and much of it probably should be every few
major versions. But knowledge and rapport -- that's where the
investment is, and that's always going to be expensive to replace.
In this industry it's really easy to fall into a gadget-centric view,
focusing on compilers, languages, tools, and such. But in the big
picture, maybe the computer industry isn't that much different from any
other. The business of business is driven by human creativity.
If one's code is well structured and well factored, the underlying logic
can almost always be ported to another language profitably. Ask Chipp
about the BASIC project he recently rewrote in Rev -- as I understand it
they saved quite a bit making that upgrade, even though it meant also
rewriting the app from the ground up.
For going the other way, Transcript is readable enough to almost any
programmer. And with Rev's growing base, there are plenty of
consultants available who can help orient a rewrite team if needed.
So with all that in mind, maybe the real business question here is: Is
it worth ditching immediate ROI benefits for the possibility of maybe
saving some time at a potential future date if a worst-case scenario
happens?
All business decisions carry risk. I'm not sure how many successful
businesses got where they are by raising current costs in an attempt to
approach zero risk for the smaller expenses associated with possible
future misfortune.
Or to look at it another way:
If the client's goal is to migrate to commodity languages to use
commodity labor, why wait until the programmer's dead? If the work is
the sort that can be commoditized, the client could do well to avoid
paying US costs altogether and hire someone overseas today.
The languages we bring to the table can always be replaced. But can our
experience/talents/creativity?
That's only true if all we bring to the table is merely functional code
that does only what was asked for.
Clement Mok doesn't sell pixels, nor Frank Gehry ink. :)
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
