Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!oddjob!uxc!uxc.cso.uiuc.edu!a.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.lang.modula2
Subject: C v.s. Modula II
Message-ID: <79500004@p.cs.uiuc.edu>
Date: 11 Aug 88 18:06:00 GMT
Lines: 36
Nf-ID: #N:p.cs.uiuc.edu:79500004:000:1589
Nf-From: p.cs.uiuc.edu!gillies    Aug 11 13:06:00 1988


When I first came to grad school, and began writing C code again, I
was unexpectedly disappointed.  I had grown used to a Modula-II like
language (MESA).  Some of the things that really bothered me about C
were:

1.  It's a one-pass-compiler language.  So you must pollute your
code with multiple declarations if you make forward procedure calls.

2.  Local changes can require non-local code restructuring.  This is a
collosal pain.  For instance, moving a procedure in a file often
requires adding new procedure declarations.  Adding an else-clause can
require you to restructure the {}'s.  Often, for(;;) loops are written
with *no body*, and adding additional commands can require major
restructuring of the loop.

3.  Include files are hard to keep track of, nest, and structure in a
big project.  Modules & Interfaces seem to work much better.

4.  I really miss the way MESA treats records as first class types.
For instance, you could say:

Gillies: RECORD[first: INTEGER, last: CARDINAL, data: CHAR];
var: Gillies <- [-5, 23, 'c];			 -- (record assignment)
var1: Gillies <- [first: -5, data: 'c, last: 23];-- (using named fields)

5.  I miss MESA INLINE procedures.  They are simpler and (often) more
efficient than C's macro expansions.  

6.  C has no provision for callback procedures (you need nested
procedures and the right semantics for the 'display').  So data
abstraction is hindered in C.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies