[REBOL] Re: Cross-platform (was NTFS Stream Fun)
From: joel:neely:fedex at: 8-Aug-2002 11:33
Hi, Ashley,
My purpose was two-pronged, so let me separate the pointy parts...
;-)
[atruter--hih--com--au] wrote:
> While I agree with you at the academic / theoretical level, this
> just doesn't make commercial sense in many cases. Make no mistake,
> I am a *big* fan of cross-platform tools, but remember that these
> tools are designed to make things easier for the *developer* not
> the end user. One only needs look at the reception of Java by
> developers vs users to see that cross-platform is almost
> irrelevant to the end-user (Not trying to start a Java debate here
> folks ;) ).
>
I understand your point, but disagree with the conclusion in the
following way: there are differences in technical issues which only
developers may "understand", but which ultimately surface as visible
characteristics to the user.
For example, I recall a situation from my past in which an application
had been in use on a small, increasingly antiquated box until such
time that the increasing workload (and decreasing reliability) forced
the team to move the application to a new platform. As usual, the
term "forced" is appropriate, because the conversion wasn't done until
the situation had become a near-emergency.
The application had some characteristics/technology which were specific
to the old platform, and therefore extra time was required to convert
those aspects to the new environment.
The user wailed and moaned mightily at the fact that developer time
and effort was going into a system upgrade that offered no new,
desired features. (I started to say "squealed like a scalded pig",
but that didn't sound sufficiently respectful! ;-) The developers
felt it was important to minimize the number of "moving parts" and get
the previous functionality up and stable on the new platform before
making any changes to provide different functions that the previous
version.
My point is that we live in an increasingly networked computing world,
where scaling, access to resources, improving performance, deploying
with "thin clients", etc. are all significantly degraded when we allow
proprietary features to get in the way of ease of mobility of our code.
I certainly understand that (currently!) the majority of end-user desk
boxen are running some form of Windows, but even the option of moving
cycles back and forth between clients and servers is often a useful
tool in tuning system behavior, scaling (or degrading!) gracefully,
etc.
It is also the case that economic conditions, the commoditization of
computer hardware, and the rate of progress in computing technology
(Moore's Law is alive and well) all give weight to the idea that I
should be able to run today's code on tomorrow's box with as few
assumptions and constraints as possible.
Ironically, one can argue that the very success of Microsoft was due
to its determination to provide a uniform, consistent layer of
functionality that was independent of the underlying hardware. This
is consistent with the overall pattern of the development of the
computing field, where a melange of ad hoc hardware, O/Ss, assembly
languages, and custom variations of "standard" languages has slowly
given rise to a layered model in which variations at one level
(which may be perfectly legitimate *AT*THAT*LEVEL* for a variety of
reasons, including performance, cost, etc.) are hidden beneath an
abstracted interface that lets the next layer up deal with only the
concerns that are relevant at that next layer.
Because Microsoft made PC hardware a commodity and attempted to
establish Visual CP/M (called "Windows" in their literature ;-)
as the universal platform, the user could stop worrying about the
insides of his/her box (assuming there were enough memory, the hard
drive were big enough, etc...)
Along comes the 'Net. Now the next stage of evolution is to make
the details of the client-vs-server distinction, the operating
system, etc. irrelevant in the face of open protocols (TCP/IP, FTP,
HTTP, etc.) This is, of course, resisted mightily by monopolists
who are loathe to cede their place of privelege which they hope
would allow them to be the gatekeepers for all of computing.
I suggest that it is in our users' best interests for us to look out
for those interests even in areas where the user has no direct
expertise. That's how we add value, after all. I don't know enough
biochemistry to know precisely how the medicine operates in my body,
but I *DO* expect my doctor to know enough about it to prescribe the
best medication for me, to avoid simultaneously prescribing drugs
with harmful interactions, etc.
My other point is that using loss of platform-neutrality as argument
against open source is invalid IMHO, for two reasons:
1) The opportunities for breaking neutrality are already all around
us, and it is our professionalism/attitude/commitment that keeps
us from breaking neutrality, not the properties of our tools.
2) Availability of open source tends IMHO to make a tool available
on even *MORE* platforms, thereby further promoting widespread
use and enhancing the recognition that neutrality is in the best
interest of users and geeks alike.
> > The best way to avoid becoming Nazgul is to decline Sauron's
> > offer of a ring, no matter how shiny (and powerful) it may be.
>
> Yes, but Frodo had to "accept" it (and its corrupting effects) for
> the short term so as it could be destroyed in the long run. ;)
>
Yes, but it almost killed him in the process (and *DID* kill others).
The odds aren't good. ;-)
And, of course, there's the fact that they really didn't have the
option to "just say no" as do we.
-jn-
