dillon@ucbvax.ARPA (The Sherif "Matt D.") (01/30/85)
The problem I see between Pascal and C is not that Pascal is so much worse than C (It is), But that many of us are forced to use languages we don't like just because So and So over that'a'way used Fortran all his life. I don't mind Pascal as long as I don't have to program in it. One reason new (and better) languages are not catching on as quickly is due to the latter cause. I take as fact that better languages are comming out these days and days to come, and as soon as I can get my hands on them, I'll check them out. But people have different preferences, so one language may suit them better than another. For instance, I cannot stand the Apple MAC, because it does not allow me enough freedom with the computer. Incidently, this is why I don't like Pascal. One argument against C that I have heard A LOT is that it isn't structured or that it's hard to program readable code in C. This is a bunch of B*LL. The fact is that who-ever said that either does not or has not programmed in C, or saw a bunch of Joe-Code by some-one-else who wasn't a very good programmer. The general objection to Pascal by C programmers is that it is not powerfull enough, or fast enough. Alternatively, Pascal programmers see C as such a change, that it's unreadable to them. My opinion on Pascal (And this may inspire a mail war), is that it is a subset of C, period.
g-frank@gumby.UUCP (02/01/85)
> For instance, I cannot > stand the Apple MAC, because it does not allow me enough freedom with > the computer. Incidently, this is why I don't like Pascal. > If you want greater freedom, try Modula-2 or Ada. In the case of Modula-2, the designers basically said, "we could probably give enormous power to the programmer without sacrificing structure, but that would require a larger, slower language than we would like. Therefore, we will create a structured language with explicit, system-dependent escapes, to be used only when necessary." With Ada, obviously the other tack was taken. Strong typing and structure is only bad when it prevents you from doing something in a reasonable way (the very legitimate complaint about ISO Pascal). If there are escapes, or if the structure is VERY powerful, there's no good argument against it, since your freedom is not threatened, and you get all the benefits without the "walls." > One argument against C that I have heard A LOT is that it isn't > structured or that it's hard to program readable code in C. This is a > bunch of B*LL. The fact is that who-ever said that either does not > or has not programmed in C, or saw a bunch of Joe-Code by some-one-else > who wasn't a very good programmer. > C is structured. C is NOT strongly typed, and it is easier than most languages to write cryptic code in. It is also possible to write nice looking, readable code in. My personal problem with C is that it does not encourage clear thinking and careful planning in those who need the most encouragement, and that I, an experienced programmer who HAS worked extensively in C, have trouble debugging large systems written in the language. Sorry. I know at least two other people in the world besides myself who aren't perfect, and all three of us like some help from our language. > The general objection to Pascal by C programmers is that it is > not powerfull enough, or fast enough. Alternatively, Pascal programmers > see C as such a change, that it's unreadable to them. > > My opinion on Pascal (And this may inspire a mail war), is that > it is a subset of C, period. Can I ask a BIG favor? Can at least ONE of the other people in this newsgroup PLEASE read a book on Modula-2, so that we can stop this "I think C is better than being slapped in the face with a dead jellyfish" discussion? Or is my contention true, that C hackers have calcified brains and no longer read books? -- Dan Frank "good news is just life's way of keeping you off balance."
friesen@psivax.UUCP (Stanley Friesen) (02/04/85)
In article <268@gumby.UUCP> g-frank@gumby.UUCP writes: > >Can I ask a BIG favor? Can at least ONE of the other people in this >newsgroup PLEASE read a book on Modula-2, so that we can stop this >"I think C is better than being slapped in the face with a dead >jellyfish" discussion? Or is my contention true, that C hackers have >calcified brains and no longer read books? > > I just read Wirth's book on Modula-2 this weekend. It seems to me to be a superset of Pascal, with some *nice* extensions. But it is missing a couple of important things.. With all his talk about the importance of data hiding and locality, he did not include local statics. To get a static variable it must be global! This is significant lack, I use local statics regularly for internal state variables, which is what they are for. I also do not seem to remember any facility for type casting or its equivalent, very useful for general purpose routines and record type. -- Sarima (Stanley Friesen) {trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen or quad1!psivax!friesen
g-frank@gumby.UUCP (02/07/85)
> With all his talk about > the importance of data hiding and locality, he did not include local > statics. To get a static variable it must be global! This is significant > lack, I use local statics regularly for internal state variables, which > is what they are for. I also do not seem to remember any facility > for type casting or its equivalent, very useful for general purpose > routines and record type. > -- Modules are intended to allow hiding of what you would call local statics. You just make a module small enough that state information is reasonably kept in its private global variables without violating scoping rules. This doesn't always work, but most of the time it is reasonable. Any type, including user-defined ones, may be cast to by taking its name as though it were a function call, as in CARDINAL (myvar) or SuperType (somevar) -- Dan Frank "good news is just life's way of keeping you off balance."
bsa@ncoast.UUCP (Brandon Allbery) (02/08/85)
Pascal has two major problems: (1) it was designed as a *teaching* language, and (2) it was designed for batch systems -- the "PROGRAM FOOBIE(INPUT, OUTPUT, BLETCH);" was intended to be linked to a file name via the CDC version of a "DD" statement. I think Pascal is great when used as intended. I wish I could get my hands on Modula for either my TRS-80 Model I or for our Unix system, though; *that* language was designed for real world applications. If anyone should be flamed for Pascal's unsuitability, it's the people who first took it out of its intended environment. Brandon (bsa@ncoast.UUCP) -- Brandon Allbery, decvax!cwruecmp!ncoast!bsa, "ncoast!bsa"@case.csnet (etc.) 6504 Chestnut Road, Independence, Ohio 44131 +1 216 524 1416 (or what have you)
cca@pur-phy.UUCP (Allen) (02/08/85)
> ... With all his talk about > the importance of data hiding and locality, he did not include local > statics. To get a static variable it must be global! This is significant > lack, I use local statics regularly for internal state variables, which > is what they are for. I also do not seem to remember any facility > for type casting or its equivalent, very useful for general purpose > routines and record type. Let's make sure we get the definitions straight here. For a variable to be "static" it must be declared in a module (i.e. not a procedure). Hence it is "global" to the module. It is NOT visible to the outside world unless it is explicitly exported. Declaring a variable in the implementation part of a module is equivalent to declaring it to be a static variable in a C file. If you want even more restriction on where it's visible, you can tuck it away in a local module. Type casting most definitely IS included. Any variable may be cast to another type OF THE SAME SIZE as follows: TYPE aType1 : ... (* whatever *) aType2 : ... (* whatever *) VAR aVar1 : aType1 ; aVar2 : aType2 ; BEGIN ... aVar2 := aType2(aVar1) ; ... For types not of the same size this doesn't work. For enumerated types, the portable thing to do is to use VAL and ORD (CHR for chars if you want). Charlie Allen cca@pur-phy
g-frank@gumby.UUCP (02/11/85)
> I wish I could get my > hands on Modula for either my TRS-80 Model I or for our Unix system, > though; *that* language was designed for real world applications. > I'm not sure, but some time ago Springer-Verlag sent me literature announcing Modula-2 for a number of machines, including ones that run CP/M. Does the TRS-80 run CP/M (or can it)? You might try contacting S-V and asking if they have something for the Model I. -- Dan Frank "good news is just life's way of keeping you off balance."
mauney@ncsu.UUCP (Jon Mauney) (02/11/85)
> Pascal has two major problems: (1) it was designed as a *teaching* language, > and (2) it was designed for batch systems -- the "PROGRAM FOOBIE(INPUT, > OUTPUT, BLETCH);" was intended to be linked to a file name via the CDC > version of a "DD" statement. Fortunately, C is clearly intended for interactive systems, and no-one would ever see a connection between stdin/stdout and SYSIN/SYSOUT. Of the many flaws in Pascal, ordinary I/O is not one. There is nothing preventing good interactive execution of Pascal programs. -- *** REPLACE THIS LINE WITH YOUR SIGNATURE *** Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University
ndiamond@watdaisy.UUCP (Norman Diamond) (02/11/85)
> Pascal has two major problems: (1) it was designed as a *teaching* language, > ... > If anyone should be flamed for Pascal's unsuitability, it's the people > who first took it out of its intended environment. > -- Brandon Allbery Unix and C were originally unavailable, and then became available only on educational licences, and then.... So, let's flame the people who took these out of their former environments too, especially when many flaws remained. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
robert@gitpyr.UUCP (Robert Viduya) (02/14/85)
>< Posted from mauney@ncsu.UUCP (Jon Mauney) > Pascal has two major problems: (1) it was designed as a *teaching* language, > > and (2) it was designed for batch systems -- the "PROGRAM FOOBIE(INPUT, > OUTPUT, BLETCH);" was intended to be linked to a file name via the CDC > version of a "DD" statement. > CDC version of a "DD" statement? I've used Pascal under NOS (one of CDC's operating systems) and it isn't necessary to use CDC's version of the "DD" statement. In your example, the command "FOOBIE,INFILE,OUTFILE,BLFILE." will execute the program with INFILE assigned to INPUT, OUTFILE assigned to OUTPUT and BLFILE assigned to BLETCH (assuming the program binary was in a file called FOOBIE). By the way, CDC's version of IBM's "DD" statement is "ASSIGN". It's also much easier to use (but then, that isn't saying much). robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
jim@hpfcla.UUCP (jim) (02/15/85)
I program in both C and Modula-2. Which is better? Well, the combination of strong typing and the ability to also breach the strong typing is certainly nice in Modula-2. But I miss my favorite C expressions like: while ((c=getmeach())==' ') and so on. But, I am very fond of MODULEs in Modula-2. And, oh yes, I HATE (read, "H*A*T*E") typing my keywords in uppercase.
mwm@ucbtopaz.CC.Berkeley.ARPA (02/17/85)
In article <2793@ncsu.UUCP> mauney@ncsu.UUCP (Jon Mauney) writes: >Of the many flaws in Pascal, ordinary I/O is not one. There is nothing >preventing good interactive execution of Pascal programs. >Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University Except (staying within the semantics of J&W, of course!): 1) Getting read/write to work as expected on an interactive system. I've heard that it can be done right while still maintaining the J&W semantics, but have never seen it so done. 2) Doing the *exact* equivalent of printf("Gimme data: "); with the cursor left at the end of the line. <mike
mauney@ncsu.UUCP (Jon Mauney) (02/18/85)
I say: >> Of the many flaws in Pascal, ordinary I/O is not one. There is nothing >> preventing good interactive execution of Pascal programs. <mike says > Except (staying within the semantics of J&W, of course!): > > 1) Getting read/write to work as expected on an interactive system. I've > heard that it can be done right while still maintaining the J&W semantics, > but have never seen it so done. > > 2) Doing the *exact* equivalent of printf("Gimme data: "); with the > cursor left at the end of the line. The trick is to do lazy evaluation on input, and to be careful how you buffer the output. The definition of I/O in J&W is very simple, concerning itself with contents of the file pointer and the values of the eof and eoln flags. Despite what the implementers of UCSD Pascal seem to think, it is not necessary to get the next input character until the code actually tries to use it. Berkeley's Pascal compiler does lazy evalution of input, and it works just fine; about the same as C, in fact. As for write('Gimme The Ax: '); J&W say nothing about buffering the output, so there is nothing to prevent write statements from having an immediate effect. I have written interactive programs in Pascal, and they conform to a reasonable interpretation of Jensen and Wirth. -- *** REPLACE THIS LINE WITH YOUR SIGNATURE *** Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University
g-frank@gumby.UUCP (02/27/85)
> I program in both C and Modula-2. Which is better? Well, the combination > of strong typing and the ability to also breach the strong typing is > certainly nice in Modula-2. But I miss my favorite C expressions like: > > while ((c=getmeach())==' ') > I miss this too. On the other hand, what comes with letting a statement be an rvalue is that if (c = 10) printf ("You blew it!\n") ; compiles just fine, and is very hard to find. > and so on. But, I am very fond of MODULEs in Modula-2. And, oh yes, > I HATE (read, "H*A*T*E") typing my keywords in uppercase. Absolutely. The effect is to make all Modula-2 programs look like ransom notes. I wish some of the compiler vendors would supply a compile- time switch to let us type the keywords in whatever case we wanted. -- Dan Frank Q: What's the difference between an Apple MacIntosh and an Etch-A-Sketch? A: You don't have to shake the Mac to clear the screen.
ndiamond@watdaisy.UUCP (Norman Diamond) (02/28/85)
> I HATE (read, "H*A*T*E") typing my keywords in uppercase.
I hate (H*A*T*E) EVER being told what case to use for words.
A programming style that is dependent on the compiler is just as
bad as code itself that is dependent on the machine & compiler.
Library function calls are NOT an exception.
^^^
---------------------------^
Syntax error, this editor only accepts leading "_" to show emphasis. :^\
--
Norman Diamond
UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa
"Opinions are those of the keyboard, and do not reflect on me or higher-ups."robertd@tektronix.UUCP (Bob Dietrich) (03/05/85)
> > Of course this is by no means the only problem with Pascal's I/O. Other > major ones include: > - no random access > - no way to open a file with a specified name from with the program. > reset(input,'foo') is an extension. It is not in the standard. > - no I/O of enumerated types (nor input of Booleans) > - the representation of files other than text is not defined. This > means that you can't write records onto a tape and expect to > read the tape on a different system. > I have never seen a program that I needed to write that could be written > in standard Pascal. General comment: Good article, Charles. I guess I'm not certain what sorts of programs you need to write, although having seen (and used) your systems programming extensions to the DEC-10 compiler, I have my suspicions. If, indeed, you want to do very environment- specific things in "standard" Pascal, and cannot do so, I'm not surprised. A standard should be implementable on a broad variety machines, and fails if what it specifies cannot be implemented. From where I sit (at my micro- programmable PERQ), I have access to one or more of the following machines, using Pascal: CDC Cyber, DEC-10, DEC-20, DEC VAX, IBM 3080, Motorola 68000, Intel 8086, National 32000, and a few others. There's more than one OS available for several of these. However, there's not much either the hardware or the various OS's agree upon in a consistent manner. As far as the problems you cite, JPC has approved Candidate Extensions for the first two items. The second two pose problems of definition and semantics. I/O of enumerated types has been suggested, but no one has taken the time or effort to try and define what this really means. It certainly poses additional problems for error recovery on user input mistakes. I'm not sure what you mean when you say that the representation of files other than text is not defined. The closest thing textfiles have defined as far as representation goes is that they are sequences of characters broken into lines. Nothing is specified about character set, length of lines, representation of the line marker, etc., in keeping with the separation of the language from its implementation. What would you want for any file? Do you want character values specified as EBCDIC? ASCII? Do you want a standard to require files of records to be aligned on 8-bit boundaries (on a DEC-10/20 with 36-bit words?) ? I feel I'm not understanding your point. I am very much in favor of portability, but specifying a language so that it can be implemented on a wide variety of machine/OS combinations is difficult. Bob Dietrich Tektronix, Inc. (503) 629-1727 {ucb or dec}vax!tektronix!robertd uucp address robertd@tektronix csnet address robertd.tektronix@rand-relay arpa address