[REBOL] Re: Cross-platform
From: joel:neely:fedex at: 9-Aug-2002 10:09
Ed O'Connor wrote:
> Atruter said:
> "[cross-platform code] just doesn't make commercial
> sense in many cases... remember that these tools are
> designed to make things easier for the *developer* not
> the end user. "
> I have to agree with Ashley here, at least in the
> context of client apps. Commercial success in this
> space is a difficult balance of technology, marketing,
> service, support and usability. Oh, and luck.
I'd suggest the paraphrase:
... these tools are designed to make it easier for the
developer to give the end users what they need, and to
keep in working/growing with a minimum of effort.
> While I agree with Joel that a developer's burden
> often translate into user woes, that statement is hard
> for anyone to disagree with. Now cross-platform code
> doesn't exactly address that problem, right?
Sure it does, as illustrated by another anecdote from my
checkered past. Imagine a system where Box A is running
an information system directly supporting end users. Box A
gets a regular FTP feed from Box B to keep some critical
data up to date. (There was a relatively slow business
cycle involved, and some correlation with other stuff was
done on Box A, so there was no point in doing this via a
live, up-to-the-nanosecond database connection. In fact,
that would have been even more disastrous, as you'll see.)
The owners of Box B (in a different department) decided to
replace Box B (running Unix) with Box B' (running a well-known
proprietary O/S). However, they configured accounts and FTP
on Box B' using some proprietary nonsense that broke the
running FTP fetches on Box A, and broke it in a way that the
nature of the problem was not immediately obvious. Work was
required on both sides to diagnose and fix the pointless,
proprietary-environment-induced interruption of service.
There are any number of things that could have been done
differently by the owners of Boxen B and B' to have avoided
this waste, and essentially all of them involve either using
cross-platform tools or at least understanding and conforming
to platform-neutral standards.
> It's likely that Joel was referring to server-based apps.
Not really. The phrase "server-based" should be a deployment
strategy and performance tuning matter, rather than a basic
consideration. In an increasingly networked, object-oriented
world, we should be able to migrate objects, services, logic,
components, etc. as appropriately (even dynamically) to deal
with performance concerns, fault-tolerance/recovery, etc.
By artificially drawing a boundary between "client" and "server"
we introduce unnecessary distinctions. In addition, the view
of the "web services" world is that one physical system may be
a client in one transaction and a server in another transaction
where both transactions are parts of a larget application
process. Again, migration and portability end up providing a
degree of flexibility for configuration and resource allocation
that IMHO benefits everybody (whether they see it directly on
a daily basis or not).
(As usual, my opinions are my on, and do not reflect the position
of any other party -- including myself 24 hours later! ;-)