gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (01/17/90)
In article <252@usblues.UUCP> tom@usblues.UUCP (Tom Markson) writes: >Pascal does the pointer manipulations for you. In pascal, if I wish to change >a "val" parameter to a reference variable all I must do is add var to it's >declaration. In C, I must recode every single occurance of that variable in >the func to a pointer. (from variable to *variable). In short, C places the >burden on the programmer. Of course, the performance implications of "var" are enormous and often not told to Pascal students. "I'm passing this 50k array into a procedure, and, oh, well I don't want to modify it, so I'd better not make it var." Then your stoopid Pascal compiler makes a local copy... I should think most C programmers don't find *var to be much of a burden at all. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
josh@cditi.UUCP (Josh Muskovitz) (01/17/90)
This is a joke, right?
Obviously, none of the "arrays should begin with 1" people have ever done ANY
serious assembly programming for any processor.
Clearly, it is simpler to retrieve the initial element in an array by using
A <- *B
and not
A <- *B(1)
Now, even if you find that difficult to believe, what about that wasted element
you get when the compiler (shudder) forces element 0? Before any flames come
this way, a pre-flame to (implied) you:
Just because the compiler takes care of it for you, doesn't justify
lousy code!
Write some assembly and then have this argument!
Josh Muskovitz
Computer Design, Inc.
josh@uunet!cditi
"Eat your head!"shane@underdog.crd.ge.com (Randall H. Shane) (01/17/90)
In article <1990Jan16.173034.25686@murdoch.acc.Virginia.EDU> gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: ] In article <252@usblues.UUCP> tom@usblues.UUCP (Tom Markson) writes: ] >Pascal does the pointer manipulations for you. In pascal, if I wish to change ] >a "val" parameter to a reference variable all I must do is add var to it's ] >declaration. In C, I must recode every single occurance of that variable in ] >the func to a pointer. (from variable to *variable). In short, C places the ] >burden on the programmer. ] Of course, the performance implications of "var" are enormous and often ] not told to Pascal students. "I'm passing this 50k array into a procedure, ] and, oh, well I don't want to modify it, so I'd better not make it var." ] Then your stoopid Pascal compiler makes a local copy... Of course, the performance implications of 'stoopid' compilers are enormous, and often not told to USENET posters. Stupid compilers exist for most, if not all languages, and the mere existence of stupid compilers is hardly a reason to slam a computer language. Intelligent Pascal compilers, while enforcing the semantics of var and non-var parameters in the program text, for efficiency's sake pass large structures such as arrays by reference in both cases. This efficient implementation is not a contradiction of the programmer's intent, let us note.... C has some advantages over Pascal, but the syntax and semantics of C's parameter passing sure as hell isn't one of them. ] I should think most C programmers don't find *var to be much of a burden ] at all. IMHO, it's one of the small irritations about C that add up over time... There are many advantages to a language that allows you to fiddle around at the lowest levels, but having to worry about the tiniest, most trivial details at every level is irritating. The conjunction of pointer manipulation primitives and var parameter passig is one of the irritating details that should be hidden most of the time. -- Randall Shane [shane@disney.crd.ge.com] "My daughter is being taught that there is no person greater than Lenin. I brought her here so that she could see a man greater than Lenin." -- Russian woman at a memorial service for Andrei Sakharov
gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (01/17/90)
In article <4822@crdgw1.crd.ge.com> shane@underdog.crd.ge.com (Randall H. Shane) writes: > Stupid compilers > exist for most, if not all languages, and the mere existence of stupid > compilers is hardly a reason to slam a computer language. Reality check. This *IS* alt.religion.computers, right? Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
schwartz@cs.psu.edu (Scott Schwartz) (01/17/90)
Greg Lindahl writes: >I should think most C programmers don't find *var to be much of a burden >at all. So much not of a burden that they added reference prameters to C++.
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (01/17/90)
In article <Ca1&o11@cs.psu.edu| schwartz@cs.psu.edu (Scott Schwartz) writes: |Greg Lindahl writes: ||I should think most C programmers don't find *var to be much of a burden ||at all. | |So much not of a burden that they added reference prameters to C++. most C programmers != C++ designer It's quite simple. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
bzs@world.std.com (Barry Shein) (01/17/90)
From: shane@underdog.crd.ge.com (Randall H. Shane) >Of course, the performance implications of 'stoopid' compilers are >enormous, and often not told to USENET posters. Stupid compilers >exist for most, if not all languages, and the mere existence of stupid >compilers is hardly a reason to slam a computer language. Intelligent >Pascal compilers, while enforcing the semantics of var and non-var >parameters in the program text, for efficiency's sake pass large structures >such as arrays by reference in both cases. This efficient implementation >is not a contradiction of the programmer's intent, let us note.... Over the past decade or so, whenever I get into an argument about how dumb Pascal is, the Pascal proponent always informs me of wonderous Pascal compilers which fix the complaint at hand. Everyone knows that Pascal has no initialization syntax. So one is told to just put a lot of assignments in the mainline which has roughly the same effect (roughly because the errors can be different, but we'll leave that be.) If I point out that this can exact a heavy start-up cost (particularly if setting array elements) on every run of the program I am often told: Well, that's just because of stupid compilers, good Pascal compilers recognize these and turn them into the same as C (load-time initialization.) Ok, makes sense, I know compiler internals well enough to know that's possible or at least plausible. One day, after such an argument, I wrote a simple piece of Pascal code and compiled it on several compilers: Unix/Pascal, VMS/Pascal, IBM370/Pascal/VS, (some other 370 Pascal we had), Greenhill, a few others. Examining the generated code in each case revealed that not one of them performed this "optimization", they all did some form of load and store as regular code in the routine. When confronted with this the Pascal proponent could not name a compiler known to perform the claimed optimization and admitted that every one he had used was in my test suite. Swell. I've seen similar claims for Pascal compilers, including a claim that one should handle variable length strings (something Pascal is incapable of) by putting them into single-character linked-lists and the compiler will fix that to be a lot like C (no joke.) So, I ask, exactly which Pascal compiler performs the optimization of hunting down call by value parameters and changing them to call by reference, specifically. If you can produce some sample generated code all the better. Thank you. -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
jb3o+@andrew.cmu.edu (Jon Allen Boone) (01/17/90)
tom@usblues.UUCP (Tom Markson) writes: > In article <5487@udccvax1.acs.udel.EDU> cygnus@vax1.acs.udel.EDU (Marc Cygnus) writes: > > now why in HELL would you want to do that? if it's in C, leave it for > > heaven's sake. if it's in pascal, the algorithm had to be broke too badly > > to make it worth _translating_, so rewrite it! or better yet, if you do > > these kinds of mindless things on a regular basis (and you haven't heard > > of _cross-linking_), write a sed (or perl, or C, or *shudder* pascal) > > programme to convert for you, so you just have to touch up things here > > and there. > > You are a truly stupid person. Aside from the obvious flame involved, what is wrong with his suggestion? It's SOP for a lot of different programmers. Why do you think people are always asking for Pascal->C or C->Pascal or Fortran->C conversions on alt.sources.wanted? > You are wrong; Pascal allows the programmer to specify the upper and lower > bounds of the array. You don't know much Pascal either. Yes, that was one of the reasons i really liked Pascal - i especially love referencing arrays that are indexed by Days of the Week. > Pascal does the pointer manipulations for you. In pascal, if I wish to change > a "val" parameter to a reference variable all I must do is add var to it's > declaration. In C, I must recode every single occurance of that variable in > the func to a pointer. (from variable to *variable). In short, C places the > burden on the programmer. You are partially correct. C does leave a lot more to the programmer in a tradeof on performance which i like a lot. However, C provides these neat things like Macros and header files which alleviate your having to go in and change 4 million references and just change one - something i never learned how to do in pascal, if it's even possible. All in all, i like C better than Pascal, though i would like to be able to run indices from any enumerated type. > That explains everything. I've never take a compiler design course, yet i still can follow your messages (as well as catching a few misrepresentations on your part!) I don't see how that explains anything! Oh, you mean that was another pointless flame? Sorry...my mistake... > -- > Tom Markson > ...!uunet!usblues!tom > ...!cbmvax!amix!blekko!usblues!tom - iain
skrenta@amix.commodore.com (Rich Skrenta) (01/18/90)
In article <684@cditi.UUCP> josh@cditi.UUCP (Josh Muskovitz) writes: > Obviously, none of the "arrays should begin with 1" people have ever done ANY > serious assembly programming for any processor. Why should all the constraints of assembly programming be forced on me when I use a high level language? If I'm using one it's so I can get *away* from assembly and have the compiler take care of some of the details for me. > Now, even if you find that difficult to believe, what about that wasted > element you get when the compiler (shudder) forces element 0? I can't imagine any compiler forcing an element. Only Pascal programmers do that when they switch to C :-) Why won't this work: b data 100 # storage for array b_base equ 1 # starting index of array b_addr equ b - b_base # base address for array Where's the inefficiency? What will go wrong with my pointer arithmetic? Rich
shane@underdog.crd.ge.com (Randall H. Shane) (01/18/90)
In article <1990Jan17.044003.2039@world.std.com> bzs@world.std.com (Barry Shein) writes:
] From: shane@underdog.crd.ge.com (Randall H. Shane)
] >Of course, the performance implications of 'stoopid' compilers are
] >enormous, and often not told to USENET posters. Stupid compilers
] >exist for most, if not all languages, and the mere existence of stupid
] >compilers is hardly a reason to slam a computer language. Intelligent
] >Pascal compilers, while enforcing the semantics of var and non-var
] >parameters in the program text, for efficiency's sake pass large structures
] >such as arrays by reference in both cases. This efficient implementation
] >is not a contradiction of the programmer's intent, let us note....
] Over the past decade or so, whenever I get into an argument about how
] dumb Pascal is, the Pascal proponent always informs me of wonderous
] Pascal compilers which fix the complaint at hand.
Please, don't count me as a Pascal 'proponent' -- that overstates
the situation greatly. I merely stated an area where I thought Pascal,
and by implication, other languages such as Ada with similar semantics in
that area, was superior to C. Saying that C isn't perfect hardly makes
be a Pascal proponent -- I haven't programmed in Pascal in three years.
] Everyone knows that Pascal has no initialization syntax. So one is
] told to just put a lot of assignments in the mainline which has
] roughly the same effect (roughly because the errors can be different,
] but we'll leave that be.)
At least one Pascal compiler I know of (UBC Pascal for the MTS
operating system) had extensions to perform proper initialization, though
I personally found the syntax EXTREMELY clumsy, and almost not worth it.
The lack of a good initialization syntax is a severe disadvantage in Pascal,
I agree.
] If I point out that this can exact a heavy start-up cost (particularly
] if setting array elements) on every run of the program I am often
] told: Well, that's just because of stupid compilers, good Pascal
] compilers recognize these and turn them into the same as C (load-time
] initialization.) Ok, makes sense, I know compiler internals well
] enough to know that's possible or at least plausible.
] One day, after such an argument, I wrote a simple piece of Pascal code
] and compiled it on several compilers: Unix/Pascal, VMS/Pascal,
] IBM370/Pascal/VS, (some other 370 Pascal we had), Greenhill, a few
] others.
] Examining the generated code in each case revealed that not one of
] them performed this "optimization", they all did some form of load and
] store as regular code in the routine. When confronted with this the
] Pascal proponent could not name a compiler known to perform the
] claimed optimization and admitted that every one he had used was in my
] test suite. Swell.
I'd assume that the reason for this is that much more effort
overall is invested in C compilers, and in optimization in C compilers,
than in Pascal compilers -- which is reasonable, since C is greatly
more used than Pascal.
] I've seen similar claims for Pascal compilers, including a claim that
] one should handle variable length strings (something Pascal is
] incapable of) by putting them into single-character linked-lists and
] the compiler will fix that to be a lot like C (no joke.)
THAT claim is a good example of blind ignorance -- I'll have to
file that one.....
] So, I ask, exactly which Pascal compiler performs the optimization of
] hunting down call by value parameters and changing them to call by
] reference, specifically. If you can produce some sample generated code
] all the better.
Well, this is all from memory, since I no longer have access
to a MTS machine, but I believe that it actually converted all
parameters to reference parameters in the compiled code. I can't
produce the generated code to PROVE this, but if I have a chance in
the next few weeks, I'll look up the UBC manual if I still have a copy
and check this out.......
Whether or not I can find a compiler that performs the optimization,
I'm sure of my main point (which I believe is more than a personal prejudice,
but I'm not willing to claim as an Universal Truth :-) which is that
the Pascal style syntax for var-style parameters is preferable and superior
to C's syntax.
-- Randall Shane [shane@disney.crd.ge.com]
"C combines the power and flexibility of assembly language with
the ease of use of assembly language."bzs@world.std.com (Barry Shein) (01/18/90)
From: shane@underdog.crd.ge.com (Randall H. Shane) > At least one Pascal compiler I know of (UBC Pascal for the MTS >operating system) had extensions to perform proper initialization, though >I personally found the syntax EXTREMELY clumsy, and almost not worth it. >The lack of a good initialization syntax is a severe disadvantage in Pascal, >I agree. (note: Randall's note is very well reasoned, we don't disagree, just chit-chat.) So is the fact that the *other* answer to every complaint is "there exists a compiler with a magic extension to do that". No wonder the language never caught on. I remember when we switched from one 370 Pascal to another and no one's programs would recompile without massive rework due to all the extensions people had relied on. All Pascal compiler suffer from this because no one can use the actual, standardized language. At least C is standardized and it's very odd to get a program which compiles syntactically under one not to compile under another compiler. And when you do one of them is almost always a rogue compiler that should be shot (i.e. added gratuitous extensions that no one needed other than some loser in marketing.) > Well, this is all from memory, since I no longer have access >to a MTS machine, but I believe that it actually converted all >parameters to reference parameters in the compiled code. I can't >produce the generated code to PROVE this, but if I have a chance in >the next few weeks, I'll look up the UBC manual if I still have a copy >and check this out....... Hmm, if it really did that that would be a bug, no. It means that things I *expected* to be copied (and, hence, unchanged by modifying them in the called routine) might now be changed on return. Ah, poor Blaise. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
shane@underdog.crd.ge.com (Randall H. Shane) (01/18/90)
In article <1990Jan18.034728.8696@world.std.com> bzs@world.std.com (Barry Shein) writes:
] From: shane@underdog.crd.ge.com (Randall H. Shane)
] > At least one Pascal compiler I know of (UBC Pascal for the MTS
] >operating system) had extensions to perform proper initialization, though
] >I personally found the syntax EXTREMELY clumsy, and almost not worth it.
] >The lack of a good initialization syntax is a severe disadvantage in Pascal,
] >I agree.
] (note: Randall's note is very well reasoned, we don't disagree, just
] chit-chat.)
Thanks!!
] So is the fact that the *other* answer to every complaint is "there
] exists a compiler with a magic extension to do that".
] No wonder the language never caught on. I remember when we switched
] from one 370 Pascal to another and no one's programs would recompile
] without massive rework due to all the extensions people had relied on.
That's why I gave up on Pascal...When RPI, an MTS site, installed
the IBM Pascal VS compiler as an eventual replacement for the UBC Pascal
compiler, it screwed up things for quite some time. Yecch. (I was a
student consultant for the ocmputer center at the time, it was reasonably
hellish.)
The only two places that Pascal still is flourishing is in the
IBM/Clone PC world (where Turbo is a good compiler, and preferable to many
of the C's I've used on the machine, but its extensions mean that portability
is tossed out the window), and in the academic community, where it will
probably not die off until the people teaching it do.
Y'know, there is a place for a good teaching procedural language --
one with a reasonable standard functionality like C with its standard
libraries, but with a simpler syntax, less direct exposure to the assembly
language level, and less opportunity for students to slice themselves.
Like Pascal should have been, I guess.
] All Pascal compilers suffer from this because no one can use the
] actual, standardized language.
Except Wirth, it seems, and the writers of Pascal textbooks. :-)
] At least C is standardized and it's very odd to get a program which
] compiles syntactically under one not to compile under another
] compiler. And when you do one of them is almost always a rogue
] compiler that should be shot (i.e. added gratuitous extensions that no
] one needed other than some loser in marketing.)
True. Portability problems in C programs are almost never caused
by syntax differences, thank Ghod, they're usually caused by reasonable
things like machine differences, and the inability of people to agree
on how big an 'int' is.
] > <I talk about a compiler that converted all parameters to references>
] Hmm, if it really did that that would be a bug, no. It means that
] things I *expected* to be copied (and, hence, unchanged by modifying
] them in the called routine) might now be changed on return.
I thought Pascal disallowed changes to non-var parameters, but
since I'm working from memory at this point, I could be wrong (and
most probably am, considering the number of Email messages I've received
about this.....).
-- Randall Shane [shane@disney.crd.ge.com]
These opinions are mine, and not intended to imply that GE
approves of them. I'm not even sure if GE knows I have opinions.thant@horus.esd.sgi.com (Thant Tessman) (01/19/90)
Pascal sucks, Fortran sucks, COBOL really sucks, even C sucks. In C++ you can do ANYTHING. C++ is GOD (and the DEVIL). thant "just sign in blood on the dotted line"
bzs@world.std.com (Barry Shein) (01/19/90)
From: shane@underdog.crd.ge.com (Randall H. Shane) > Y'know, there is a place for a good teaching procedural language -- >one with a reasonable standard functionality like C with its standard >libraries, but with a simpler syntax, less direct exposure to the assembly >language level, and less opportunity for students to slice themselves. >Like Pascal should have been, I guess. Actually, I disagree. First, I've taught programming at various levels for about a decade. I've taught courses using, lessee, C, Pascal, PL/I and IBM/370 Assembler and even "If It's Tuesday This Must Be Cobol" (i.e. Survey Of Programming Languages, add Lisp, Snobol, Cobol, Algol, Fortran and a few others to the above list, fun course.) I don't think it's a good idea to teach in a "teaching language", far better to think hard and subset a "real" language. When I taught C people would always say "ugh, how do you get them past all that complicated pointer syntax?! What an awful language to teach in!" Well, the answer was of course I simply didn't cover pointers until they were ready to learn pointers. I also never had as much trouble with teaching pointers as some of my colleagues seemed to. I suspect this was at least partially due to the fact that I understood them and had put a lot of thought into how to explain them. I usually started with some amusing "confusion between the thing and the thing contained" stories, like when in the news they report that "The White House said today..." they don't mean The White House at all because it cannot talk, they mean the contents of the white house. Most of the problems people have with pointers has a lot to do with that sort of sloppiness in our natural languages (not that it's a problem in natural languages, context saves the day there, but we are accustomed to using a location to describe its contents as if they were interchangeable.) But I digress. Pascal was initially designed to be a teaching language and it shows. One of the design goals of the language was merely to be able to write a one-pass compiler so students wouldn't use so much CPU time recompiling, back in a day when compiling was a very dear activity. It's amusing to think that one can design a language that is both lightweight on the CPU and easy to learn. Those goals seem terribly at odds to say the least! BASIC suffers from the same problem (C doesn't only because no one ever claimed it was particularly easy to learn, it just is because it's a rather clean design, not because that was the motivation of the designer especially.) The whole idea of packed data comes from the odd word size and word-addressibility of the B6600 Pascal was first designed for. I am forever amused at the explanations students have been given for this feature (umm, it's, uh, well, packed, lessee, ah!, more memory efficient! yeah, must be that...hah! Well, true on some ancient machines, but not usually the machine being used.) The lack of external linkage in the standard language is truly quaint and heralds from an era when linking several source modules on most operating systems was a heroic feat (hence, no one needed that for teaching.) Ever notice that in order to attain portability Knuth's TeX (which is written in Web which is translated to Pascal) produces one 10,000+ line source file? Not exactly my idea of software engineering. Unfortunately, so many people were taught Pascal (particularly around engineering schools who felt they had to move away from Fortran even by the late 70's) that a market developed for letting them continue to program in Pascal in their professional careers. Since these students had grown up now and Pascal was clearly inadequate to do much anything the vendors responded by extending Pascal in an effort to capture market. So Pascal mutated into at least 50 different dialects, probably more, each usually quite incompatible. Adding a syntax for variable-length string types is not minor surgery! It was all a mistake and most so-called proponents are usually victims of that mistake trying to rationalize the situation they are in. I haven't met too many folks, who know several languages well, and consider Pascal very good. It's passable for little projects, perhaps less than 1,000 lines of code, but utterly unmanageable beyond that and truly awful for any projects that require significant interface to system libraries (again, in its standard form, once you extend it then the word "Pascal" is merely a marketing tool, if the FDA were in charge of programming languages they'd forbid those languages from being called "Pascal", "Pascal-like" perhaps.) -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
KARLJ@kuhub.cc.ukans.edu (01/20/90)
In article <1990Jan16.173034.25686@murdoch.acc.Virginia.EDU>, gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: > > Of course, the performance implications of "var" are enormous and often > not told to Pascal students. "I'm passing this 50k array into a procedure, > and, oh, well I don't want to modify it, so I'd better not make it var." > Then your stoopid Pascal compiler makes a local copy... > This is so very true! The same thing can be said about global variables. Often, instructors will tell their students to never use globals. Instead, they have them pass the globals into a procedure as a val parameter. In the same vain, they tell students to only pass variables in as var only if a change is to be made. It would seem to be more prudent to inform students of exactly what happens when a variable is passed and urge extreme caution; however, I don't get to make the rules. > > Greg Lindahl > gl8f@virginia.edu Astrophysicists for Choice. karl smith karlj@kuhub.cc.ukans.edu "But before I rise, man, why not roll still another one, to make sure I'm really stoned, because sometimes, man, in my condition, it is hard to tell." Horse Badorties _The Fan Man_ by William Kotzwinkle