Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!iitmax!gkt From: gkt@iitmax.iit.edu (George Thiruvathukal) Newsgroups: comp.lang.modula2 Subject: Re: BIX - BYTE - JPI - Chaos Message-ID: <1991Apr8.231822.31788@iitmax.iit.edu> Date: 8 Apr 91 23:18:22 GMT References: Organization: Illinois Institute of Technology / Academic Computing Center Lines: 62 In article , 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