🚀 go-pugleaf

In article <INFO-M2%91040711362771@UCF1VM.BITNET>, GRANGERG@VTVM1.BITNET (Greg Granger) writes:
> Well in terms of object orientation, JPI did add some OOP features,
> these were in the spirit of Borland Turbo Pascal.  In TP these features
> greatly increased one's ability to encapsulate, but M2 was already
> strong in this area.  I believe it would have been better to have added
> operator overloading, and a few parameter passing enhancements, IF
> OOP was the intent.  I believe JPI fell to the market pressure of
> "gee we have to say it's object oriented or no one will buy it".

I am not so sure Modula-2 needed any object-oriented extensions at all.  A 
Modula-2 implementation with an adequate set of modules might be appropriate.
Good library support is to be preferred to syntactic extensions in my opinion.

I would probably not be alone on the idea that any implementation of an object-
oriented language ought to provide a robust set of classes (like the Smalltalk
classes) to encourage the use of the object-oriented paradigm.  It is somewhat
of a shame that language definition after language definition continues to 
ignore the issue of standard libraries, as a side note.  Sigh.  Look at the
intricate tangle associated with the C++ programming language.

> It was clearly hung on the compiler with little thought about it's
> value or of the long term concepts that make up OOPS, IMHO strictly
> marketing hype 'enhancement'.  I also read on JPAM (quite a while back)
> the JPI refused to consider operator overloading because it would
> "make your code unreadable".

Maybe so, but they have been working on a C++ compiler for some time now and
are planning on releasing it with version 3.0, so why the heck would anybody
say something so stupid.  Seemingly, it would argue against development of
languages which implement the feature.

> "A fair-size onion to Jensen & Partners International
> who thought it might be interesting to turn Modula-2 into C.  The old
> JPI compiler was pretty good; the new one borders on the absurd."

Well, it is no surprise to hear someone from Byte uttering such rubbish.  The
compiler technology JPI is developing is good, even if the emphasis is not
necessarily directed properly wrt the multiple-language environment.  JPI is
doing compilation techniques that have almost never been implemented on micro-
computers.  The ideas of machine independent representation, common code 
generation, and code optimization have come to fruition in early releases of
the JPI compilers prior to all of the other vendors.  It took Microsoft six
major releases to get their C compiler to perform optimizations correctly.
Once all was said and done, their compiler still cannot produce the same 
quality code as JPI's C compiler.  Their Modula-2 compiler has always supported
the Modula-2 language defined in Programming in Modula-2 and even contains an
implementation of the Wirth Modula-2 libraries.  So what is the guy from Byte
trying to say?

> Greg
> Hoping that JPI TopSpeed Modula 2 Version 3 won't be
> JPI TopSpeed Modula 2 - Oberon - C - ++ Version 3. :-)

Well, don't get your hopes up too high!  You know how the multiple-language
model is inherent to their products.

-- 
George Thiruvathukal

Laboratory for Parallel Computing and Languages
Illinois Institute of Technology
Chicago