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