🚀 go-pugleaf

On Fri, 5 Apr 91 01:34:00 GMT <editor%ucf1vm.BITNET@LILAC.BERKELEY.EDU> 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. :-)