Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!khayo
From: khayo@MATH.UCLA.EDU
Newsgroups: comp.sys.mac
Subject: Borland's Turbo Pascal
Message-ID: <6932@shemp.UCLA.EDU>
Date: Tue, 30-Jun-87 03:12:16 EDT
Article-I.D.: shemp.6932
Posted: Tue Jun 30 03:12:16 1987
Date-Received: Sat, 4-Jul-87 18:28:40 EDT
Sender: root@CS.UCLA.EDU
Distribution: na
Organization: UCLA Math Science Department
Lines: 106
Summary: I liked it v. much


  After seeing a few postings about TML Pascal (with which I had
numerous problems) and a review of Turbo Pascal in the last MacUser, I
decided to write a few words about my experiences with both. Note that 
I am an amateur compared to most of people subscribing to this group,
but I've done my share of writing in Pascal - 90% of which was on the
Mac and used all the fancy interface stuff.
  I had a chance to try out my friend's TML compiler, which acted
adequately, but in certain situations bombed for no apparent reason at
all (not even while it was compiling, just transferring to or from Edit
could do it). But I managed to produce a nice application (ca. 26K) out
of my program - a scorekeeping affair which I use to keep track of my
students' sins. In the next vsn. some of it seems to be fixed, but I still
had problems. I found using TML rather cumbersome, plus I had a bit of
a problem trying to compile the source files for the interfaces; MacIntf
for instance is pretty large, and when I tried to compile it all at once
I saw a complaint of one sort or another - it couldn't be done. So either
I'd have to break it up into several separate, smaller units or... I'd
figure it out eventually, but it was rather annoying and since I had just
seen a discounted Turbo Pascal for $70, I went out & bought it.
  Of course the first thing I tried to feed it was the program mentioned
above. The initial impression is that the compiler is not really doing
anything; after the time in which you'd think the source code was just
read from the disk, the little progress indicator (a neat Indy 500 checkered
flag) stopped waving, and I was sitting there & waiting for something to
happen. Well, it turned out that the job was done - about 20 seconds, as
opposed to >3 min. for TML (yeah, I'm counting compile and link times
together - because there is no such distinction in Turbo, both things
are done in a single operation). The set-up I was using: Turbo on RAMDisk,
the source file on a floppy. The tradeoff is the fact that Turbo links
ALL routines that reside in the UNITs used by the program, and not only
those that the program actually uses. When you write a small (say 5K)
application which uses any of the Mac stuff, the difference is huge -
compiled with Turbo it will be up to 20K in size. Of course when the
program grows and actually uses more and more functions and procedures
that sit in the linked units, the difference will drop and in the case
of my moderate-sized program it was ca. 6K more with Turbo compared to TML.
I have not written any DAs (yet ?), so I don't know how will this affect
their sizes - which really should be kept to a minimum. But with normal
applications, this isn't a really big disadvantage.
  Some other differences: a unit (including the main program) has to
be <=32K, so if you are writing something larger, you just HAVE to break
it up into segments. Again, this is easily done and was never a problem for
me, but if you have a LONG and messy code from old days that you would
like to change like that, it may be a little work (figuring out which
variables should be global to particular units, plus which routines should
be kept together in a single unit so the execution speed would not suffer
too much etc.) Other differences are very clearly listed in the great
manual (a 470 page book!) that comes with Turbo; it seems that the
compiler follows the standard a little more closely than, say, Lisa
Pascal, in that it does not initialize anything, and you have to be very
careful with your dangling pointers (no allusions intended) etc. One
restriction that was really painful to me was that function results can
only be of simple type - so you can't return a record, only a pointer to
it, and I'm used to the former. Well, I just had to change my habits.
Even though I feel Turbo respects the standard more than the others, it
also allows you to do crazy things by "type-casting", i.e. giving any
variable of type "foo" any other type "goo" and using it in e.g. a
substitution for another "goo" variable (and, of course, you and only you
are responsible for the results).
  Execution speed: I ran some primitive tests, comparing TML with Turbo,
I found that Turbo's advantage was ca. 0-15% when substantial amount of
screen output was involved, and at least 15-30% with little output.
  Compilation of separate units is very easy, the compiler leads you
by the hand and tells you which units have to be recompiled after you
change something in one (or more) of the others. When the program is
executed from within Turbo, all bombs are detected by the run-time
support part and you are shown the place where the error occurred; this
is really useful. By the way, compile-time errors are indicated one-by-one,
i.e. unlike TML, Turbo gets to the first one and stops - you make the
change, and compile again. Those of you who are used to TML's endless
lists of errors may be horrified, because such approach in TML would
take hours to correct a simple program - but in Turbo it's a snap, since
compilation of an entire 32K unit would take about 25 sec., roughly 10
of which are used to write the executable code onto the disk, so that
getting to the first syntax error takes less than 10 sec. (average), and
the editor is bundled with the compiler/linker, so you waste no time; this
method also prevents the compiler from going bananas due to a forgotten
"end" or a string-constant quote.
  The editor/compiler/linker is VERY reliable and uses default (and other)
pathnames for files in a more intelligent way - I never even had to think
about pathnames, while in TML it was a constant pain in whatever. The
strange implementation of tabs (see MacUser) is really stupid, but didn't
bother me very much and will (hopefully) be corrected soon. Another
program on the disk you buy, UnitMover, lets you incorporate your own
compiled units into a "master library" that is constantly inside Turbo
(and normally includes all the Mac stuff + printer support + "console" unit
for "plain vanilla" applications + Turtle). But your programs can also use
other files, external to Turbo, as libraries - so you don't have to do this.
The whole shebang, i.e. ALL you need to compile a Mac application or a
desk accessory using whatever your soul may desire, is a single application
called Turbo, which takes about 155K of your disk space (plus, obviously,
RMaker, which Borland also includes on the disks you buy). This is what
I call simplicity.
  Overall, I recommend this thing very highly - I don't know why it only
got 4.5* in MacUser, while TML had 5 stars. Some places still have it for
$70, and then it's a REAL bargain. Of course, I don't know anything about
user support, updates etc. from Borland - I haven't had Turbo long enough -
but surely there are others around who have more experience with Borland's
products. In ending, the above may have sounded like a raving advertisement,
which always raises suspicions, but I simply like the product very much and,
needless to say (?), I am in no way connected with, nor do I... etc. etc.
                  
                                     Sincerely,

>>>>== .sicknature =======>  khayo@math.ucla.edu [Eric Behr]