breuel@harvard.ARPA (Thomas M. Breuel) (01/11/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. | |I've always thought that was one of its most *broken* features. |This bifurcation is ridiculous in the light of such C objects |as pointers to pointers. I don't know what you are talking about. PASCAL has a superset of the data structures available in 'C'. In particular, you can get pointers to pointers. You can even define a type 'TYPE foo= ^foo;' which is impossible in 'C'. |> It is thus easier to debug monster programs |>with monster data structures than is the case with C. | |Exactly contrary to my experience with ~1000 line programs. |(Not really monsters, but large enough for comparison |purposes...) Perhaps that would change if you worked with PASCAL a bit more? You may find that it indeed is not a bad language for debugging. The current state of the UN*X kernel (ever looked at namei or ever wondered where all these unreferenced inodes come from) and the UN*X utilities ("My sendmail has a bug!") seem to indicate that 'C' is not that easy to debug either. |> Actually, |>all PASCAL needs to be a superior systems language to C is a |>casting operator, | |No pointer arithmetic? Or ability to take the address of a static |object? ACK! The ability to have static headers for linked-lists |in dynamic storage is one of the things I miss most in Pascal. Indeed, no pointer arithmetic. Using arrays and indices instead is a lot more portable and gives the compiler a lot more freedom for optimisation and adaptation to strange architectures. Basically the same is true for getting the address of a static object. If you are used to it, you won't find it any less convenient than pointer arithmetic. You may also discover that it helps avoid traps and pitfalls. |>assuming the compiler knows how to optimize |>programming constructs like sequential array references. | |I prefer a minimum of magic (like global optimizations; these |are an invitation to the compiler to mysteriously break programs). Working compilers don't break correct programs. I prefer a maximum of optimisation, and if 'magic' is involved, I couldn't care less. If you, on the other hand, rely on certain 'features' of the compiler (e.g. sequential allocation of static data &c), then you should not complain if you don't get what you expected. PASCAL is written such that the compiler has a lot of freedom in optimising the code. 'C' code, on the other hand, is very hard to optimise, just because 'C' allows you to do funny things like get a pointer to any variable anywhere &c. |>I can do without the demented precedence of logical operators, |>though. | |Plus the fact that short-circuit evaluation is not required... [I'm not even sure that it would be permitted to happen..., I'll have to look at Jensen&Wirth] So what? Why does the whole world have to look like '&&' and '||'? Use 'IF' instead, it might even come out more readable. Thomas. breuel@harvard
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/11/85)
> ... The current state of the UN*X kernel (ever looked at namei or ever > wondered where all these unreferenced inodes come from) and the UN*X > utilities ("My sendmail has a bug!") seem to indicate that 'C' is not > that easy to debug either. This argument is totally bogus. You can't prove anything about the relative merit of two languages by pointing at bad examples of either. (Not to imply that UNIX is all that bad.) By the way, what unreferenced inodes? I never noticed that problem.. > Indeed, no pointer arithmetic. Using arrays and indices instead is a > lot more portable ... There is nothing unportable about C pointers that are used in accordance with the language rules. C's convenient pointers are one of its significant advantages for implementing systems efficiently. > PASCAL is written such that the compiler has a lot of freedom in > optimising the code. 'C' code, on the other hand, is very hard to > optimise, just because 'C' allows you to do funny things like get a > pointer to any variable anywhere &c. Yes, C was designed to provide that level of control. Traditional optimization is much less important when the language is that close to the machine already. > So what? Why does the whole world have to look like '&&' and '||'? > Use 'IF' instead, it might even come out more readable. Using multiple "if"s is definitely LESS readable and is why && and || were invented in the first place. Using J&W Pascal as a systems implementation language is much like using Small-C or some similar emasculated C subset. Sure, one can do it (with some amount of cheating), but C was deliberately designed to facilitate systems implementation and it is pretty good at that. There are several improvements one would like to see (many of them are in C++), but following the Pascal model is not one of them. I note with disgusted amusement that C is the only significant major language that was not considered in the Ada project.
kjm@ut-ngp.UUCP (Ken Montgomery) (01/12/85)
[] >From: breuel@harvard.ARPA (Thomas M. Breuel) > >|>Perhaps the nicest (in the sense of clean) thing about PASCAL >|>is the way it bifurcates the universe of objects into pointers >|>and pointees. >| >|I've always thought that was one of its most *broken* features. >|This bifurcation is ridiculous in the light of such C objects >|as pointers to pointers. > >I don't know what you are talking about. PASCAL has a superset of the >data structures available in 'C'. In particular, you can get pointers >to pointers. You can even define a type 'TYPE foo= ^foo;' which is >impossible in 'C'. Touche. But you still can't allocate a static object and then create a pointer to it. I consider this to be a serious deficiency. >|> It is thus easier to debug monster programs >|>with monster data structures than is the case with C. >| >|Exactly contrary to my experience with ~1000 line programs. >|(Not really monsters, but large enough for comparison >|purposes...) > >Perhaps that would change if you worked with PASCAL a bit more? You >may find that it indeed is not a bad language for debugging. The >current state of the UN*X kernel (ever looked at namei or ever >wondered where all these unreferenced inodes come from) and the UN*X >utilities ("My sendmail has a bug!") seem to indicate that 'C' is not >that easy to debug either. OS code is not subject to ordinary debugging techniques. (Try Cyber Peripheral Processors some time!) Thus I think that your example (of namei() in UN?X) is suboptimal. Unfortunately, I can't comment any further than that, since the last time I looked at a UN?X kernel was in 1980 (Version 6 with buffer mods). I don't work on UN?X or its utilities now, so I haven't looked at sendmail either. However, C was my language of choice for my fullscreen editor (which I wrote in my spare time). I shudder to think of the amount of nonsense I would have gone through writing in Pascal... >|> Actually, >|>all PASCAL needs to be a superior systems language to C is a >|>casting operator, >| >|No pointer arithmetic? Or ability to take the address of a static >|object? ACK! The ability to have static headers for linked-lists >|in dynamic storage is one of the things I miss most in Pascal. > >Indeed, no pointer arithmetic. Using arrays and indices instead is a Arrays and indices are a pretty poor way to implement linked lists. >lot more portable How so? > and gives the compiler a lot more freedom for >optimisation Compilers should translate code, not second-guess programmers. > and adaptation to strange architectures. Such as? > Basically the same >is true for getting the address of a static object. If you are used to >it, you won't find it any less convenient than pointer arithmetic. You >may also discover that it helps avoid traps and pitfalls. Traps and pitfalls are *my* problem, not the compiler's. But I've not noticed any such problems in addressing static objects in C... >|>assuming the compiler knows how to optimize >|>programming constructs like sequential array references. >| >|I prefer a minimum of magic (like global optimizations; these >|are an invitation to the compiler to mysteriously break programs). > >Working compilers don't break correct programs. I prefer >a maximum of optimisation, and if 'magic' is involved, I couldn't >care less. If you, on the other hand, rely on certain 'features' of >the compiler (e.g. sequential allocation of static data &c), No. I merely want the compiler to translate what I said, not what it thought I meant. > then you >should not complain if you don't get what you expected. My experience has been that I get what I expect more often with C than with any other HLL. >PASCAL is written such that the compiler has a lot of freedom in >optimising the code. 'C' code, on the other hand, is very hard to >optimise, just because 'C' allows you to do funny things like get a >pointer to any variable anywhere &c. If you're talking about global optimizations, I mostly prefer to do them myself (which is why 'register' variables are so nice). >|>I can do without the demented precedence of logical operators, >|>though. >| >|Plus the fact that short-circuit evaluation is not required... > >[I'm not even sure that it would be permitted to happen..., I'll have >to look at Jensen&Wirth] > >So what? Why does the whole world have to look like '&&' and '||'? >Use 'IF' instead, it might even come out more readable. There is no direct way (that I'm aware of...) to represent the semantics of '||' using pure nested 'IF' constructions. (Of course you can always (Horrors! :-)) use 'GOTO'.) I think expressions using '&&' are cleaner, more readable, and more maintainable than equivalent nested 'IF' constructions, in most cases. > Thomas. > breuel@harvard -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cats and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ut-ngp.ARPA [for Arpanauts only]
jack@vu44.UUCP (Jack Jansen) (01/13/85)
Ok, let me throw in my $1E-1 worth of opinion.
I use both Pascal (mainly on a prime and on a cyber) and C (on
unix) a lot, especially for system-programming.
Although I haven't written any kernel stuff in pascal, I did
write things like an uucp-like package, an editor and stuff
like that in it.
Well, what I like most about pascal is that it *works*.
By this, I mean that if a C program takes an hour to write
and a pascal program 2 hours, the pascal program is debugged
in 20 minutes, and the C program in 2 days.
As an example, I wrote a program to read tar tapes on a prime
(in pascal) *yesterday*.
This is exactly what I mean. It took me no more than 8 hours to
write *AND DEBUG* a ~600 line pascal program. (Ok, there's still
ONE bug, it won't extract a file if an intermediate directory
name starts with a digit, but I'll fix that mondaymorning between
11:00 and 11:01 hour:-).
Now, if anyone ever succeeded in accomplishing something like
this in C, I would be very interested. Usually, I find that C programs
of that size (say, 200-1000 lines) take about 1 day per 100 lines
to write.
I have seen this also with friends of mine, so I don't think it
can be influenced by a difference in experience or other personal
factors, I think that pascal, by *forcing* you to define your
data, parameters, etc. correctly points you to a lot of logic errors
(and typing errors), where C will have you addicted to coffee and
tobacco by the time you locate the missing &.
It's a *real* pity, though, that there are no standard ways to do
even mildly funny things (opening a named file, static variables or
other forms of modularization, *any* kind of string handling, etc etc),
and that there are no *fast* pascal compilers for unix (are there?
I'd *love* to hear about them!!).
--
Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack
or ...!vu44!htsa!jack
Help! How do I make a cup of tee while working with an acoustic modem?ksbszabo@wateng.UUCP (Kevin Szabo) (01/14/85)
In article <571@vu44.UUCP> jack@vu44.UUCP (Jack Jansen) writes: ( editted quite a bit by me, Kevin Szabo ) > Ok, let me throw in my $1E-1 worth of opinion. > Well, what I like most about pascal is that it *works*. > By this, I mean that if a C program takes an hour to write > and a pascal program 2 hours, the pascal program is debugged > in 20 minutes, and the C program in 2 days. > I have seen this also with friends of mine, so I don't think it > can be influenced by a difference in experience or other personal > factors, I think that pascal, by *forcing* you to define your > data, parameters, etc. correctly points you to a lot of logic errors > (and typing errors), where C will have you addicted to coffee and > tobacco by the time you locate the missing &. I agree whole heartedly that forcing the programmer to define data, parameters etc. will improve correctness in code. Actually in a recent note to the mod.standard-c newgroup I suggested adding stronger typing to C, as well as some other goodies. Of course the moderator (quite rightly and wisely) pointed out that this fell into the class of additions to C, and thus did not belong in the standard. He also pointed out that check programs, such as lint, are not part of the standard and hence could enforce strict type checking for those that so wished. This holds great promise for me since I like C but I also like the compiler to tell me when I have been stupid and passed the wrong type of argument to a function. I had previously hoped that typedef's would allow me to create my own types that would be checked by lint, but presently they are only aliases which are immediately promoted to their basic type when encountered. Hence they do not pick up errors such as: typedef foo int; /* These typedefs might be wrong */ typedef bar int; main() { foo a; bar b; get_a_and_b( &b, &a ); .... } get_a_and_b( a, b ) foo *a; bar *b; { }; Sooo... if anybody out there in net-land is hacking away at LINT you could possibly try adding a `super typechecking' option (that has to be explicitly turned off!). I suggest that it strictly enforces type checking when calling functions and, in order not to be innudated with billions of warnings, it will promote the derived type (foo) to its basic type (int) whenever mixed arithmetic is attempted. (mixed arithmetic in the sense of typea = typeb + typec; the Derived types) It doesn't effect CC but allows the disciplined programmer the type checking that s/he requires. What say ye? Kevin -- Kevin Szabo watmath!wateng!ksbszabo (U of Waterloo VLSI Group, Waterloo Ont.)
henry@utzoo.UUCP (Henry Spencer) (01/15/85)
> Well, what I like most about pascal is that it *works*. > By this, I mean that if a C program takes an hour to write > and a pascal program 2 hours, the pascal program is debugged > in 20 minutes, and the C program in 2 days. > > ... It took me no more than 8 hours to > write *AND DEBUG* a ~600 line pascal program. ... > > Now, if anyone ever succeeded in accomplishing something like > this in C, I would be very interested. Usually, I find that C programs > of that size (say, 200-1000 lines) take about 1 day per 100 lines > to write. It is quite possible to compose several hundred lines of C in one evening and have it right the first time, with no debugging needed. This requires a pretty good idea of what you're going to do, plus really fierce self-discipline ("if the code isn't OBVIOUSLY right, throw it out and do it over, even if it hurts"), but it is possible sometimes. It would certainly be possible in Pascal as well. That aside, the C rate you quote strikes me as low; insofar as I can put numbers on it, my C programming rate seems comparable to the Pascal rate you quote. There are all sorts of apples-vs-oranges problems here, of course. I confess that I would prefer a strongly-typed language, which would transfer the need to be careful about certain things from me to the compiler. Getting things done well in C requires more care, and quite possibly requires more experience to achieve a given productivity level. But it's a perfectly usable language, and has a number of capabilities that are difficult to match in a strongly-typed language. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
dgary@ecsvax.UUCP (D Gary Grady) (01/16/85)
<>
Seems to me that Pascal and Modula-2 (or extended versions of them) are
well suited to a variety of things, perhaps including some system-level
work. The discipline enforced is good for projects involving large
numbers of programmers and especially inexperienced programmers.
On the other hand, very experienced programmers will find C more
expressive and faster to write. This is why C, in practice, has such a
following.
I don't think either school of language design has all the answers; it
depends on what you're trying to do, and who's going to be doing it.
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary