rang@cs.wisc.edu (Anton Rang) (07/14/90)
I'm moving this over to comp.misc since I'm not sure it really belongs in comp.arch; feel free to move it back if you do. :-) In article <64044@sgi.sgi.com> karsh@trifolium.esd.sgi.com (Bruce Karsh) writes: >We were bombarded with information about how programs "should be" >structured, but usually the end-result of all this structuring was >slow, user-unfriendly, huge programs. Of course, structure in itself doesn't lead to slow, unfriendly, or huge programs. What often does, though, is an over-emphasis on it, to the detriment of the program's usefulness. I think about structure as I design a program, because I find that it makes it easier (for me) to put the whole thing together and make it work. Trying to retro-fit "structure" into a program after the design has been done doesn't work, but unfortunately is what a lot of students in CS classes do. (Structure is often taught as a textual thing, or a coding issue, and not as a design issue; my personal feelings are that if the design has been done in a fairly structured way, the structure of the code generally appears magically. :-) >Much of what we did was completely unconcerned with what the program >did for the user. Yeah. It's pretty easy in most CS programs to get a degree without ever writing a program that people actually use. In fact, having nasty user interfaces is often encouraged, probably because it makes grading easier. "Write a program that multiplies two three by three matrices; read in the 18 elements as real numbers, one per line, with no prompts; print the solution in such-and-such a format." There are definitely days I think all CS majors should be forced to take a class where they actually talk with a user and have to write a program for the user, and have part of their grade based on how well it works, the user interface, etc. Probably impractical, but I think it can be done better than it is right now. >Portability, modularity, programming style, and extensibility are >religious issues, Their general necessity has never been proven Well...depends what you mean by "general necessity". If you mean that not *every* program needs to be portable/modular/whatever, you're certainly right. If I need to hack something together to get something done "right now," and there's an obvious though ugly way to do it, I'll use it. I think modularity is useful in general for larger programs, just because it makes them easier to comprehend. I can write unstructured programs up to a few hundred lines or so; after that, I impose some structure on it just to keep my brain clear. :-) Portability is something which is not especially important most of the time; on the other hand, it's rather difficult to write non-portable code in many languages (C being one notable exception, and of course any code using system routines or run-time libraries is non-portable as well). You have to work at it, a bit. Style...religious issue, yeah, mostly. Some people argue that a particular style helps other people doing maintenance; I generally find that any consistency helps me, whether it's "good style" or not, and most programmers tend to be consistent. Extensibility is usually not worth it. If there's a clean way to put it in, then the design should at least allow for the possibility. If not, it should be left out. I've written a program which is fairly widely used (several hundred users at least), and has been hacked up by a number of people. I left out most of the extensions I thought of because it would have increased the complexity of the code a lot and not been much use to the average user. Others have added a lot of flexibility to it, but my code works well enough for most people, and I don't know of anyone whose extensions have been debugged and are working yet. So here, adding extensibility isn't worth it. I wrote the original code in about a week, and some people have been working on extensions for months. >I still hope for a day when programming professionals will evaluate >programs by how well they perform their intended function Gee, that would be nice. :-) Seriously, though, there are a lot of us (I do consider myself a programming professional though I'm still in school right now) who do. The right way to write software, as far as I'm concerned: 1. Find out what it ought to do, by talking to the users. 2. Design a tentative user interface and talk to your users to see what they think of it; iterate until they're happy. 3. Design the program. 4. Code it; test it. Repeat until done. 5. Ask the users how they like it, what changes they want, etc. Hopefully the design will be flexible enough that the changes are fairly minor; go to step 3 or 4 as necessary. Your mileage may vary. >In other technical fields, I have not found the stridency of belief in >unproven cosmetic practices as I have found in computer science. Hmm. Could be. There's certainly a lot of emphasis put on it in many undergrad classes, and even in respectable journals like CACM.... >So, yes there are dingbat undergrads in all fields, but in CS, there's >an intellectual attitude against learning new and difficult things. There's some; I know students who don't want to write "applications" because "it's no fun writing programs for users." I know a lot of them, actually. I actually find it as much fun as systems programming and even more rewarding: it's a nice feeling to know that you've given someone who doesn't know anything about computers the power to solve a problem they couldn't before. Of course, not all computer scientists (or would-be CS's) are like this. I come from a CS background, but with enough MIS thrown in to know that computers are at their best when they're helping people, and that studying computers-for-the-sake-of-computers is rather narcissistic, in a way. Oh well. This is longer than I'd intended, but I thought I'd throw in my $.02 (now more like $0.20 I guess). +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+