Copyright © (1998-2002) by www.modulAware.com
SORRY! This page is no longer maintained; contains many dead links.
[Due to its defects and weaknesses, is M2 not suitable, not even for] ... "producing cohorts of sandwich graduates" ...
wrote Graham Perkins from De Montfort University Milton Keynes in this article in June 1993. It would be interesting to know what programming language they have choosen for teaching after the above referenced article was written, and what experiences they made with that (other?) language.
I don't want to summarize or criticize this article here,
but from reading Graham's article, I got the impression that
one of the selection goal was, to find a language, were students
could make less errors.
Only one example: Graham didn't like case sensitivity of identifiers in M2. I'd recommend students having problems with case sensitive identifiers to study politics or infotainment. ;-)
Graham also says, M2 is too complicated. Here I agree with him. And ISO M2 even added more complexity later. He obviously knew about Oberon-2 in 1993. But I guess, O2 was also ruled out because of case-sensitivity.
by Mark Morgan Lloyd, firstname.lastname@example.org, 30-Oct-1999
Some of the points Graham makes are extremely pertinent, for example his comment that case-sensitivity encourages novices to introduce numerous identifiers with similar spelling but different capitalisation. However, I'd point out that there is no harm in a language or implementation allowing errors of style unless the staff member marking the assignments is unprepared or unable to point them out where appropriate. The same applies to absence of comments, poor choice of names, inappropriate choice of functional units and data types and so on.
The area that I do believe his logic falls down badly is that he is not distinguishing sufficiently between the language, implementations of it, and platforms supporting the development environment and target code. It is totally inappropriate to criticise Modula-2 because the TopSpeed/Clarion implementation does not conform to a standard that was unpublished when the product came out, particularly since almost in the same breath he rubbishes both the libraries suggested by Wirth and those later implemented by Logitech which TopSpeed weighed and found wanting.
In addition, I cannot follow his reasoning when he criticises Modula-2 for not supporting the Windows API or X, after all they are so different in structure, tradition and purpose that customising a language for one of them would almost certainly make fitting it to the other a kludge and would be likely to make the resulting implementation unusable for systems and embedded programming.
I'm not going to try to pretend that Modula-2 has a great future ahead of it and is about to displace the current main-stream languages. However, as a teaching tool which is sufficient to introduce the concepts of a strongly-typed procedural language it still has a lot going for it: fairly complete, capable of real-world jobs, and a good demonstration of underlying concepts which other tools have taken on board as they've matured.
Further [anti-]anti-Modula-2 comments are welcome. If you want to add further comments, please send them to modulAware.com.
[ Home | Legal | OpenVMS_compiler | Alpha_Oberon_System | ModulaTor | Bibliography | Oberon[-2]_links | Modula-2_links | General interesting book recommendations ]
Copyright © (1998-2002) ModulAware.com