hrubin@pop.stat.purdue.edu (Herman Rubin) (01/25/91)
In article <1991Jan24.222501.7054@research.canon.oz.au>, andy@research.canon.oz.au (Andy Newman) writes: > In article <13985@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill) writes: > >A 'user' just wants to run applications. > > Aren't you a computer user? > > Give (non-programmer) ``users'' some credit ... a user who understands that > they can construct their own applications by plugging together some tools > in the correct order would want some easy mechanism to construct pipelines > (and pipelines aren't the only model). There are, unfortunately, some who want the software to do all their thinking for them. It is only those who can be called non-programmers. Anyone who has to put things together is already doing programming. As andy points out, even a pipeline is a program. One of the problems I have with using "packages" is that they do not allow the combining of tools. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
hrubin@pop.stat.purdue.edu (Herman Rubin) (01/29/91)
In article <12830@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <1991Jan28.112723.15274@lth.se>, by magnus%thep.lu.se@Urd.lth.se (Magnus Olsson): > > [...] > > Users aren't stupid (at least, not most of them). However, most of them lack > > the energy and motivation to think like programmers. [...] > > It has nothing to do with motivation or intelligence. It's just a matter > of cost-effectiveness. If it takes longer to learn to do something than > the value of being able to do it - it's _more_ intelligent _not_ to > learn it. > > > [...] Instead of forcing people > > to adapt to computers, wouldn't it be much nicer if we adapted computers to > > people? > > Exactly!! > > J. Giles This is exactly wrong. It assumes that the computer can be programmed to do exactly what the user wants. In my experience, this is far from the case. What does happen is that the user is taught that what the guru has put in the language, system, etc., is what the computer is capable of. The user is deliberately kept from even finding out the capabilities of the hardware, and then the hardware is built in such a way as to make these capabilities difficult and expensive. To adapt computers to people, we have to let the people who can understand what hardware can be capable of to get into the act. One of the recent "developments" is to separate integer and floating-point operations. Now that some people cannot see the need for not doing this does not mean it should not be done, nor that it should be made expensive. High accuracy arithmetic can be done in floating point, but it is a real mess; usually one makes the floating point emulate fixed point. The same applies to packages. They rarely do what is really needed, or they do it clumsily. BC (before computers), it was necessary for the user to put together what was wanted. This is programming. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
barmar@think.com (Barry Margolin) (01/31/91)
In article <1991Jan30.100611.6787@lth.se> magnus@thep.lu.se (Magnus Olsson) writes: >The concept of `folders' on the Mac is identical to what is called >subdirectories under Unix, MS-DOS, VMS and so on. Under these last >OS's, you see lots of users who refuse to learn anything about subdirectories, >but put all their files in the root directory. Is this because the concept of >a subdirectory is so inherently difficult that the users just can't understand >it? Possibly - but I haven't seen a single Macintosh user (at least not one >with a hard disk) who didn't understand and use folders. I think one reason (but not the only one) Macintosh users make folders is because they *have* to. The graphical user interface makes it harder to access files that don't fit on the screen. With a single folder the user would be spending all their time scrolling the window to find the files they want (yes, there are some keyboard shortcuts, but most users probably don't know about them). On a traditional, command line OS it's just as easy to access a file in a big directory as it is in a small one. Also, the size of the directory isn't as obvious on a text-based OS, whereas graphical file managers put a representation of the directory right there on the screen, reminding you all the time. >The point is: to use >the Unix subdirectories, you have to have some *udnerstanding* of how the >directory tree works. To get that understanding, you must spend some time >reading manuals, or having it explained to you. On a Mac, the concept of a >folder is intuitively obvious once you've played around with the finder for >five minutes or so I find it very difficult to believe that significant "understanding" is necessary to use traditional subdirectories. Sure, you have to find out about the "mkdir" and "cd" commands, whereas the menu and visual interface of a Mac make this step simpler. But you don't have to understand how it works; all the user needs to know is that directories are places to put their things. Here's an interesting question I have: how many unsophisticated Mac users have nested folders (not counting nested folders built automatically by some application)? My guess is that very few do. I'm not sure exactly what the significance of this would be, but it seems like it should mean something. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
swsh@ellis.uchicago.edu (Janet M. Swisher) (01/31/91)
In article <1991Jan30.193422.15369@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Jan30.100611.6787@lth.se> magnus@thep.lu.se (Magnus >Olsson) writes: >>The concept of `folders' on the Mac is identical to what is called >>subdirectories under Unix, MS-DOS, VMS and so on. Under these last >>OS's, you see lots of users who refuse to learn anything about >>subdirectories but put all their files in the root directory. Is >>this because the concept of a subdirectory is so inherently >>difficult that the users just can't understand it? Possibly - but I >>haven't seen a single Macintosh user (at least not one with a hard >>disk) who didn't understand and use folders. > >I think one reason (but not the only one) Macintosh users make folders is >because they *have* to. The graphical user interface makes it harder to >access files that don't fit on the screen. With a single folder the user >would be spending all their time scrolling the window to find the files >they want (yes, there are some keyboard shortcuts, but most users probably >don't know about them). I know of one person who understands folders all right, but he arranges the files on his hard disk the same way he arranges the papers in his office: spread out as widely as possible with as few layers as possible. But he doesn't claim this is organized or efficient; it's just the way he likes it. >I find it very difficult to believe that significant "understanding" is >necessary to use traditional subdirectories. Sure, you have to find out >about the "mkdir" and "cd" commands, whereas the menu and visual interface >of a Mac make this step simpler. But you don't have to understand how it >works; all the user needs to know is that directories are places to put >their things. > >Here's an interesting question I have: how many unsophisticated Mac users >have nested folders (not counting nested folders built automatically by >some application)? My guess is that very few do. I'm not sure exactly >what the significance of this would be, but it seems like it should mean >something. You may be right about naive users creating nested folders *intentionally*, but I have seen entirely too many naive users with things like Copy_of_Empty_Folder:Empty_Folder:Empty_Folder. And then somehow they got Microsoft Word's spelling dictionary down at the bottom of that so the program can't find it. One thing I think this means is that the use of "New Folder" is not necessarily any more self-evident than "mkdir". -- Janet Swisher Internet: swsh@midway.uchicago.edu University of Chicago Phone: (312) 702-7608 Academic and Public Computing P-mail: 1155 E. 60th St. Chicago IL 60637, USA
jlg@lanl.gov (Jim Giles) (01/31/91)
From article <1991Jan30.100611.6787@lth.se>, by magnus%thep.lu.se@Urd.lth.se (Magnus Olsson): I agree with everything else you said - except the following. > [...] >b)The users with som knowledge of programming (let's not be picky about whether > these are programmers or users - they act as users, anyway), who use one > terminal window on their workstation and the simplest possible editor (like > dxnotepad under DECwindows) to write, compile and link small Fortran > programs, and learn to do this and to send and receive mail, but never much > more. That's about the way I use UNIX. I've had a UNIX workstation for several years. I don't use just one window (I usually have about 7). I _do_ use the simplest adequate editor I could find (the Rand editor: e). I write Fortran (and other language) programs - but "small" is a relative term - I regard anything less than 10000 lines as small. However, I don't compile and link any of these on UNIX - frankly, UNIX could never hope to run any of them (UNICOS on the Cray, perhaps - but not the UNIX on the workstation). I don't learn UNIX tools (more than a taste here and there), because it's obvious than none of them do anything helpful: no asynchronous I/O support, no tools to aid vectorizing code, no tools to analyze stability of numerical algorithms, etc.. Even the debuggers are crummy compared to what I have available elsewhere. Except for the big screen (that lets me see lots of context of my current problems all at once), UNIX just plain doesn't do anything that's useful to me. And, for a mainframe (like a Cray), UNIX is a vast step backward. J. Giles
chip@tct.uucp (Chip Salzenberg) (02/01/91)
According to jlg@lanl.gov (Jim Giles): >I don't learn UNIX tools (more than a taste here and there), because >it's obvious than none of them do anything helpful ... "Obvious." Right. Can you say "prejudice"? >Except for the big screen (that lets me see lots of context of my >current problems all at once), UNIX just plain doesn't do anything >that's useful to me. Clue: UNIX has nothing to do with screen size. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/02/91)
In article <3169@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > In article <13252@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > > | What? NONE of the UNIX tools do anything _NEW_. They are just poorly > | designed and hard to use versions of utilities that every system I've > | ever seen has versions of. > > That's great! We've been spending thousands of dollars to gt unix > tools for other systems, and all this time they were right there. > > So what programs under MS-DOS, AmigaDOS, MaxIntosh, VMS, AOS, CMS and > JPL correspond to awk, sed, yacc, diff, and grep? Other than VMS, which > has a diff which produces an output which is only human readable, and a > search command which lacks powerful pattern matching, the capabilities > seem... well *missing* is the first word which comes to mind. What do these tools have to do with the UNIX operating system? Possibly there are some legal restrictions in some cases, but I believe most of these are public domain. At most, interfaces would have to be rewritten. The hardware provides the capabilities. As far as possible, software should allow the user access to these capabilities. Except for security restrictions, and possibly some restrictions to prevent physical damage to the machine, software should allow whatever hardware allows, instead of restricting it. As far as grep is concerned, the only UNIX part in the interface is handling file access and the ability to display file names. I agree that any operating system needs this, and the more flexible the better. This means reading directories, and the possibility of accessing files only found by reading directories. That is part of the operating system. Getting line numbers, etc., is not. The hardware manubacturers should help the users use the hardware; the systems designers should make the systems flexible so that tools can be easily inserted or replaced, and the tool designers should make the tools so that they do not restrict the users. To much to great an extent, all of these are being violated to a very great extent. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
les@chinet.chi.il.us (Leslie Mikesell) (02/05/91)
In article <5038@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >> So what programs under MS-DOS, AmigaDOS, MaxIntosh, VMS, AOS, CMS and >> JPL correspond to awk, sed, yacc, diff, and grep? Other than VMS, which >> has a diff which produces an output which is only human readable, and a >> search command which lacks powerful pattern matching, the capabilities >> seem... well *missing* is the first word which comes to mind. >What do these tools have to do with the UNIX operating system? Possibly >there are some legal restrictions in some cases, but I believe most of >these are public domain. At most, interfaces would have to be rewritten. What unix provides is the ability to easily tie these tools together so that you can combine the operations of the individual tools. How would you propose to get an equally easy-to-use interface in a single-tasking environment like MSDOS or CMS? >The hardware provides the capabilities. As far as possible, software >should allow the user access to these capabilities. Except for security >restrictions, and possibly some restrictions to prevent physical damage >to the machine, software should allow whatever hardware allows, instead >of restricting it. Exactly, and if you are inclined toward the toolbox approach, that means the OS should provide multi-tasking, virtual memory, and an efficient means to connect the output of one program to the input of another. Also, you need a quick and easy way to automate any portion of a task that the operator finds to be repetitive. >As far as grep is concerned, the only UNIX part in the interface is handling >file access and the ability to display file names. I agree that any >operating system needs this, and the more flexible the better. This >means reading directories, and the possibility of accessing files only >found by reading directories. That is part of the operating system. >Getting line numbers, etc., is not. Wrong! The useful function has nothing to do with directory reading because it doesn't do any (at least under unix where the shell normally expands wildcard filenames). It has much more to do with the fact that grep can be used to parse the output of any other program that generates a stream of lines, and in turn its output (and exit status indicating sucess of a match) can be used by any other program. While it is possible to approximate the functionality of pipes using temporary files, there are many situations where this is impractical. For example the total amount of data may be larger than the available storage, or you may wish to interrupt the processing as soon as the first output appears. Les Mikesell les@chinet.chi.il.us
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/06/91)
In article <27AF17B9.72E2@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > According to jlg@lanl.gov (Jim Giles): > >The people I'm talking have used _many_ different systems and have > >switched many times. They _know_ what's involved in moving to a new > >system. ... The conclusion is that UNIX does _not_ have sufficient > >capability to offset those features it lacks. > That conclusion would be meaningful if we knew to what purpose the > UNIX computers were being used. UNIX is not right for all tasks. > Those who claim so have something in common with those who claim the > opposite: prejudice. Computers are typically not obtained for single purposes. Both the hardware and software should be designed for versatility. Certainly the BSD version of UNIX was intended for the extremely varied university environment. This ranges from simple ASCII editing to powerful number crunching, and everything in between and even not covered by that range. In addition, UNIX is a monster. There are things normally included in UNIX which should be add-ons, and not part of an operating system. There is the mistaken view that hardware should be designed to particular languages, and never mind that some programs may be many times slower because of the lack of particular instructions. There is far more concern with "Braille optimization" and never mind what the sighted person can do. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)