rosenber@ra.abo.fi (Robin Rosenberg INF) (07/03/89)
In article <18215@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: > In article <4525@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes: > >mwm@eris.berkeley.edu (Mike (I'll think of something yet) writes: > >>In article <4495@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes: > >>< So far I have found nothing I could do in C that I could not do in > >><M2. To me this is the test of a Language. > >> > >>You're not looking very hard. Please translate the following C > >>construct into M2: > >> short main[] = {1, 2, 3} ; > > > >Sure, > > main : ARRAY[0..2] OF INTEGER; > > main[0] := 1; main[1] := 2; main[3] := 3; > > > >Pre-initialization is a nicety, not allowed in M2 because there is no way to > >type the data. This is a restriction that I understand will be/has been > >lifted. However, pre-initailization is not a conceptual tool. It can always > >be translated to a series of assignments, or a number of other methods can > ^^^^^^^^^^^^^ > >be used to init data. > > C'mon. SURE you say. The answer is NO, you can't do it. And the result of this > can be devastating for a large project. M2 like Pascal REQUIRES you to write > CODE to initialize all your variables that need initialization. Think for > example of all the menus in a program: you'll need one line of code (that > dereferences a pointer or accesses a field) for EACH field in EACH of the > Menu item. If you have ever seen a "large" PASCAL program there is ALWAYS a Where did Pascal enter? Thought this was M2 vs C. Wirth made both Pascal and Modula2. That's what they have in common. Period. > HUGE file with all the initializations. This is enough a reason to not make > me consider M2 for any serious programming. I can't understand how you > can call this a 'nicety'. Lack of it is just dreadful. The fact that MAYBE/ > WILLBE/HAS BEEN/IT IS POSSIBLE that some M2 compilers allow pre-initialization > is irrelevant, because those programs will be totally 'unportable'. Take a better example than initializing menus. For that purpose statically initialized data structures is not a big win. To begin with I also did initialize menus that way (now I don't ). However, as things change, static initialization becomes an obstacle because it doesn't provide flexibility: it's a REAL PAIN to change anything. You still have to walk through your menus to allow for different default fonts (in most cases you should). And how about adding menus at run time. You will need menu manipulation routines. But, ok. For hacking, static initialization is great. For serious work, you will find it less useful (albeit, not useless). >And what are the "number of other methods [that] can be used to init the data" > besides pre-initialization and assignement? The question wasn't for me. But reading data from a file seems like one method. I posted this, beacuse it seems to be a habit of some people to flame first, and ask later. And there were not much to flame after all. Furthermore, which programming language you use is determined by (in priority) 1. Your employer (his religous belief). If he allows then 2. 2. You (Your religion), if your language isn't suitable then 3 3. The requirements of the problem to be solved. I.e The comparisons of languages here seems not to have anything to do with facts, just religious fanaticism. There is no reason to have a religous war in a group where you are supposed to have TECHNICAL discussion. I've made some comparisons between the two rivals. Feature Modula2 C ------- ------- - Modularization: Supported Allowed ; I.e. C does not prevent you or place from having modules, but M2 ; support modules better than C. Definition modules_ Supported Allowed ; .H files in C can serve the purpose just fine Module qualifiers Yes No ; M2 allows you to specify the module (like InOut.Read) whereas in ; C all global names must be unique. Data Abstraction: Yes Yes ; COBOL was the first language to support 'a kind of' data abstaction. ; .... ( data abstraction != data hiding ) ; Footnote: COBOL = COmmon Badly Oriented Language Data Hiding: Yes Yes ; In M2 you write TYPE hidden; in the definition module and have ; the hidden type declared in the implementation module. ; In C you declare typedef struct hidden *hidden in the .H file ; and define struct hidden in the .C file. Equivalence. Macros: No Yes ; Can help you type less, and do things (magic) that procedures ; simply cannot do. Conditional compilation: No Yes ; The feature I'd REALLY like to see in modula2. Suggestion: ; Use C macros and run the C preprocessor on your Modula2 program Static Initialzation: Not standard Yes ; Useful sometimes. Sometimes makes you take thw wrong road. Nested procedures/modules: Yes No ; On the other hand C has local static variables. Not the same though Strong typing Yes 1/2 Yes (gives warnings) ; When strong typing is used, the compiler should not complain when ; a superset of the reequired parameter is used. Like ; IntuitionBase = OpenLibrary("intuition.library",0). ; struct IntuitionBase is a superset of struct Library. Low-level access: Yes Yes ; Both M2 and C allows you to manipulate bits and bytes and word ; and longwords and do pointer arithmetic. Open Arrays: Yes 1/2 Yes ; In C arrays are ALLWAYS passed by reference, this can be chosen ; in M2. M2 allows open arrays as parameters, allowing arrays of ; any size. What I like most is ARRAY OF BYTE that allows any object ; of any size. Standard: 1/2 Yes ; There was suppose to be a standard for Modula-2. All compilers for ; modula-2 I have seen have had major differences. Wirth says that ; CARDINAL and ADDRESS are compatible, not true. Casting is different ; on different compilers (same syntax, but some allows casting between ; all type, but some don't). ; C has been relatively standard despite the lack of an official ; standard. Now ANSI is coming. You might find other things that differ. But I chose those points that are of interest. Coroutines are nothing special to modula-2. There is no reason to have them a part of the language. Corutines can be used in C by calling a couroutine library. (I suspect you could write the coroutine library completely in C with Lattice 5.02). My personal preferences goes to C, since M2 sometimes places unneccessary restrictions on how I's suppose to do thing (not what I can do). Also the lack of conditional compilation in modula-2 makes C my choice. C lets me do it MY way, good or bad. If you find it hard to choose. Choose JForth and implement any d*mn feature you like. > -- Marco Papa 'Doc' > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu > "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --- o Robin Rosenberg, Abo Akademi - Finland
doug@xdos.UUCP (Doug Merritt) (07/03/89)
In article <133@ra.abo.fi> rosenber@ra.abo.fi (Robin Rosenberg INF) writes: >Where did Pascal enter? Thought this was M2 vs C. Actually, so far it hasn't been a full fledged M2 vs C war, and I hope it doesn't become one. Simply comparing features of languages is relatively innocuous, as far as it goes. >Wirth made both Pascal >and Modula2. That's what they have in common. Period. Well, no, that's an overstatement. If you look at a C program, an M2 program and a Pascal program you'll notice far more similarities between M2 and Pascal. M2 is based on most of the same philosophies as Pascal but with the intention of having it be a practical tool (the original Pascal was a teaching tool), and this results in M2 looking like a "grown up" version of standard Pascal. No other two commonly used commercially available languages resemble each other as much as M2 and Pascal. But I think your main point, that you can't judge M2 by looking at Pascal, is perfectly valid. > Furthermore, which >programming language you use is determined by (in priority) > > 1. Your employer (his religous belief). If he allows then 2. > 2. You (Your religion), if your language isn't suitable then 3 > 3. The requirements of the problem to be solved. Unfortunately I think that usually it's just 1 & 2 without 3 as an option. Whereas ideally it would be *just* 3 by itself. > There is no reason to have a religous war >in a group where you are supposed to have TECHNICAL discussion. Agreed. Let's keep it neutral. >I've made some comparisons between the two rivals. [...lengthy...] Interesting comparisons. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary