bobc@hrcca.UUCP (04/21/87)
Do you think Modula-2 will be a successful language in the Micro
world? I recently purchased Turbo Modula-2 from Echelon, and have
mixed feelings about the language. Although I don't think there is
any question that straight M2 is a better language than straight
Pascal, most M2 enhancements were already incorporated into Turbo
Pascal (and other successful implementations of Pascal I believe).
Indeed, I think that Wirth liked certain features of Turbo Pascal and
'C' language, borrowed them to rewrite Pascal, and named the result
Modula-2.
On the negative aspects of M2:
1. The explicit IMPORT of every identifier that I want to
use drives me crazy. It wouldn't be so bad if there
were only 2 or 3 modules to import from, but there are
so many!! I'll never complain about
#include <stdio.h> again.
2. The lack of a general purpose output procedure (e.g.:
Pascal's WRITE/WRITELN or C's printf() ) makes output
routines a nightmare. Using 4-5 procedure calls to
write 1 line to the console is a pain.
3. Linking in entire modules rather than individual
procedures (which I took the bother of identifying
with IMPORTs) leads to large object code. This may
just be a problem with Borland's linker though and not
inherent to the language.
I would be interested in the comments that you or any of your
associates may have on this matter.
Sincerely,
Bob Kempjtr485@umich.UUCP (Johnathan Tainter) (04/24/87)
In article <KPETERSEN.12296145744.BABYL@SIMTEL20.ARPA>, bobc@hrcca.UUCP writes: > Do you think Modula-2 will be a successful language in the Micro > world? I recently purchased Turbo Modula-2 from Echelon, and have > mixed feelings about the language. Although I don't think there is > any question that straight M2 is a better language than straight > Pascal, most M2 enhancements were already incorporated into Turbo > Pascal (and other successful implementations of Pascal I believe). > Indeed, I think that Wirth liked certain features of Turbo Pascal and > 'C' language, borrowed them to rewrite Pascal, and named the result > Modula-2. Actually, Turbo Pascal did not innovate anything. All the good stuff was lifted from UCSD Pascal (with some massaging to make it fit as native code on the z80 and 8088's; for those what don'know UCSD Pascal is compiled to a stack machine language called p-code then interpreted by hardware specific interpreters). However, UCSD didn't really innovate much either. They just collected a number of the academically favored language facilities and added them to pascal to get a real language. Meanwhile, over in Europe, Wirth was developing Modula (NOT Modula-2 yet) which incorporated many of these same ideas and some that had given rise to the C programming language. There were problems with Modula (just as there had been with pascal). However the world was no longer starving for a programming language which was both concise and powerful, so Modula did not get heavily adopted. This allowed Wirth to come along with another language, Modula-2, before anyone took Modula to heart. Modula-2 changed substitute new broken constructs for old but made some progress also. (Personal commentary, I HATE UPPERCASE RESERVED WORDS! They heavily detract from the readability of code.) > On the negative aspects of M2: > 1. The explicit IMPORT of every identifier that I want to > use drives me crazy. It wouldn't be so bad if there > were only 2 or 3 modules to import from, but there are > so many!! I'll never complain about > #include <stdio.h> again. Some M2 compilers provide a source include directive so you can do this. > 2. The lack of a general purpose output procedure (e.g.: > Pascal's WRITE/WRITELN or C's printf() ) makes output > routines a nightmare. Using 4-5 procedure calls to > write 1 line to the console is a pain. This is a consequence of not wanting special predefined procedures or functions nor allowing variable parameter lists. A clean strongly typed language is going to have this kind of problem. > 3. Linking in entire modules rather than individual > procedures (which I took the bother of identifying > with IMPORTs) leads to large object code. This may > just be a problem with Borland's linker though and not > inherent to the language. Since there can be hidden objects/functions inside of modules (which the procedures you want are dependent on) it demands a very sophisticated linker and dependency information to properly support selective linkage. You are not likely to find this in an inexpensive system. > Bob Kemp --j.a.tainter