Cross-platform
[1/4] from: rebologue:yaho:o at: 8-Aug-2002 17:36
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.
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?
It's likely that Joel was referring to server-based
apps. The cross-platform feature is much more
prominent issue there. To please the market for
server-based apps and CGI, a product usually needs:
* reliability
* speed
* scalability
* acceptable security
* cross-platform support
* support for standard integration interfaces
(protocols, security, etc.)
With client apps, the list of priorities is much
different:
* familiarity (native look & feel)
* responsiveness (speed)
* functionality (features)
* usability
* interoperability (integrates with platform and plays
well with other apps)
On Windows, a technology that fails to address each of
these points might be better off as shareware or open
source. An exception to this rule could be made for
killer-apps such Netscape or Napster (and were boosted
by the fact that they were also free).
>From a business and user perspective, many proprietary
platform features add value. Such as the ability to
display a spreadsheet inside a word-processing
document, or drag a file icon from the desktop into
another app. The evil side of that is lock-in, but
that's a fundamental business reality and hollerin'
won't make it any less so.
So what now? Give developers the tools that give users
the no-compromise client-experience they expect. At
the same time, eliminate the developer headaches and
bloat required by other tools to achieve that same
high-quality experience. Offer me that and you've got
something **most** developers would willing to pay
serious money for. No other company has really
delivered on this yet, which is why it remains an
opportunity.
Hey, I've got the perfect product to sell in the US,
but it requires Americans to switch to the metric
system, lose weight and drive electric cars... I'm
betting this will be the next big thing... ;^)
// Ed
[2/4] from: gscottjones::mchsi::com at: 9-Aug-2002 6:44
From: "Ed O'Connor"
<snip>
> Hey, I've got the perfect product to sell in the US,
> but it requires Americans to switch to the metric
> system, lose weight and drive electric cars... I'm
> betting this will be the next big thing... ;^)
LOL. It is good to be able to laugh at ourselves sometimes. Thanks for the
morning chuckle.
--Scott Jones
[3/4] from: joel:neely:fedex at: 9-Aug-2002 10:09
Hi, Ed,
Ed O'Connor wrote:
> Atruter said:
> "[cross-platform code] just doesn't make commercial
<<quoted lines omitted: 5>>
> 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).
-jn-
(As usual, my opinions are my on, and do not reflect the position
of any other party -- including myself 24 hours later! ;-)
[4/4] from: rebologue:yah:oo at: 9-Aug-2002 9:55
Hi Joel--
Cross-platform code aids developers in cases where the
required solution is to port code to a new platform.
Not a real boon the rest of the time, other than the
comfort of knowing that you've got easy migration
options.
I'm taking a micro-leap of faith in asserting that
migrations of this type are more common (and critical)
for server-executed code than for client apps.
15 or 20 years ago, I'd say that cross-platform code
was key to ensuring survival of client-side apps. No
so much these days. The present world is now dominated
by highly adaptable survivors such as pidgeons,
cockroaches, McDonalds and Microsoft Windows.
Joel Neely wrote: ---
> By artificially drawing a boundary between "client"
> and "server" we introduce unnecessary distinctions.
Bzzzzt! I need to buzz-in on you here. Good stuff, and
we can speculate that it will be more relevant in the
grand "one degree of separation" future, but still a
bit of a digression. I use the terms client and server
because we're all familiar with the terms/concepts.
I provided a list of important criteria for successful
software, and that cross-platform code addresses one
of those items. I'm not attacking the importance of
cross-platform code, just putting it in perspective.
I mean no disrespect, Joel. Your participation and
support of Rebol over the years has helped me
immeasurably. I'm sure many on this list would say the
same.
// Ed
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted