mcdonald@uxe.cso.uiuc.edu (11/04/88)
I've observed a lot of users using a lot of programs over a long time. I note that the order of the following list has changed over the ages. But today I really believe it to be true. User's Program Priority List (1 is highest priority) 1. Cost is <= amount of money purchaser has at hand. 2. Utility. The program must do what the user need it for. It must have ALL necessary features. For example, if the user's name is Co^te', a word processor is useless if it can't get the accents over the letters. If a word processor can't produce integral signs it is useless to me. If a spreadsheet can't produce pound signs (which this medium can't!), it is useless in England. 3. Look and feel. It should look nice and be easy to use. For a large and growing segment of the world, this means it should work like a Macintosh. Lacking that, it should be full-screen, and use all the functionality of the computer it runs on. For example, word processors should properly display imported graphics. Fonts should appear on the screen as they do on paper. Menus and commands should be used INTELLIGENTLY, at the whim of the user. There should be more flexibility here than is usually the case - a Mac failing, slowly being remedied. 4. Speed. Speed. Speed. More speed. 5. Small memory usage. 6. Bug-free. Note that this is number six. Users will tolerate small bugs if a program is otherwise suitable. But they will mercilessly flame the seller. If that seller give an essentially free update that fixes the bugs, users will not actually blacklist the seller. 7. Portability of program. Users would like to be able to use the same program on different computers. 8. Cost. If item #1 is met OK, actual cost doesn't seem to be very important. _________________________________________________________________________ User's don't care AT ALL about items below this line. This implies that they matter only as they impact things above the line. A. Portable source code. Users don't read source code. But they do do know what "vaporware" is. B. Easily maintainable source code. Users don't read source code. C. Language program is written in, whether it is "structured" or not, whether it is "object oriented" or not. Users don't read source code. Of course, if the user and programmer are the same, or closely related, the order may change. Comments and flames are welcome. Doug McDonald (mcdonald@uiucuxe)
rgh@inmet (11/13/88)
>another teacher here loves ANSI C, and every 'enhancement' he mentions >smacks me of being Pascalish in orientation. For example, the >declaration of variables within the function parentheses will >provide the 'protection' that Pascal lovers want only if the >compiler can compile both the caller and callee at the same time. >Or the linker must be more sophisticated, using information that >is generated by the compiler. How will it be handled folks? >Either way we lose. If the compiler does it, there goes our >modular strategy of putting related functions in seperate files >from the functions that use them. But then we could always >#include C code files, which is exactly what one of the afore- >mentioned teachers required of beginning C students! But what >if I want to package a set of functions for users of equipment >I manufacture to connect to the computer and I don't want them >to have the source? Then the linker will have to do it. Will >that cost more for the compiler and linker? Apparently you've not been informed that function declarations can use the prototype notation [i.e., declaring argument types as part of the function header] as well as function definitions. This addresses all your concerns: you put a prototype function declaration in an include file, and include that in all the modules that call that function, and in the module that defines the function. The linker doesn't have to do anything special. You market your function package as an include file that declares the functions, along with the object modules that define the functions. Fairly standard practice these days is to write a .h file declaring the types, macros, functions that form the external interface of the corresponding .c file. There are potential efficiency gains in this prototype business which should interest you. In the absence of prototypes, integral arguments have to be at least int-size, and floating arguments have to be at least double-size. That is, an actual argument of type float is converted to double in the calling sequence. If the caller and callee can agree, via prototypes, that the argument really is a float, then the conversion can be omitted. More fundamentally, C implementors have had to assume that any function call might be to a function that takes a variable number of arguments (such as printf). This constrains calling sequence design in various ways. For instance, several machines have a Return instruction with a operand specifying how much data to pop off the stack. You can't use this instruction unless you know how big the argument list is, which in classical C you don't. So generally the argument list gets popped off the stack at the call site, certainly more expensive in space and often in time. Now part of the prototype syntax is specifying functions (like sprintf) that take optional trailing arguments. All other functions can be assumed to take a fixed argument list. Thus an implementor could choose to use that Return-popping-n instruction in most cases. Passing arguments in registers also becomes a more attractive implementation, for similar reasons. Randy Hudson rgh@inmet.inmet.com uunet!inmet!rgh
joe@modcomp.UUCP (11/21/88)
Steve Summit (scs@adam.pika.mit.edu) writes [slightly edited]: > There is an abominable quantity of horrible code in existence today, and > egregious amounts of time are wasted trying to fix neverending bugs, trying > to add seemingly reasonable features which the "architecture" inexplicably > prohibits, and finally abandoning the whole mess and rewriting it from > scratch. I agree completely. > I will be vehemently disagreed with, but I submit that most of this > unmaintainable code arises out of misplaced concerns for "efficiency." Some of it, yes, is produced by otherwise good programmers with misguided notions of what is important. However, my experience has been that most bad code comes from bad programmers. These fellows don't try to put "efficiency", or anything else, into their code. > It is true that there are a lot of miseducated programmers out there, but > their miseducation often derives from teachers and textbook authors who > constantly harp on efficiency without teaching moderation, and from the > badly-written code by which they are surrounded and which they (the > students) inevitably emulate and go on to perpetuate. I'm not sure if the swarms of bad programmers are due to miseducation. Certainly, my teachers didn't harp on efficiency issues; there just wasn't enough classroom hours to do that and also get the basic concepts across. Rather, a lack of excitement for the field, a mismatch of skills, perhaps due to the selection of a career based on paycheck rather than interest, may be the more important factors. Of course, it doesn't help that the problem of writing truly maintainable, flexible code is one of the most challenging and creative things available to the working programmer. I suspect that none but the best of us will ever be very good at it, at least, not until the "general principle of creativity" has been discovered and reduced to a rule of thumb (:->). > When assigning priorities, though, I would rather have people learn clarity > and good style first, and efficiency as the need arises. (Among other > things, the marketplace imperatives of which we are endlessly reminded will > ensure that efficiency will not be neglected; while there are, sadly, not as > many incentives for writing clearly.) The industry is not plagued by slow > programs (compilers being tuned for the benchmarks to the contrary > notwithstanding). The industry is plagued by software that is over > schedule, over budget, buggy, and unmaintainable. Right on the mark. No one could have said it better. Joe Korty uunet!modcomp!joe