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 | +---------------------------+------------------+-------------+
peter@ficc.ferranti.com (Peter da Silva) (07/16/90)
In article <RANG.90Jul13220207@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes: > 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. Well, it seems no two Modula-2 compilers have the same set of run-time libraries for I/O. Then there's Fortran, which is so constrained to the fixed-format card-image world that to do anything interesting with it from the point of view of the user interface you pretty much have to go right to the system. Pascal, of course, is aother case where a limited base standard has led to the use of massive numbers of non-portable extensions. Forth is a sitting duck, so I won't take a shot at it. ADA hasn't been around long enough to tell one way or the other, but I understand a lot of the DoD ADA code has become dependent on VRTX. To sum it up, I can't think of a single language in which it is the slightest bit difficult to write non-portable code. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
brown@csd.uwo.ca (Mike Brown) (07/16/90)
In article <RANG.90Jul13220207@derby.cs.wisc.edu>, rang@cs.wisc.edu (Anton Rang) writes: |> |> 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. |> I completely agree and that's why I took CS611 here, a Masters level course in Software Engineering which includes a year-long project for a real user. This year we (3 of us) did an X Windows-based scholarly text processing system for an English professor (SGML, TeX, etc). I worked for 3 years before coming back for my Masters, but being the architect of a project of this size (15,000 lines) and working with the client to come up with the best solution to his problem was quite a learning experience. I would reccommend it to every CS student - get this kind of experience as early as you can! ------------------------------------------------------------------------------ Mike Brown, Gradual Student in Computer Science, University of Western Ontario brown@csd.uwo.ca ..then the bartender says "That's not a duck!". (Wait for laughter) "Four score and seven years ago ..." (G. Larsen)
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/25/90)
In article <665@ria.ccs.uwo.ca> brown@csd.uwo.ca (Mike Brown) writes: In article <RANG.90Jul13220207@derby.cs.wisc.edu>, rang@cs.wisc.edu (Anton Rang) writes: |> |> 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. |> I completely agree and that's why I took CS611 here, a Masters level course in Software Engineering which includes a year-long project for a real user. This happens also at the local University, for all undergraduates, and non research postgraduates. Well, the client is not real-real (it is some lecturer or professor), but the experience is nice, from what I see of them. This year we (3 of us) did an X Windows-based scholarly text processing system for an English professor (SGML, TeX, etc). I worked for 3 years before coming back for my Masters, but being the architect of a project of this size (15,000 lines) and working with the client to come up with the best solution to his problem was quite a learning experience. Here we stumble upon an interesting problem: you and your friends put 3 man years into an interesting user grade application of 15,000 lines, which on the face of it should be of interest to a vast public. Who owns it now? (hint: some universities insist they own exclusively any student work, and students are not allowed to publish or redistribute their work without permission, which is routinely refused until it is proven that such cannot be commercially exploited by the university). Who *should* own it? Well, if your University has done what IMNHO is the right thing, why don't you tell us where to fetch it. I have a few people here that would like to try it :-). -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk