madd@bucsb.bu.edu.UUCP (Jim Frost) (10/28/86)
Recently there have been many postings tearing apart Turbo Pascal
(henceforth called TP). I think they all started with a comparison
that somebody did with TP vs some C compiler. I guess the results of
the TP/C tests showed TP significantly slower on character I/O. Well,
I think that there may be a few things people forgot.
TP is not the best language going for everything. It doesn't exactly
make small programs (the min size for ver. 3.10A is something like
14k, since TP includes a runtime package). It isn't usually real fast
for character I/O operations (more later). It only allows 64k of data
space (unless you go to pointer-related structures). It's floating
point is far from the best. But these are the only deficits I know of.
Consider: TP is one of the fastest compilers around. It compiles
code at about the same rate as the IBM PC linker links modules (maybe
a little slower, but not in my experience). This tends to knock out
those who beat on it for not allowing precompiled modules to be used,
though there are problems in using the include compiler directive (no
nesting, for instance). If you make compiled code as fast as the
other compiler can have its code linked, how could the compiler/linker
combo possibly beat you in time tests?
TP has one of the easiest operating system interfaces I've seen yet.
I can directly access the operating system with a minimum of work.
This provides more flexibility than the Pascal language has built in.
It makes it next to ideal for systems programming. The only problem
is the minimum size after compilation. And the speed of the compiler
cuts down on debug time.
TP has enough extensions to the Pascal language to make it flexible
enough to use for nearly anything. It's string-handling routines
alone make TP useful. It's screen routines (at least on the PC) make
life easier on the programmer. The graphics module they include gives
you nearly everything you need for graphics. Granted, you have to
specifically include it. But, you have to do a number of #includes to
make C worth using (eg #include <stdio.h>) at all. I never used C
with graphics, so I have no idea if there are similar necessities.
I realize that TP's number handling isn't that great. But if you want
it, they offer a BCD version that is more than adequate. I wouldn't
recommend it for business applications, though. Use a real language
(like RPG II :-)).
Now it's time to address running speed. Except in I/O and floating
point calculations, TP matches most of the C's out there. Meaning,
the basic language is very fast. This comes from both my own
experience and those of programmers in companies which use TP for
systems programming (they DO exist!). For instance, Alloy makes a
coprocessing card for PC's. They have an operating system extension
that ties it to PC/MS-DOS. While the network executive that handles
most of the card functions is written in a C/assembler hybrid, they
write early all their utility programs in TP. They say that
development goes so fast, they wouldn't dream of writing it in C
unless it has to be real small. (Disclaimer: this was revealed to me
in a conversation with one of their tech people. My opinions may
reflect my interpretations of what they said, but I think that's
accurate).
Floating point is not TP's strong point. I almost never use FP in my
programs, so I can't give much from experience. I have heard that
many C's beat TP in this and I believe it. If you want fast FP, use
FORTRAN and not Pascal. TP's 8087 version is supposed to be great,
but I don't recommend it for business stuff either.
I/O is a complex thing with TP. It's true that on basic character
I/O, C tends to beat out TP. This stems from the built-in buffering
of most C's. TP *CAN* give you his, but it doesn't do it alone. When
you use text files, you have to specify a buffer size. If you use a
"file of byte" specification, use C instead. I don't think you can
speed it up. But on text processing, the specification of a large
buffer can increase performance by a *lot*. If you want raw speed,
you can use the block specification for disk files. This is TP's
fastest I/O, and it runs at least as fast as in anything I've dealt
with except assembler.
If it sounds like I like TP, you're right. I wouldn't use it for a
really big application because of its limitiations. But if you need a
fast hack, it's hard to beat. As for price, it's by far the best deal
I've come across in terms of capability vs cost. It's compilation is
so fast that debug time is drastically cut. The lack of a symbolic
debugger makes it harder to use, but REAL hacks don't use them (:-)).
The operating system interface is good enough to make it one of the
best languages for writing utility programs.
Email flames so I can reply directly.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
- Jim Frost * The Madd Hacker -
UUCP: ..!harvard!bu-cs!bucsb!madd | ARPANET: madd@bucsb.bu.edu
CSNET: madd%bucsb@bu-cs | BITNET: cscc71c@bostonu
-----------------------------------+-----------+------------------------
"Use the key, unlock the door | o/ <- Rudolf the
See what Fate might have in store." -- Rush | _O_ waving penguin