Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!e2big.mko.dec.com!ceomax!gillett From: gillett@ceomax..dec.com (Christopher Gillett) Newsgroups: comp.arch Subject: Re: He's not the only one at it again! Message-ID: <396@e2big.mko.dec.com> Date: 24 Jul 90 20:59:57 GMT References: <1990Jul21.004616.649@Stardent.COM> <388@e2big.mko.dec.com> <391@e2big.mko.dec.com> <1990Jul23.231717.2766@cs.UAlberta.CA> Sender: usenet@e2big.mko.dec.com Reply-To: gillett@ceomax.dec.com (Christopher Gillett) Organization: Digital Equipment Corporation, Semiconductor Engineering Group Lines: 79 In article <1990Jul23.231717.2766@cs.UAlberta.CA> cdshaw@cs.UAlberta.CA (Chris Shaw) writes: >In article gillett@ceomax.dec.com (Christopher Gillett) writes: >>Borland is but one example of a company whose success is based upon >>their ability to deliver "performance products". For the environment and >>audience they've defined as market targets, their products are excellent. > >Sure, but the problem is that these products are not what they claim to be. >Borland's products are not "Compilers", they are miniature special-purpose >compiler-based operating systems. In some cases, they are not compilers for >the languages that they claim. In other words, I'm complaining about Borland >lying to me about what their products are. > Go back and read the first paragraph. I wrote that "For the environment and audience they've defined as market targets, their products are excellent". What I've heard so far is that they've experienced troubles making Turbo xxx products work in environments other than what Borland themselves defined as the "correct operating environment". So who cares if they write to screen memory all the time? In a previous life, I wrote thousands of lines of Turbo Pascal (and Turbo C when it became available). The stuff that I wrote was all pretty much boring run-of-the-mill applications that were designed to run on your basic 640K, monochrome-or-EGA, hard disk PC-class machines. I used to write to screen memory all the time. Doing so was quick, and the O/S didn't prohibit it. When I had to port my C applications to other machines, I simply replaced the I/O module, and everything else clicked into place. Turbo xxx (Pascal and C) are true native code compilers...pure and simple. They are not certainly not operating systems. >>Griping about Turbo Whatever not running in some foreign environment (like >>Double DOS) is akin to griping about how hard it is to get your date to ride >>in your cool new garbage truck. You need the right tool for the right job. > >Again more nonsense. One of the basic problems with the Borland products is >that they bypass the operating system. Its strength (speed) is also its >weakness (unportability). Turbo xxx is in fact a step backwards in terms of >computer history, to the bad old days when you had to re-write every program >for each new machine. Why would you have to rewrite every program just because you've chosen to use something from Borland? Yes, if you use some of the stuff in their standard libraries, or if you grab onto any of their language extensions you're locking yourself in, but places where this happens are all reasonably well documented so you can stay clear if need be. I've got applications, written in C, that will compile without modification (and without radical conditional compilation) in environments as diverse as Ultrix, VMS, AmigaDOS, and MS-DOS. There's nothing magic in how to do it, and it certainly doesn't require any amazing engineering skills. Yes, you can write nonportable, unfriendly code with Turbo whatever. But you can also write robust, portable code as well. >It was a pretty good observation made by whoever in the >50's that you could write programs with a consistent programmer interface, >but which ran on different machines. Hence FORTRAN. Yeah, and back then as now you could do all sorts of things to guarentee that your FORTRAN program would never be portable. Everyone here has probably seen all the trickery with oversubscripting arrays to write into memory, or loading up arrays with machine code and then executing it, etc. Nobody blames the language or the compiler vendor for that. BTW, I didn't reply to the portions of your posting dealing with the nature and definition of science and whether or not computer science is a legitimate science. Not that I don't want to discuss it further, but I'm sick of all the "drop dead" mail from .edu types and all the "get the f*** out of comp.arch" mail from the hardware types. Let's continue that discussion offline or someplace else. >Chris Shaw University of Alberta /Chris --- Christopher Gillett gillett@ceomax.dec.com Digital Equipment Corporation {decwrl,decpa}!ceomax.dec.com!gillett Hudson, Taxachusetts (508) 568-7172