brad@looking.UUCP (Brad Templeton) (10/21/86)
In article <631@imsvax.UUCP> ted@imsvax.UUCP (Ted Holden) writes: > > Borland's Turbo Pascal should probably be the "standard" > programming language for 80 percent of the programming which gets > done (outside of professional software houses such as Ashton- > Tate) on today's XTs and ATs etc. Turbo Pascal is a fine low priced system for playing around with programming. It is no more than this, however. I have to reply to an aritcle calling for it as a standard. > > 1. Price: > of around $55, Turbo is nearly free. Reasonable DOS C > compilers go for around $300 and the only reasonable C > INTERPRETER goes for around $450. Keep this point in mind; > compilers and interpreters both have their place in the > scheme of things and Turbo functions as both. Few if any > other packages make this claim. A Minor point - Turbo is not in any way an interpreter. As you are aware, it simply can compile from ram. An interpreter conjures up all sorts of superior debug stuff, at a stiff penalty in speed. An interesting point on the price. Real Turbo users have not bought Turbo 1.0, 2.0, 3.0, 8087 version and possibly some of the toolboxes. If you have been buying the product as it came out, you have forked out a couple of hundred dollars. An excellent scheme, actually. Get more money from the serious programmers, provide the dabblers with a low price so that they are encouraged to buy it. > > 2. Turbo, both in its interpreter (actually, compile to memory) > and its compile (to .com) modes, produces very fast code. > Further, the compiler itself is almost supernaturally fast, Actually, the compiler is NOT significantly faster than others. It is simply the fact that it compiles from ram that does the job. Mainframe compilers often compile as fast as TP once you take away their I/O time. Many compilers for PCs are in the same ballpark once you take away their I/O time and compiler load-from-disk time. The Turbo 2.0 compiler was no faster than others. The 3.0 is faster, but not supernaturally. The code generated isn't so great either. The main thing that helps it win is that some args are passed in registers. It's long been known that this is a way to get much faster code, but lazy compiler writers ignore it. > > 3. Turbo has the only completely believable debugging system in > the Micro world. Actually, there are lots of source code debuggers around now. Have been around for ages. Any interpreter has far superior debugging to TP (mine does, if I may plug it) and all TP does is tell you about runtime errors that it can catch. Real errors like memory violations it can't. > > 4. Turbo is a cleanly and elegantly structured language; Actually, you're talking about Pascal here. I'm not a big Pascal fan for professional work, but it is a good choice for starters. TP's extensions are haphazard and not very elegant. (More on that later) > > 5. Turbo is a large super-set of standard Pascal, with a > tremendously good interface into DOS and PC functionality, > things which lie outside of any of the ANSI standards for > programming languages. It is actually better than Basic in > this regard. It actually allows machine-coded routines to > be imbedded right into Turbo routines (Turbo inline code), > allows DOS calls with the use of only one simple register > structure, and has easy systems for addressing segments and > offsets of Turbo variables, labels etc. Such code can be > made as fast as is possible on 80x86 devices. Masm > interfaces for the various C compilers are not as clean or > elegant. This interface is hardly elegent. It is in fact, a curse. Thousands of TP programs are now totally non-portable because of these interfaces. How can you call inserting 8086 hex bytes into your code stream "elegant?" The DOS call should rarely be needed (library routines should be provided) but even when it is, almost all the C compilers I have used have something like it When a C compiler decides to go nonportable, it usually provides inline assembler in a symbolic form. The cleaner method is slightly slower. I find it hard to see a function call as "not as clean or elegant." Turbo's access to segment registers ruins portability even on the PC. Lots of programs have now been written assuming the TP segment structure. Things like "there is one code segment. Code and initialized variables are in it." are hardwired into programs now. Any reasonable attempt to make a TP compatible system for more memory, or perhaps a 286 environment, will break lots of programs. > > 6. Graphics Good, but not exceptional graphics. CGA only, though. > 7. Turbo is heavily supported by after-market and free-ware > packages and applications. A fine advantage of buying the most popular system. While most free-ware is worth less than you pay for it, there are some exceptions. The amount of C code posted to the net is pretty large, mind you. Of course, most coders don't write C very well, either, so lots of it is not suitable for machines where sizeof(pointer) > sizeof(int) > > > The other thing which bothers some people regarding Turbo is > the fact that it isn't totally "standard". This is the one case > I know of in which the Ansi standard is really kind of a joke. > With 500,000 users, Turbo IS the real standard for Pascal > in the Micro World, pure and simple. It is sort of a joke, and I would laugh a little harder if Turbo Pascal's extensions had been well designed. TP took what was wrong with Pascal and went further. One of Pascal's biggest problems is that it is full of built-ins that are called procedures and functions but aren't. Almost all of them have some feature that a user could not put in a user defined routine. They take special arguments, or have relaxed type rules, or take optional file variables etc. etc. Consider that the official definition of writeln(f,a,b); is that it is a MACRO for: f^ := a; put(f); f^ := b; put(f); Borland added such gems as the "random" function that returns a different type based on whether it has an argument or not! Initialized variables that are created in the CONST section! (They also don't work in the popular compile-to-memory mode since they generate impure code) File I/O checking that is turned on by a SECRET COMMENT and is static in scope! A Mem array that simply does poorly what absolute variables do. (And which also has a crazy syntax deviation) On the plus side, the Assign procedure is well done, a number of the others are credibly done. -------- In summary: Turbo Pascal has a number of things going for it. It is not, however, elegant. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
ken@argus.UUCP (Kenneth Ng) (10/27/86)
In article <691@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes: > In article <631@imsvax.UUCP> ted@imsvax.UUCP (Ted Holden) writes: > > > > Borland's Turbo Pascal should probably be the "standard" > > programming language for 80 percent of the programming which gets > > done (outside of professional software houses such as Ashton- > > Tate) on today's XTs and ATs etc. > > Turbo Pascal is a fine low priced system for playing around with programming. > It is no more than this, however. I have to reply to an aritcle calling for it > as a standard. The biggest selling products have a nasty habbit of becoming defacto standards. Just look at the IBM-PC, 5.25 inch disk drive, Shurgart (sp) disk drive interface, IEEE 488 (was HP GPIB), ANSI terminal (was VT100), etc. Just because something is not produced from a committee of people does not mean it cannot effectively become a standard. -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet McCoy: "This won't hurt a bit" Chekov: "That's what you said last time" McCoy: "Did it?" Chekov: "Yes"