Hi, Ed, 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). -jn- (As usual, my opinions are my on, and do not reflect the position of any other party -- including myself 24 hours later! ;-) -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
