Archive of UserLand's first discussion group, started October 5, 1998.

Re: You end up with the same soup

Author:Paul Snively
Posted:4/4/1999; 4:39:15 PM
Topic:Zope vs. Frontier
Msg #:4801 (In response to 839)
Prev/Next:4800 / 4802

>>It's interesting after four years of Java WORA religion it's come >>back to that. That's what Bill Gates said. We tried WORA once before >>(at least). It was called the UCSD P-System. Well, guess what, few >>people wanted to use software written for a virtual machine, they >>wanted to use Apple II software, or IBM PC software

I have to say, Dave, that I think this comparison is a tad unfair for essentially two reasons: first, because in those days practically all "users" were technical and, as such, were largely locked into the mindset that insisted upon machine-level access--hence, "using p-code" meant "learning the p-code assembly language," regardless of the fact that the point was to provide a portable runtime environment for UCSD Pascal. Secondly, the hardware of that generation obviously couldn't support a virtual machine efficiently, and the truth about performance is that before all other performance criteria are measured there's a binary "fast enough/not fast enough" criterion that must be met. The p-machine was arguably "not fast enough" for the majority of users of the day. Contrast that with, e.g. the 68040LC emulator of the first generation of PowerPC-based Macintoshes, which was "fast enough" for the 680x0-to-PowerPC transition to have been successful by practically anyone's definition.

>>BTW, I don't believe that the Mac way is better. I think that Brent >>is about to have a very interesting experience as he dives into C on >>Unix. On Unix, C is almost a scripting language, it's so simple.

Well, sure: given a minimalist OS and a minimalist programming language, it's not hard to assert that the result has the virtue of simplicity, perhaps even elegance: programming the UNIX console in C could be called the haiku of programming precisely because the austerity of the environment coupled with the constraints imposed on the environment can result in outcomes that resemble what we might call "art." I don't see how that mitigates against the advancements of what, for contrast, we might call the "McDonalds" of GUI-based environments.

>>The Mac way yields applications that are a bitch to understand >>internally, but are easy to use editors of all kinds. The Unix >>approach makes very low-tech therefore highly reliable servers.

If by "the Mac way" you mean "writing applications strictly to the Mac Toolbox and OS," then this is very hard to argue with, but that's why frameworks such as MacApp and Powerplant, to name only the most obvious ones, arose: as an attempt to map an improved set of concepts (commands, chains of command, observers/observables, a more flexible and robust event model, etc.) onto the admittedly primitive Mac Toolbox and OS.

Incidentally, it's not necessarily true that all UNIX-based servers are "low tech." I've been developing largely UNIX-based application servers for the past couple of years now--some of them multi-machine, multi-CPU-per-machine, caching, Fortune-100-financial-security-level monstrosities--and let me tell you, it's as big a jungle in that space as it is in the desktop PC or even most ISP's rack-mounted Wintel boxen space, if not more so.

>>When Unix gets a standard GUI, if it gets one as rich as Windows or >>Mac, it will require just as much head-banging to make the software >>work as users expect it to.

I think that if you look closely at CDE, KDE, and/or GNOME, you'll find that this has already been borne out. But to lay this at the doorstep of GUI's themselves is, I'm quite convinced, an error in judgement. The truth of the matter is that we software developers, in our hubris, have largely created GUI's in a humanistic vacuum. We need the input of psychologists, sociologists, linguists, historians, and perhaps most of all semioticians, in the formation of effective graphical user interfaces. We also need to recognize that GUI's are a newborn concept that has arisen in the infancy of personal computing, which itself has arisen only in the adolescence of high-speed electronic computing at all. We will make mistakes--lots of them--along the way.

>>You can push the piles around, but there are no silver bullets, you >>end up with the same soup if you use the same ingredients.

Too true. Unfortunately, the various disciplines that I'm convinced need to come together to provide an effective ingredient list, if you will, are barely speaking to each other, if not outright hostile to each other. A good place to start would be for everyone who is serious about developing software for a living to start taking courses in philosophy, cognitive psychology, logic, and probability and statistics, all with the background questions in their mind being: "Why is software so inflexible? Why doesn't software adapt itself to the user?" and the goal being to change that observation.



This page was archived on 6/13/2001; 4:49:13 PM.

© Copyright 1998-2001 UserLand Software, Inc.