Date: Fri, 29 Aug 1997 11:19:09 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Tim Vanderhoek <hoek@hwcn.org> Cc: Peter Korsten <peter@grendel.IAEhv.nl>, freebsd-chat@FreeBSD.ORG Subject: Re: ATT Unix for Windows ! Message-ID: <Pine.BSF.3.96.970829103015.341I-100000@fallout.campusview.indiana.edu> In-Reply-To: <Pine.GSO.3.96.970829063812.28421C-100000@james.freenet.hamilton.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Aug 1997, Tim Vanderhoek wrote: > editting (eg. with sed(1)), for two. And no, simply thinking > from a Windows point of view does not obviate the need for sed. > GUIs aren't that powerful (_yet_). ...Or, GUIs solve different sorts of problems so the comparison is possibly inappropriate.... > Fix the damn user. If a user is stupid, they are going to screw > things up, no matter what. GIGO is a universal law, and there's > simply no getting around that. A smart user will recognize when > they don't know wtf they're doing. The stupid user keeps > bumbling-on, and there's no way for anything, either a program > working from a text init file, or not. It's not possible to > screen-out every wrong input, because if there was only one right > input, we wouldn't need any input... You make sweeping generalizations about user intelligence. For example, imagine an architect who is a virtuoso with a piece of CAD software. They have taken the time to become a smart and sophisticate user within the domain where computer and architecture intersect. From the point of view of the busy architect, the smaller this intersection the better so long as the benefits of the technology can be had. If forced out of that small overlap area, the architect may look and feel like an incompetent bumbling idiot. The driving philosophy of the Star/Lisa/Macintosh lineage was to maximize application domain benefit while minimizing computer domain expertise requirement. The Unix philosophy is closer to maximizing application domain benefit by maximizing computer domain expertise. Both approaches are effective, but it shouldn't come as any surprise that the potential market for the former is much larger. Not only that, there probably isn't much overlap between the markets. It is also worth noting that the Unix tool and pipe model doesn't map into a GUI world very well. The knee-jerk reaction is to discount the GUI world as being inferior, without making an effort to understand it. Alternatively, attempts are made to apply Unix tool philosophies to the GUI world, witness dozens X toolkits. But, while Unix tools can be put to good use in isolation a widget is nothing unless embedded in an application. The Unix philosophy tends to leave that last step--the application development--up to the end user, the problem being that developing a good interactive GUI application is a lot harder for most traditionally trained programmers than developing a good batch-oriented command line tool. The programming isn't hard, the design is; it has absolutely nothing to do with anything you will find in any algorithms or data structures text. You have to venture into graphic design, industrial engineering and psychology. Effective small can be built built on a good understanding of algorithms and data structures. Effective GUI applications are built on a good understanding of application domains and the capabilities of the target user. Now, I want to have my cake and eat it to, namely high quality GUI applications that allow me to concentrate on the task at hand instead of always having little bits of the computing domain intruding, yet be able to drop down into "small tool" world when I need to do something too unusual or rare to warrant designing a GUI for it. Sort of a Macintosh/Unix hybrid like the Next but with enough market share to attract good application developers. Sorry, I sort of rambled.... -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970829103015.341I-100000>