Main image of article Pascal Is Way Underrated
While it came slightly later to the party (see my article here), Pascal’s history can perhaps be summed up with the phrase, “Always the Bridesmaid never the Bride.” Developed at the end of the 60s by professor Niklaus Wirth, Pascal was only intended to be a teaching language. Original Pascal had very limited string handling, no disk access and, crucially, lacked any kind of library mechanism. What it did have was an easy-to-read syntax, a good type system, facilities for developing structured programs with three types of loops (for, while and repeat), nested procedures and functions and scoping of variables. Using begin and end to mark blocks may have come from COBOL, which was one of the languages—along with Algol-60, Algol-W and Simula 67—that influenced Pascal. At University in 1978 I was taught Pascal and I'm still doing the odd Delphi contract now, developing new applications or maintaining old code. Thirty-five years later, I’m still programming in Pascal. Click here to find Pascal programming jobs. It's safe to say that without the Danish Pascal compiler writer Anders Hejlsberg, the language would most likely be forgotten. Hejlsberg developed a Pascal compiler for the CP/M Nascom 2 computer and then for IBM PC called “Compas Pascal.” By 1986, Compas had been bought and transformed into Turbo Pascal, which—by virtue of its IDE with fast editing, compiling and debugging plus a very low price (£50 in the UK)—sold very well. At the time, other Pascal compilers were a lot more expensive and somewhat clunky with separate edit, compile and link stages. Turbo Pascal's compiler left the cursor over the compile error in the editor. That was revolutionary in 1985! But it wasn't just the IDE and fast compile-edit-debug cycle that impressed. Turbo Pascal was enhanced with library support from TP 4.0 onwards, worked with DOS and had proper string handling. This was the 16-bit era, so data structures were limited to 64KB in size, but back then that was less important. In one mad year, I wrote a 50,000-line program. It was so large that it had to be split into 20 or so dlls that shared a common data block held in memory. The big advantages of Turbo Pascal over other tools was its slickness and very short learning curve. Written in Assembler, it was fast to edit, fast to compile and ran in just 640KB of space on PC. (For a detailed explanation of how TP 3.0 worked, see PC Engines.) Turbo Pascal became Borland Pascal 7.0 in the early 90s. Along the way a not very usable TPW (Turbo Pascal for Windows) appeared, but it was as Delphi in 1996 that it gained wings. Delphi was technically superior to Visual Basic—slicker, faster and overall better once it moved to 32 bits with Delphi 2 in 1997. However, Delphi inherited one of Turbo Pascal's worst features: unit incompatibility between versions.

Units?

Units were a compile unit, similar in concept to .NET's assembly. They were invented to solve a problem that languages like C and C++ had: long compile times due to header files being reimported during compilation. Traditionally in C/C++, programs were split into main code plus lots of include files. As compilers were multi-pass, they'd re-read source files, which lengthened compile times. Even with the introduction of pre-compiled headers, units were vastly superior. Any change to a header source file could trigger massive recompilation. Units in Turbo Pascal and Delphi avoided this. They were self-contained compile units, exporting just the types, variables, functions and classes in the interface that you specified. It was the equivalent of a header file in C/C++ but generally much superior. The implementation part of the Pascal file had the code and each unit had an interface part and implementation part in the same file. The Pascal compiler could quickly decide what depended on a unit and what to recompile, making for very fast compile times. Internal changes to units only needed that unit to be recompiled. Third party libraries could be supplied as a bunch of DCUs (Delphi Compile Units) without the source code other than an interface unit defining the DCU. Unfortunately, units had a major flaw: When a new version of Turbo Pascal or Delphi came out, all existing DCUs became obsolete. They weren’t compatible between versions. If you had the source code, you could recompile it. If you didn't, you could no longer link to those DCUs. That was a major failing and though it wasn't Delphi's biggest flaw, it was a bad one. C++ had gained far more popularity by the time Delphi came along in the late 90s and then Java took even greater market share and Peak Delphi passed. Borland had its time in the sun in the early 90s with Borland Pascal 7, but it didn't innovate fast enough. In a repeat of the VHS/Betamax wars of the 1980s, Microsoft's Visual Basic defeated Borland's Delphi.

And Today

Delphi had a turbulent time, with Borland first becoming Imprise to try and get into the enterprise area. Then Codegear took over Delphi. Not long afterwards, in 2007, it sold Delphi/Borland C++ to the database vendor Embarcadero. They've done a pretty good job of extending Delphi into the enterprise area with new releases every year since then. Embarcadero's database tools were written in Delphi/Borland C++, so it's my guess that buying the dev tools was a way to preserve its investment. Over almost 30 years the revolutionary 1985 £50 Turbo Pascal 3.0 has transformed into Delphi XE6 and costs about 30 times more. But now it’s 64 bits and can develop for Android and iPhone as well as the desktop. Or there's the free/open source alternative with Lazarus, part of the Free Pascal project. That’s about equivalent to Delphi 7, and runs on Mac and Linux as well as Windows. Pascal the language deserves a very honorable mention in the pantheon of programming languages, but Borland equally so for making a usable Pascal.

Related Stories

Image: Dice