gsg0384@uxa.cso.uiuc.edu (12/22/88)
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.
1) Is C++ not appropriate for general purpose? Why?
2) What are the deficiencies of Modula 2 as a system programming language?
What I particularly want to know is:
3) Which of the two languages, Modula 2 and C++, is better suited for numerical
computation?
Thanks in advance.
Hugh gsg0384@uxa.cso.uiuc.edumartillo@cpoint.UUCP (martillo) (12/29/88)
If you are interested in the usefulness of Modula II as a systems programming language, I suggest you contact someone in the Operating Systems group at Prime Computer. They were trying to use Modula II as a system programming language for Primos to supplement FORTRAN 66, PLP, SPL and 4 dialects of PMA. Helen Raizen wrote in Modula II the operating system synchronizer code, which in a very weird way gives Primos some of the functionality of BSD select(). Primos Rev 22 as a consequence has part of the operating system written in modula II. I am not sure off hand what other operating system functionality was added in Modula II. Joachim Carlo Santos Martillo
daveh@cbmvax.UUCP (Dave Haynie) (01/04/89)
in article <114700003@uxa.cso.uiuc.edu>, gsg0384@uxa.cso.uiuc.edu says: > Nf-ID: #N:uxa.cso.uiuc.edu:114700003:000:647 > Nf-From: uxa.cso.uiuc.edu!gsg0384 Dec 22 00:03:00 1988 > ...FORTRAN 8x for numerical computation > C++ for system and object-oriented programming > Modula 2 for general purpose and eduation > 1) Is C++ not appropriate for general purpose? Why? I use C++ for general purpose programming, and would have no interest in using Modula 2 for such a task. It's certainly a matter of personal preferences, but I think the object oriented features of C++ make good C++ code easier to write and maintain than anything I've used in the past. > What I particularly want to know is: > 3) Which of the two languages, Modula 2 and C++, is better suited for numerical > computation? I'd pick C++ for that, some might pick M2. In C++, I have the option of doing something like: #include <complex.h> #include <streams.h> ... complex a(3,4), b(2,3), c; c = a * b; cout << "The result is" << c << "\n"; In M2, you're going be calling functions for the multiply and probably other things. That's not to say you can't achieve exactly the same results in M2 that you can in C++, but I think I'd go mad if I had to do lots of complex math, or other similar things, in M2. > Thanks in advance. > Hugh gsg0384@uxa.cso.uiuc.edu -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
heiser@iis.UUCP (Gernot Heiser) (01/11/89)
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. > >1) Is C++ not appropriate for general purpose? Why? I see no reason why it shouldn't. C++ basically contains everything that Modula does, and MUCH more. Its major drawback is what is inherited from C, which makes it very easy to write terrible code. But then, bad code can be written in ANY language. C++ lacks the strict checks of module dependencies that are performed by (most) Modula compilers. However, in a UNIX environment (with make) the C/C++ approach works equally well (and is much more flexible). >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. Second are address computations. Their definition in Modula is WRONG! If you add one to a pointer in Modula, that's one storage unit (you don't even know whether it's one byte or one word). In C/C++, adding one to a pointer to char increments the address by one byte, incrementing a pointer to int increments the address by sizeof(int). That's the way it should be. 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. Many further deficiencies of Modula will (hopefully) be fixed in the upcoming international standard. >What I particularly want to know is: >3) Which of the two languages, Modula 2 and C++, is better suited for numerical >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.) Both languages lack an exponentiation operator. C supplies a standard library function for that, Modula doesn't. Modula does not provide information on the numeric properties of the hardware (like the machine epsilon). C has standard library functions for that. 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. C has a standard math library that is more extensive than what FORTRAN-77 provides. Modula has virtually nothing, the quasi-standard MathLib0 is totally insufficient. The upcoming standard may rectify that, though according to what I've seen so far there is not much hope. If we look at current (pre-ISO Modula-2, AT&T C++, FORTRAN-77), rather than future languages (i.e. ISO Modula-2, FORTRAN-8x) the disadvantages of FORTRAN far outweigh its advantages even for numerics. Currently my language of choice would be C++ in all three fields. Whether FORTRAN-8x is really better for numerics I cannot say until I used it for a while. >Thanks in advance. > Hugh gsg0384@uxa.cso.uiuc.edu -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser
alk@UX.ACSS.UMN.EDU (01/13/89)
quoth Gernot Heiser <mcvax!cernvax!ethz!iis!heiser@UUNET.UU.NET>: >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.
tynor@pyr.gatech.EDU (Steve Tynor) (01/13/89)
>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. But... If in order to DoVMSStuff you have to IMPORT from modules that are not present in OtherOSs, then in addition to defining the constant, you must also comment out the IMPORTs... This can get quite messy. I'm currently having the same problem in a large project in Ada. While most Ada compilers indeed eliminate code inside conditions that can be proven to be false at compile time, the compiler still has to scan that code and do syntactic and semantic checks... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= No problem is so formidable that you can't just walk away from it. Steve Tynor Georgia Tech Research Institute tynor@gitpyr.gatech.edu
treese@athena.mit.edu (Win Treese) (01/15/89)
(Problem: conditional compilation is lacking in Modula-2) One could, however, write a preprocessor to do this for Modula-2; that how's it's done with C. Indeed, one could almost use, say, the C preprocessor as it exists now. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corporation
piet@ruuinf (Piet van Oostrum) (01/16/89)
In article <INFO-M2%89011219330825@UCF1VM>, alk@UX writes:
`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.
This only helps for statements, not for declarations.
`
`>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.
This is also true for C. I had a problem recently on our HCX/UX system
where the compiler insists on aligning a lot, and where this gave problems
in one of the COFF format structs, that have a long word not aligned on a
four-byte boundary. I could get along with hacking a short in front of it
and reading/writing the second to last fields.
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806. piet@cs.ruu.nl (mcvax!hp4nl!ruuinf!piet)heiser@iis.UUCP (Gernot Heiser) (01/20/89)
In article <INFO-M2%89011219330825@UCF1VM> Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: > >quoth Gernot Heiser <mcvax!cernvax!ethz!iis!heiser@UUNET.UU.NET>: [ ... ] >As was recently observed in the info-pascal mailing list, optimization -> >conditional compilation. Consider: [ example deleted] >All but the most inanely STUPID of compilers will completely eliminate the >unreachable code. This has already been clarified by other posters. >>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. [ ... ] >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. Of course you can pass multi dimensional arrays to C procedures, but there are no multi-dimensional open array parameters. Consider SUBROUTINE sub (N,A) INTEGER N REAL A(N,*) i.e. a formal array where the size of more than one dimension is variable. Both Modula-2 and C only allow one dimension to be "open". (If anybody knows of an elegant means (NOT a hack) to do this in C++ I'd be interested to hear about it. >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. Some call it powerful, others call it messy. First of all it is not a generalization of BASIC/Pascal/Modula, its a leftover of one of ALGOL/60's worst features. C's 'for' is really a 'while' with an initialization clause and a designated spot that may contain an incrementation clause. What I consider a "real" 'for' (as opposed to the while/repeat/loop family) is a construct that executes a specific number ot times, the iteration count being determined BEFORE the processing of the body starts. This is what is really needed most of the time in numerical programs. The other cases are exactly what while/repeat/ loop constructs are for. >>....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... If you ever see anything like IF this_is_a_CRAY THEN VAR number: REAL; ELSE VAR number: LONG REAL; END; then it's certainly not Modula-2 (nor a language I could imagine to be particularly fond of). >I hope that my comments will be construed constructively and prove sufficiently >non-trivial to provoke some rejoinder. you asked for it :-) -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser