Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!teddy!panda!talcott!harvard!breuel From: breuel@harvard.ARPA (Thomas M. Breuel) Newsgroups: net.lang.c,net.lang.pascal Subject: Re: PASCAL as a systems programming langugage Message-ID: <282@harvard.ARPA> Date: Thu, 10-Jan-85 21:01:41 EST Article-I.D.: harvard.282 Posted: Thu Jan 10 21:01:41 1985 Date-Received: Sat, 12-Jan-85 07:37:35 EST Distribution: net Organization: Harvard University Lines: 72 Xref: watmath net.lang.c:3817 net.lang.pascal:178 |>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