From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Darren New Subject: College, C, etc. (Was Re: Is there a language that Dijkstra liked?) Date: 1998/10/23 Message-ID: <3630C8DC.DF508803@fv.com> X-Deja-AN: 404370825 Content-Transfer-Encoding: 7bit References: <6skfs7$2s6$1@hirame.wwa.com> <35F252DD.5187538@earthlink.net> <6t4dge$t8u$1@nnrp1.dejanews.com> <6t5mtp$4ho$1@news.indigo.ie> <35FFE58C.5727@ibm.net> <3600E72E.24C93C94@cl.cam.ac.uk> <6ts1q0$vo2$1@nnrp1.dejanews.com> <361DBC60.C153BBAD@earthlink.net> <36228EC3.4F7381FD@domain.nul> <3630b064.23189339@news.supernews.com> Content-Type: text/plain; charset=us-ascii Organization: First Virtual Holdings Inc MIME-Version: 1.0 NNTP-Posting-Date: Fri, 23 Oct 1998 11:13:07 PDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-10-23T00:00:00+00:00 List-Id: Brian Mueller wrote: > Wish they would just teach me C, teach me GOOD C, teach me GREAT C, > teach my how not to screw up C so I could write anything. Anyone > wonder why the object ADA compiler and GUI program is written in C? > Because with a bit of extra work FASTER programs can be written in C > that do the same thing that ADA will do. Uh, you can't teach great C. C is a very simple language with lots of potholes. You can teach programming OK, but getting C right is simply a matter of experience. You make the same mistake the third time, and you say "Oh, right, I did that six months ago, it had the same wierd behavior, maybe I did it again." It's like driving. You can't teach someone how to get out of a blow-out or where to drive during an earthquake. The conditions where such could happen are just too variable. A blowout on a back road is a lot different than on an on-ramp, an off-ramp, on the freeway, etc. C's much the same. The only way to get good is to get a bunch of blowouts. It's like chess: you can learn the moves in a day. To be good takes months of playing. To be great takes years or decades. It takes like 2 - 6 years of programming C on a regular basis to where your programs will run without unfindable bugs after the first successful compile. *And* I must say, C and assembler and FORTH are the only languages (out of maybe 15 to 20 commercial languages I know) that are like that. The rest, if they compile they're close enough to right that you can find the bugs because it's obvious what's actually happening. (Personally, I now avoid any languages that have popular tools like Purify for patching your executable so you can find baroque bugs.) What's much more important than the language is to understand programming, understand how to build a program that'll do what you want, and all that other design/use case stuff. It doesn't look useful now, because you're only writing one-person one-month programs. You can't write a "great" program in homework by yourself. A "great" program is one that takes curve-balls thrown at you by the continued existance of the program without folding under the weight of a bad design. Sadly, almost nobody rewrites a program when it comes time to do so, when the maintenance costs of it exceed the cost of rewriting it. There's a timeliness factor that prevents most companies from taking six months off to rewrite a program to do the same thing as one they already have, except done right. Hence, if you only give the customer what they ask for, you're screwed three months later when they want to add something that's just too hard to add, but easy for them to describe. You need to understand correctness, robustness, how to interpret what the customer's asking for and turn it into what the customer wants (never the same), how to pick what language you'll use (I paid for my Ph.D. by picking the right language :-), understand the limitations and patterns and idioms you need to know in your chosen environment, understand people using computers (i.e., user interface stuff, even when you're not doing user interfaces yourself), and even various theoretical maths are useful (proving things equivalent to the halting problem or some NP-complete problem has prevented me from wasting weeks or months at times). > Now that you bring that up, I got into trouble for having too many > comment blocks in my code, WFT is this? I could have handed my > project to anyone in that room and they would have been able to read > it and understand what I was doing easily from my comments. I've > always been told, the more, the better. Not necessarily. A program that doesn't *need* comments is best. :-) Not that I agree with your professor, mind. But if you get to the point where you can hand your *uncommented* code to someone else and they can follow it, *then* you are a "GREAT" programmer. :-) The benefit being that you don't have to keep the comments up to date when you modify the code. The danger being that the code isn't nearly as clear as *you* think it is. > I hate my C.S. class, can't > wait until the spring when I get to take C (which I know a bit), and > learn how to do it RIGHT. Suggestion: The best way to do it "RIGHT" is to listen to your profs with skepticism, and *learn* what works, rather than going into it with the attitude that you already know what works and the prof must be wrong. Because the frustration you're seeing right now is part of the job you have to learn to work around. It's not restricted to one programming language or one college class. And you'll go out there, and your boss will say "Use Ada because I read it's good in a magazine." Your choice will be to use and understand it, or shovel fries into little bags. :-) [Example: right now I'm doing java, because "Use Java instead of Eiffel, because Eiffel is a botique language. We acknowledge it's far superior to Java for what we want to do, but how do we know it'll be around in 5 years?" Of course, Java wasn't around 5 years ago and Eiffel has been around some 14 years with minimal changes, but mere logic and facts couldn't sway Sun's hype-spinners .] Did you ask the prof *why* he took off for error checking? Did you ask him *why* comments are bad? I find that asking such questions (not necessarily during class) generally clarifies such things. If I were to play devil's advocate, I'd say you shouldn't have error checking because you should do the right thing with any input, and you shouldn't have comments because your code should be so clear it doesn't need comments, but I suspect your prof is just being stupid. But *you* will never distinguish between a stupid prof and a prof who communicates poorly unless you ask why. > version, short description, that's it. It's not all us, it's our > teachers, who are just about 80 years old, and want us to follow > exactly what they did. Well, none of this was around 80 years ago. :-) *-*-* As an aside, here's some hints for GREAT C: Don't cast things to incompatible types, even if it works and is much easier. Don't do tricks, even if it works and is much easier. Don't index off arrays on purpose (trust me, you'll do it accidentally often enough). Learn what "assert()" does and use it frequently. Check *every* array access and make sure it's in bounds; doing so visually is enough in most cases, but *think* about it every time you write an array index expression. The same with pointer indirections. Understand the difference between globals and externs, between definitions and declarations. Worry about efficiency last. Allocate memory and deallocate that memory in the same function, or in a pair of functions that are always called from the same function. (Memory allocations and running off the ends of arrays are probably the most common problems. Fouling up declarations is probably second, but easier to figure out and easier to learn a style that prevents it.) Finally, write programs. All kinds of programs. File filters, GUIs, terminal emulators, servers, clients, file floggers, number crunchers, etc. By the time you're really good at C, C will be like COBOL: Everyone will use it, nobody will want to. :-) My $0.005. -- Darren New / Senior Software Architect / First Virtual Holdings Inc http://www.fv.com or info@fv.com -=|=- PGP Key: ftp://ftp.fv.com/pub/fv Fingerprint: 61 7D AF 9E 00 CC C2 ED / D8 4C D7 AA E4 C2 A0 73