alex@sdcsvax.UUCP (Alex Pournelle) (06/22/84)
{ I guess this is the symbol for a Japanese smiley face: ;-) }
M2 does indeed provide exception-handling, at least in real
implementations. Rather than Ada's hide-bound "this is the way you will
handle them, unless you stick in a statement to pass the buck" exception
declaration, M2's allows them to be passed in at run-time (heavens!
Shades of LISP!).
C may be flexible, but it's also incomplete: no modules, little data
hiding (except with the primitive "across file boundaries" method), no
nesting, and an infuriating VAR parameter passing method. Not to
mention that PROCS are an add-on (using the void type), there is no
initialization section (hand-in-hand with modules), and loony-bin
syntax.
Sure, you can cure the rather baroque syntax oddities with #DEFINEs, but
then no one will be able to read your code ("Hey, mac, what are all
these BEGINs and ENDs doing in your C program!").
C is also very hard to learn as a first (or even seventh!) language.
Its syntax and I/O lead to hair-tearing bugs that can take hours to find:
e.g., leaving out the word "case" in front of the cases of a switch();
leaving the file parameter out of an fprint(); the crazy dichotomy between
zero- and one-based arrays (in the same language, mind you!).
More examples on request.
Here's a question that the lions of net.lang can tear into: will we see
a coming-together of "traditional" Pascaloid languages with the more
"experimental" LISPoids? We've seen some of this
already; what with the tremendous inertia of FOOBOL and COTRAN, we're
unlikely to see wholesale change within a year, are we?
Alex
Vituperation will be cheerfully laughed at, then sent to the TwiByte Zone.
Constructive comments will be saved.gam@proper.UUCP (Gordon Moffett) (06/26/84)
> From: alex@sdcsvax.UUCP (Alex Pournelle) > Organization: Alex Pournelle @ UC San Diego; freelance writer > > C may be flexible, but it's also incomplete: ... > ... and an infuriating VAR parameter passing method. Not to > mention that PROCS are an add-on (using the void type), there is no > initialization section (hand-in-hand with modules), and loony-bin > syntax. It seems you just don't like C: these complaints are not reflections of the languages weaknesses but your objection that it doesn't look like Pascal. To wit: > Sure, you can cure the rather baroque syntax oddities with #DEFINEs, but > then no one will be able to read your code ("Hey, mac, what are all > these BEGINs and ENDs doing in your C program!"). Again, you are just trying to make it look like Pascal. It's not Pascal. It's C. > C is also very hard to learn as a first (or even seventh!) language. Anyone who knows Pascal [!] can learn C in two weeks. I say this not only from my own experience but of others' as well (in fact, such a sequence is to be encouraged!). > [C's] syntax and I/O lead to hair-tearing bugs that can take hours to find: > e.g., leaving out the word "case" in front of the cases of a switch(); > leaving the file parameter out of an fprint(); ... This is true, sometimes the catch-all `syntax error' does not tell me all I would like to know about grammatical errors I've made, but it has never been a serious problem for me. As for the fprint [sic] do you use lint? > ... the crazy dichotomy between > zero- and one-based arrays (in the same language, mind you!). I have no idea what this is refering to. Arrays in C are always zero-origin. -- Gordon A. Moffett { hplabs!nsc, decvax!sun!amd, ihnp4!dual } !proper!gam
alex@sdcsvax.UUCP (06/28/84)
Oh, goody! A net controversy! Somehow I guess I should have known that knocking C would get me talked about.... > From: alex@sdcsvax.UUCP (Alex Pournelle) > Organization: Alex Pournelle @ UC San Diego; freelance writer > > C may be flexible, but it's also incomplete: ... > ... and an infuriating VAR parameter passing method. Not to > mention that PROCS are an add-on (using the void type), there is no > initialization section (hand-in-hand with modules), and loony-bin > syntax. It seems you just don't like C: these complaints are not reflections of the languages weaknesses but your objection that it doesn't look like Pascal. [My reply:] Well, not exactlyish. I would much prefer Modula-2 to Pascal; given a choice between Pascal and C, I would have a rough time (watch, it Alex, next you'll be saying you actually wrote code in C when you had a choice!). But between M2 and C, I'd choose M2 any day and twice on Splashday. To wit, and to explain my rather breezy comments of yesteryore: The VAR parameter passing method: can anyone REALLY believe that putting '&' before a parm (or wherever it goes; I always have to look it up) and then dereferencing it inside is easy to read and intuitive? I guess if I remembered more of my assembly class it'd make more sense. Me, I'll take writing VAR in front of the parm. C's method makes it look more like a high-level assembler, but, hey, that's what a guy from Mark Williams told me C was anyway... PROCs: If I decide I want to use a function as a proc, I can either ignore its (possible) return or predeclare it as "void". {I can hear the reply: "well, most things will return int anyway, so the default is FUNC. You want a PROC, you void it like in the void captain's tale." And my immediate reaction: yuuch. But that's prolly colored by my long and toxic exposure to PASMODCAL2.} This method isn't the greatest, I feel. Modules: Nope, putting parts in different source files DOESN'T count. There are no true modules in C and will never be. Shure (don't they make needles?), a follow-on language to C might have these added, just as they have been to M2. But that's not the current argument. There just aren't proper modules in C, ones that encapsulate other code and 'hide' it. Nor is there proper checking of passed parms, or much of anything else, either. Lint checks up on some of these things, but not all. There STILL aren't proper interfaces for multi-programmer projects. There are formal ones within M2--specifically, definition modules. Def modules are a bit like ".h" files, 'cep' that there is one per M2 module. This means that only those files that directly rely on the changed def module now require recompilation. Now, it's true that you could do much the same thing with C--use a ".h" file for every "module", so make won't recompile everything. But the parameters aren't laid down in the interface section (def module or ".h" file). I would much prefer they were; but this will probably get me talked about so I'll stop. Initialization sections of modules: by this I mean a section of the encapsulating structure which contains a "begin .. end" (or "{ .. }", if you must) block. This block is executed once before any of the contained code is performed. E.g.: Module phydeaux; proc bella; begin .. end; proc donna_donna; begin .. end; begin (* phydeaux init section *) y := 3; end phydeaux; y will equal three before bella or donna_donna are called. Very useful when you have a great heap of code; not only do you have to know nothing about the internals of the module to use it, but you don't have to remember to call any init proc, either. ((If someone can show me how to do this in C, feel free (((unless free's not in a feeling mood))) )) Loony-bin syntax: "if (y = 3) ..." won't quite do what we abhorrent Pascallers thought it would. Lint won't ever complain, either. I can live with the word "then", I guess, but bugs like that are real subtle to me. I guess I'm lazy; I'd rather have the compiler check such things. Another example is union/struct references. I still have bald spots over these. They ain't intuitive, nor are they easily committed to memory. I can limp along by "drawing pictures" (a To wit: > Sure, you can cure the rather baroque syntax oddities with #DEFINEs, but > then no one will be able to read your code ("Hey, mac, what are all > these BEGINs and ENDs doing in your C program!"). Again, you are just trying to make it look like Pascal. It's not Pascal. It's C. > C is also very hard to learn as a first (or even seventh!) language. Anyone who knows Pascal [!] can learn C in two weeks. I say this not only from my own experience but of others' as well (in fact, such a sequence is to be encouraged!). > [C's] syntax and I/O lead to hair-tearing bugs that can take hours to find: > e.g., leaving out the word "case" in front of the cases of a switch(); > leaving the file parameter out of an fprint(); ... This is true, sometimes the catch-all `syntax error' does not tell me all I would like to know about grammatical errors I've made, but it has never been a serious problem for me. As for the fprint [sic] do you use lint? > ... the crazy dichotomy between > zero- and one-based arrays (in the same language, mind you!). I have no idea what this is refering to. Arrays in C are always zero-origin. -- Gordon A. Moffett { hplabs!nsc, decvax!sun!amd, ihnp4!dual } !proper!gam