[net.lang.pascal] The case for Borland's Turbo Pa

brian@prism.UUCP (10/22/86)

As far as using Turbo Pascal for quick program development, I don't
think that there is anything that beats it. Sure, other compilers may
COMPILE as fast -- but, gee whiz, I think that the whole task of reading
the code from disk, compiling it, and writing an executable is the
actual COMPILE step. (Heck, my car could have a 400 horsepower engine in it,
but I don't go very fast because it only runs in first gear).

Oh, and if you think that other pascal compilers are comparable to turbo
as far as compile speed if you compile from disk, I think you are wrong.

Try compiling with source code on disk (use the M option in the compiler
to define a main file name, which INCLUDES program source on disk) and 
compile it to a .COM file - It will be quite a bit faster than Microsoft's
Pascal compiler.

That is what the development process is sometimes all about -- trying new
stuff as quickly as possible.  Then use microsoft's compiler to generate the
production code (if you think it is really necessary).

----
Brian K. Moran  brian@mirror.TMC.COM	
               {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
Mirror Systems	2067 Massachusetts Avenue  Cambridge, MA, 02140
Telephone:	617-661-0777 extension 141
(((((((( * ))))))))
---

brad@looking.UUCP (Brad Templeton) (10/23/86)

In article <72100001@prism> brian@prism.UUCP writes:
>
>
>Oh, and if you think that other pascal compilers are comparable to turbo
>as far as compile speed if you compile from disk, I think you are wrong.

That's because Turbo Pascal
	doesn't have to load in the compiler (or multiple passes of it).

	doesn't have to write out the object code. (or does it in a single
	  block write)

	loads in the source with a single multi-block read into ram.
	  (You would be surprised how much faster this can be than a tpical
	  buffered getc)

	Has no link phase or libraries. (one of the biggest wins, but one of the
	  biggest costs.

Now you may say, "this cleverness is exactly what's right about TP," and you
are probably right.  My point was that the compiler itself is not
supernaturally fast.  Anybody could have done the same with their compiler.
If they had realized the market, they would have.
>
>That is what the development process is sometimes all about -- trying new
>stuff as quickly as possible.  Then use microsoft's compiler to generate the
>production code (if you think it is really necessary).

If your program is not CPU bound itself, use an interpreter.  That lets you
try stuff even faster and gives you superior debugging.
>Brian K. Moran  brian@mirror.TMC.COM	
-- 
Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473