Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: 18 Apr 91 21:30:14 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 53 On Tue, 16 Apr 91 04:02:46 GMT George Thiruvathukal said: >In article , GRANGERG@VTVM1.BITNET (Greg >>... >Well, as I mentioned in a previous message, Pournelle is full of it. There >is absolutely no good reason for anybody to argue about language "purity" and >"philosophy" when discussing a multiple-language development environment. It >is never going to be possible to interface Modula-2 and C without some details >entering the picture. I might also mention that it is pretty common practice >in the art of compilation to generate linkage names which begin with an >underscore symbol. Yes often he is, but I do like his BYTE articles. I would disagree about the language purity and philosophy issue. I see no reason why, even in a multiple-language development environment, that implementation details can't be hidden. Likely, you are more familiar with 'the art of compilation' than I, the only place I've seen underscores appended to everything is in C. >>... >In fact, you and I are in complete agreement here. The only company which has >done anything intelligent with object-oriented languages in the PC world is >Borland. Their Borland C++ product is equipped with a robust class library >... >oriented is more than just another buzzword which makes everybody's hair stand >straight and eyes pop out. marketing .. ain't it grand :-) > >>... > >If you use Modula-2 as Modula-2, there is no additional overhead for procedure >calls. In fact, in JPI Modula-2, there is less overhead for a procedure call >than there is in Turbo Pascal, because the parameters can be passed in >registers >most of the time. Your allusion to underscores, I might add, is not relevant >at all to call overhead. Not directly, but I get the impression that if I were using TopSpeed C I might have to 'go through' 1 to 2 function calls to get to a base level (in the multi-lang system) routine, while under TopSpeed M2 I have to got through 4 to 5 to get to the SAME routine. In short the routines seem to have been written for use with TopSpeed C then kludged up to work with M2, instead of designed from the ground up to work with a multi-lang environment >>... >It is my impression that the product doubled in price for the Standard Ed. Doubled, tripled ... not really important as long as they have adopted a 'reasonable' pricing structure for the future. Don't get me wrong over all I like JPI, and think the are TRYING to do a good job. Unfortunately, trying isn't doing. Hopefully, version 3.0 will be a better effort and a return to M2 (as god intended it :-) Greg