peter@ficc.uu.net (Peter da Silva) (04/13/89)
In article <28836@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > As a programmer who has worked on the IBM PC, VM/CMS, MVS, UN*X, Mac, ect, I > have to say that as a programmer, I had more control over what the user could > do under command line interfaces. As a user I have more control over what the program will do under command line interfaces. I can combine commands in ways the programmer never expected. Because a well-defined and well-implemented command line interface is also a programming language. > Now that graphic interfaces (like the Mac, Windows, GEM) are becoming the norm, > I have to take more care in writing code that doesn't know what order the user > normally works with. When writing a graphics-oriented program I really have more control over the user, because he can't really get to me. I know what sort of environment I'm going to run in. I don't have to worry about input streams coming from strange places like pipes or files. I don't have to make sure that I seperate my error messages from my useful output... it's all going onto the screen anyway. > The user likes this because they have more control over how they use my > program. I, as a user, hate working with a menu-only program that didn't have to be that way. How the hell do you put MacPaint into a script? > (flame on) > I have found that most programmers care only about their programs. ... > this "I know better what the user wants than the user does" attitude of > programming. This is rubbish. It's the graphic interfaces that force me to live in the straitjacket world of what this other dopey programmer thought up. What if I want to do something else while this ultra-cool spellchecker is running over my design document. On UNIX, no problem... just throw it into the background. On the Mac you have to sit there and manually intervene for every damn typo when it discovers it. Repeat after me... PROGRAMMERS ARE USERS TOO. Not only that, but they spend MORE time using software tools than any other class of user. Don't you think they'd have some complaints if your precious graphics were so superior? > Since graphic > interfaces challenge that belief, a lot of programmers are against them. Graphic interfaces reinforce that belief. The user is tied to the environment the programmer decides to allow them, instead of being free to build their own environment using the program as a tool. I have the best of both worlds at home. An Amiga, with a fancy graphics interface AND an integrated programming environemnt called AREXX. You can write scripts that control your fancy menu-driven programs. More and more people are using AREXX as a common macro/command language that co-exists with the intuitive menu-oriented one. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
bruceb@microsoft.UUCP (Bruce Burger) (04/18/89)
> This is rubbish. It's the graphic interfaces that force me to live in the > straitjacket world of what this other dopey programmer thought up. What if > I want to do something else while this ultra-cool spellchecker is running > over my design document. On UNIX, no problem... just throw it into the > background. On the Mac you have to sit there and manually intervene for > every damn typo when it discovers it. I don't think running a spell checker in foreground has anything to do with a graphical interface, just an interactive one. It would be quite simple to develop an interactive spell checker that was not graphical, and vice versa. (As a matter of fact, I've used an interactive spell-checker with EMACS, which is a rather graphicless program!) The advantage of an interactive spell checker is that it lets the user see the context of each word so they can easily correct it, something that's difficult with the plain UNIX spell command. The disadvantages are that you have to wait for the CPU and you have to be distracted with the computer displaying the context for lots of words that you can quickly identify as correct. Apparently most PC software vendors think the advantage outweighs the disadvantages. I suspect they're right, although I agree it would be nice if a word processor had an option to check spelling as a batch background process and produce a list of misspelled words. Anyway, don't condemn graphics because you don't like a specific feature to be implemented interactively. A graphical interface is based on the premise that not all information is best presented or provided textually. When you're driving a car, would you prefer to see a textual description of what's in fromt of you, or look at the road? Of course, it can be overdone, and of course, there are unique merits to a command language. They *don't* have to be mutually exclusive! True, they often are today, requiring a developer to choose between them, but that's changing. As for interactivity, that's another feature that's useful in some situations and not in others. Software technology has a long and exciting road ahead; there are tremendous opportunities for graphics (and interactivity, and command languages) in that world. Bruce Burger
peter@ficc.uu.net (Peter da Silva) (04/18/89)
In article <5518@microsoft.UUCP>, bruceb@microsoft.UUCP (Bruce Burger) writes: > Anyway, don't condemn graphics because you don't like a specific feature > to be implemented interactively. a) I'm not harping on a specific feature. A spell-checker is just an example. There are others... compilers, for example. > A graphical interface is based on the > premise that not all information is best presented or provided textually. b) I understand this. If I didn't, I wouldn't have an Amiga (which lets me use textual, graphic, video, and audio data) now would I? The problem is that not all information is best presented either graphically or interactively... and on the Mac you really don't have an alternative. > and of course, there are unique merits to a command language. > They *don't* have to be mutually exclusive! c) Surely not. Look at X, News, Display Postscript, etc... It's easier to choose if you're not working on a machine that ties every program to the user-interface. Can you imagine a non-interactive application on the Mac (not device drivers or spoolers, but something like a compiler)? Sure, under MPW. Problem is, now you lose the advantages of the graphics interface. Again, the application is tied to the user interface of the machine as a whole. It's not just the Mac... how many compilers run under Microsoft Windows? Well, there's Actor... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
josef@ugun21.UUCP (04/20/89)
There was a rather interesting talk at the recent EUUG conference in Brussels (Belgium) on splitting a program into two parts - the functional part - the user interface In doing this, You can use the functional part as a filter or inside a shell script. Buit IMHO this also will allow You to - use different user interfaces (icons, menus, command line args) - run functional part and user interface on different machines. The talk was Dp: a System for Inter-Program Communication by Robin Faichney Computing Laboratory The University Canterbury, Kent CT2 7NF England (rjf@ukc.ac.uk) Josef Moellers paper mail: e-mail: c/o Nixdorf Computer AG USA: uunet!linus!nixbur!mollers.pad Abt. EG-3 !USA: mcvax!unido!nixpbe!mollers.pad Unterer Frankfurter Weg Phone: D-4790 Paderborn (+49) 5251 104691 +-----------------------------------------------------------------------+ | "Many that live deserve death. And some that die deserve life. | | Can You give it to them? Then do not be too eager to deal out | | death in judgement" | | Gandalf to Frodo in "The Fellowship of the Ring"| +-----------------------------------------------------------------------+
chari@nueces.UUCP (Chris Whatley) (04/25/89)
In article <6800003@ugun21>, josef@ugun21.UUCP writes: > There was a rather interesting talk at the recent EUUG conference in > Brussels (Belgium) on splitting a program into two parts > - the functional part > - the user interface > In doing this, You can use the functional part as a filter or inside > a shell script. > Buit IMHO this also will allow You to > - use different user interfaces (icons, menus, command line args) > - run functional part and user interface on different machines. If you have ever seen or used Mathematica on a Unix machine, you have seen this in action. I am not *absolutely* sure of all of this but, the copy of Mathematica I have used on my NeXT includes the files that would allow you to run either the NeWS, NeXTStep or Suntools graphics interfaces. Of course you can't do these *on* the NeXT, only with the Sun (or whatever) connected to the NeXT running the Kernel. (I have no idea why you would want to use a NeXT for this though. Math is not especially speedy with the 68882.) In all implementations of Mathematica (that I know of) you run the Kernel and the user interface as different entities and they communicate with ascii text. So, I can run the kernel on a supercomputer and use the interface of my NeXT to interact. Also,a simple tty interface is available which could be used in a script though it would be a bit slow since the kernel is so large and slow to load. Not something I recommend but, it is there. This way you have a choice of interfaces. A Mac or NeXT with notebooks (text and graphics in the same window), a Sun or DEC 3100 (etc..) with a tty interface for text and graphics in a separate window or terminal interaction only. Just my 2 francs, Chris