rat@madnix.UUCP (David Douthitt) (01/06/91)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: | | >Given how universities are pushing "modular" code these days, and the | >amount of people writing *tiny* subroutines | | That's really sad. Has everybody forgotten the original reasons for inline() | and parametric defines? They can't be THAT anal retentive about modularity. Please explain further what you mean here - WITHOUT getting salty. Have you ever see a FORTH programmer's C code? Subroutines everywhere. Personally, I don't see how that is so bad - except that C function calls might have abominable execution time overhead. Tsk tsk - shoulda used FORTH :-) -- ! InterNet: deety!rat@spool.cs.wisc.edu ! David Douthitt ! UUCP: ...uwvax!astroatc!nicmad!madnix!deety!rat ! Madison, Wisconsin ! {decvax!att}! ! === Apple II Forever === ! Home of Mad Apple Forth and the Tiger Toolbox ! The Stainless Steel Rat
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/07/91)
rat@madnix.UUCP (David Douthitt) writes: >| >Given how universities are pushing "modular" code these days, and the >| >amount of people writing *tiny* subroutines >| That's really sad. Has everybody forgotten the original reasons for inline() >| and parametric defines? They can't be THAT anal retentive about modularity. >Please explain further what you mean here - WITHOUT getting salty. What I am talking about is that subroutine overhead and dealing with it when it's large is an old problem in computer science. I simply can't believe that colleges today are actually training people to modularize their code to death without also explaining performance considerations and how they can be dealt with: inline specifiers, which generate explicit code from functions; and parametric defines, which generate explicit code via macro replacement. >Have you ever see a FORTH programmer's C code? Subroutines everywhere. >Personally, I don't see how that is so bad - except that C function calls >might have abominable execution time overhead. Tsk tsk - shoulda used >FORTH :-) You're right -- shoulda used FORTH, if that's what you know. Such a person is still programming in FORTH most of the time but is mentally translating from FORTH semantics to C. When I first got started in Pascal (a short and very discouraging experience) I tried to keep programming as if I were using Basic. Needless to say, nothing worked. I turned to assembly; soon I found that projects of any reasonable size required modular organization just so I could keep track of them. By the time I decided to learn C, I welcomed the idea of an efficient language with the minimum amount of pascal-style progam block structure (necessary for manageable programs) and the semantics (often more compactly expressed) of both assembly and basic -- when each was appropriate. The ANSI changes (especially prototyping) deal with nearly everything I could have wanted changed in C. The structure of a programming language cannot help but dictate to some extent the programming styles which will tend to produce efficient/coherent/correct results in that language. I just can't see a CS curriculum that doesn't at least address the question of 'which language for the job?'. Todd Whitesel toddpw @ tybalt.caltech.edu