Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!UX.ACSS.UMN.EDU!alk From: alk@UX.ACSS.UMN.EDU Newsgroups: comp.lang.modula2 Subject: Re: Re: C++ vs. Modula2 Message-ID: Date: 12 Jan 89 22:08:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Modula2 Distribution List Organization: The Internet Lines: 115 quoth Gernot Heiser : >In article <114700003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes: >> >>Hi, >> >>Which language do you think will fit more purposes? >>From the present perspectives, it seems that >> >>FORTRAN 8x for numerical computation >>C++ for system and object-oriented programming >>Modula 2 for general purpose and eduation >> >>are going to serve ninties and the first decade of the 21th century. >> Personally, I despise all procedural languages for being such. They are semantically obfuscative, period. As optimization methods for the compilation of functional languages continue to develop at a furious pace, I expect that some as yet unrealized LISP/Prolog stew shall be the principal source of sustenance for the hungry programmers of the late 90's and beyond. This is the case particularly in view of the fact that automagical code-generation is MUCH simpler (and more efficient) in such languages. >2) What are the deficiencies of Modula 2 as a system programming language? > >In my eyes, first of all the lack of conditional compilation. Look at C code >that is portable across widlely differing hardware and operating systems. GNU >emacs, for example, comes in one distribution for all supported systems. To >configure it for a particular hardware/operating system, one only changes a few >lines (usually 1 to 3) in the configuration file and types "make". I don't see >how that could reasonably be done in Modula. As was recently observed in the info-pascal mailing list, optimization -> conditional compilation. Consider: . : CONST . : OpSys = VMS; . : IF OpSys = VMS THEN DoVMSStuff ELSE DoOtherOSStuff; . : All but the most inanely STUPID of compilers will completely eliminate the unreachable code. >Allocation of space for records (particularily alignment) is unclear in Modula. >Operating system calls frequently return pointers to records with some >operating system defined layout. Mapping these on Modula records is, due to >alignment, compiler dependent. >Further missing are bit manipulation operators. BITSETs provide most (or all) >that is needed, but using the BITSET operators on INTEGERs or CARDINALs >requires many type casts, making these manipulations both messy and unsafe. Call me a heretic, but I often think that the safety-madness of Modula-2 is the result of completely loosing sight of the purpose of programming: To GET THINGS DONE. Modula-3 rectifies this to some extent, but if I actually want to get results in a reasonable time-frame, and LISP is forbidden to me-- often the case in systems-level applications by virtue of the relatively primitive state of commerically availiable LISP compilers, I'll pick C/C++ over M2 anyday. On the other hand, big multi-party projects make the laxity of C prohibitvely expensive. (Too obvious for words, right?) Hence C++. >>What I particularly want to know is: >>3) Which of the two languages, Modula 2 and C++, is better suited for numerica l >>computation? >Both have serious deficiencies here. The most serious one is probably the >impossibility to pass multi dimensional arrays of vaying size to subprograms. >Linearizing your matrices to be able to pass them to subprograms is a step back >towards assembler code. >Also very annoying for numerical computations is the lack of a real FOR >statement in C/C++. (Wirth, while always complaining about C, took the same >road in Oberon.) I don't understand how it is 'impossible' to pass such arrays in C. I may not be cognizant of changes made by the ANSI standard in this regard, but each dimensional component of a C array being merely a pointer, one may readily pass any array of any structural characteristic, to a 'subprogram'. It is however, necessary to pass explicit information regarding the run-time structural characteristics of such a data object, in order to prevent inappropriate memory accesses. Nor do I understand what is unreal about C's 'for'. It is a powerful generalization (within it's limited domain) of the BASIC/Pascal/Modula, etc. 'for'. I'd like to know what objections you have to the character of the C 'for', please. >....Modula provides no means to switch between single >and double precision depending on the hardware (e.g. using single precision on >>= 48 bit hardware, double precision otherwise). C makes that easy using >#define. Again, conditional compilation... I hope that my comments will be construed constructively and prove sufficiently non-trivial to provoke some rejoinder. ;;__________________________________________________________ ;;Anthony L Kimball : alk @ ux.acss.umn.edu / UMNACVX.bitnet ;;U of Mn ACSS Languages Group. (use-package 'disclaimer) ;quidquid cognoscitur, cognoscitur ; per modem cognoscentis.