breuel@harvard.ARPA (Thomas M. Breuel) (01/06/85)
The fact that PASCAL has clear semantics and consistent syntax makes it very usable for 'Programming 101'. The fact that PASCAL has also a rich set of data structures and rudimentary mechanisms for modular program design allows it to be used for system's programming as well. The language definition by Jensen&Wirth leaves extensions for integration into a host environment unspecified (although an example is given). All implementations that I have encountered (except for Berkley/UN*X 'pc') provide such extensions, and with them PASCAL is an excellent tool for system's programming. Calling it a 'toy' language is completely unjustified. 'C', on the other hand, is a usable, although a bit outdated, workhorse for architectures very similar to the PDP, VAX, or 68000. Unfortunately, 'C' can be adapted only with great difficulties to other architectures, like the Cyber 173, the DEC-20, &c. (not to be misunderstood, 'C' compilers for these machines exists, it is just that practically no program that Joe Random Hacker produces on a VAX will run on them unaltered). Other problems of the language include that its syntax appears convoluted or counter-intuitive to many people (e.g. "return (fun)(*(fun)rtoi(cdr(def)))();" ), and that 'C' is hard to optimise or adapt to parallel execution. I don't want to start another PASCAL vs. 'C' debate here. Which language you prefer depends mostly on your taste (both of them are Turing equivalent :-). Thomas. breuel@harvard.
henry@utzoo.UUCP (Henry Spencer) (01/08/85)
> ... Unfortunately, 'C' can be adapted only with great difficulties > to other architectures, like the Cyber 173, the DEC-20, &c. (not to be > misunderstood, 'C' compilers for these machines exists, it is just that > practically no program that Joe Random Hacker produces on a VAX will > run on them unaltered). Actually, practically no program that Joe Random Hacker produces on a VAX will run on a PDP11 unaltered... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gadfly@ihu1m.UUCP (Gadfly) (01/09/85)
--
Perhaps the nicest (in the sense of clean) thing about PASCAL
is the way it bifurcates the universe of objects into pointers
and pointees. It is thus easier to debug monster programs
with monster data structures than is the case with C. Actually,
all PASCAL needs to be a superior systems language to C is a
casting operator, assuming the compiler knows how to optimize
programming constructs like sequential array references.
I can do without the demented precedence of logical operators,
though.
--
*** ***
JE MAINTIENDRAI ***** *****
****** ****** 08 Jan 85 [19 Nivose An CXCIII]
ken perlow ***** *****
(312)979-7188 ** ** ** **
..ihnp4!iwsl8!ken *** ***ellis@spar.UUCP (Michael Ellis) (01/10/85)
From Ken Perlow: >-- >Actually, all PASCAL needs to be a superior systems language to C is a >casting operator, assuming the compiler knows how to optimize >programming constructs like sequential array references. My experience implementing a filesystem in PASCAL was surprisingly positive given the bias I held toward C at the time. The only deviation from Jensen-Wirth's standard required to transform PASCAL from a toy into a credible language is separately compilable modules. Casting operators can then be written in PASCAL as functions which blindly return whatever is passed to them (the assumption here is that type-checking is ineffective across compilations). Such functions also serve the purpose of C's `&' operator. One still must code assembly routines in order to escape PASCAL's detestable (that word is too mild!) I/O `philosophy'; again, separately compilable modules provide this avenue. The features of PASCAL I miss most when programming in `C' are: 1) The debugging power of PASCAL's subrange types. 2) Notational consistency, especially with structures, arrays and pointers. It's unfortunate that C is irrevocably brain-damaged by the lack of coherence and clarity as regards item (2). -michael ellis
ron@brl-tgr.ARPA (Ron Natalie <ron>) (01/10/85)
> > ... Unfortunately, 'C' can be adapted only with great difficulties > > to other architectures, like the Cyber 173, the DEC-20, &c. (not to be > > misunderstood, 'C' compilers for these machines exists, it is just that > > practically no program that Joe Random Hacker produces on a VAX will > > run on them unaltered). > > Actually, practically no program that Joe Random Hacker produces on a > VAX will run on a PDP11 unaltered... > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Nobody ever claimed C guarantees that you will your code to portable, but only that it allows you to write portable code. The thing that makes C so appealing for system programming is that it allows you to break the rules. Systems Programmers do not necessarily want to do things in a portable or even structured manner. They should be of a level of skill that they know enough to be careful when using the questionable features of the language. -Ron
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/12/85)
> 2) Notational consistency, especially with structures, arrays and pointers. > > It's unfortunate that C is irrevocably brain-damaged by the lack of > coherence and clarity as regards item (2). How about explaining what you mean. If you're referring to the equivalence of *(p + i) and p[i] then I have to disagree. Otherwise, what notational inconsistency? Structs (unions), arrays, and pointers are not the same things so what consistency are you asking for??