Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!VTVM1.BITNET!GRANGERG From: GRANGERG@VTVM1.BITNET (Greg Granger) Newsgroups: comp.lang.modula2 Subject: Re: BIX - BYTE - JPI - Chaos Message-ID: Date: 7 Apr 91 15:11:19 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 75 On Fri, 5 Apr 91 01:34:00 GMT said: >... >I was under the (woefully mistaken?) impression that most of the changes to be > found between 1.0 and 2.0 of the Jensen compiler, were also features > that might be found, earlier, in Oberon, and hence had been implicitly > sanctioned by Wirth. What is being talked about here? I assume we are > talking about something more or less in the spirit of object > orientation. Hmmm, well I guess it is somewhat a matter of taste, but M2 isn't Oberon nor would I what it to be, newer is not always better. Further, 'implicitly sanctioned by Wirth' is a bit of a broad statement, imagine if you saw that on a bright red peel sticker (the kind marketing people are so fond of) on your lastest compiler product box ;-) 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". 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". >Was there much in version 2.0 that did not have a close parallel in Wirth's > Oberon compiler? I know that there was a great deal in Oberon not to be > found in anything calling itself a Modula-2 compiler, such as the > abolition of variant records and the addition of built-in garbage > collection. But between Modula-2 and Oberon, was it not possible to > find a precedent for "almost" anything in JPI M2 2.0? Again this is a question of whether you want a M2 compiler or a Oberon compiler. Note, that the first copy of Version 2 JPI sent me did have a primitive form of garbage collection (which BTW I think is rarely useful, considering it's overhead, unless you are heavily OO). JPI's version of garbage collection involved the program crashing which did effectively clear the heap :-) This was corrected in later versions. Tracing this problem make me aware of just how C oriented TopSpeed Version 2.0 is. You can trace a lot of calls to the 'CLB' module (this according to JPI stands for 'Common Library') the 'Common Library' is just chocked full of _(proc name) type defs. I traced the heap problem to a _fmalloc (malloc a good sound M2 name :-) call. I get the feeling that TopSpeed C users get a lot of their calls mapped directly to assembly language procedures while TopSpeed M2 users (the companies first customers) get call overhead out the ying-yang, M2 call->M2 call->M2 call->assembly call. >Assuming that there are features in JPI M2 2.0, that have never before been > seen in association with either M2 or Oberon, what is there about them > that makes them so pernicious? Are they pernicious per se, or chiefly > so only because it makes source code written for JPI compilation > un-portable? Un-portablity isn't an issue, a least not until someone comes up with a set of standard libraries. I really comes down to the reason I posted the first message, which was what Jerry Pournelle said in byte (which I have handy today) "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." The differences between the new compiler and the old: the new requires a least 5 times more disk space, requires more memory, compiles half as fast, was/is buggy and has even poorer manuals. Further, the libraries in the old compiler were simple useful and written in M2, if you wanted to (for example) change the heap manager, it was a fairly straight forward task. The new libraries are ... COMPLEX (in fact I think some of the code was written in an imaginary plane). In short version 1 inbodied certain philosophical concepts about programming and M2 that are utterly and completely missing in version 2. Sigh. Greg Hoping that JPI TopSpeed Modula 2 Version 3 won't be JPI TopSpeed Modula 2 - Oberon - C - ++ Version 3. :-)