From 1985 to 1990 Borland's Turbo Pascal was at least as popular as C for DOS systems. Turbo Pascal was especially popular because of it's ground breaking BGI graphics interface while C was stalled in standardization committees.
What caused the rapid decline of Pascal support and almost universal adoption of C?
I don't think the answer is very complicated, but the scope and time-frame of the transition was much bigger than you indicate. This wasn't so much about what was happening in DOS/PC programming as it was about the slow but steady unification of scientific computing and mainstream/business computing.
The C Language, along with the Unix OS, grew to dominate scientific computing at about the same time that PC hardware was taking off and dominating all of mainstream computing. The move from workstations to PC's was inevitable because of economies of scale, but it would take all of the 1990's for commodity PC hardware to gain the performance increases needed to make it "respectable" for scientific computing. So, this long-term trend from workstation to PC hardware moved professional programmers off of their various RISC Unix platforms (Sun, HP, DEC, etc.) and onto x86. The programmers simply brought their preferred tool - the C Language - with them. The growth in the population of professional C/C++ programmers using PC's would then cement those as the most influential development languages on their new hardware platform.
I think it’s worth looking at the rise of Turbo Pascal (in particular) to understand its “downfall”. When Turbo Pascal was released, it has a number of advantages over the competition, regardless of programming language: it was fast, it produced (reasonably) fast programs, it came with excellent documentation, it included a full development environment with an integrated editor and compiler, it had decent support for the underlying platform (BGI as you point out, although it wasn’t all that good really), and it was cheap ($49.95 at launch, with an extra $100 distribution royalty at first). As a result, it was great for hobbyists, where it competed with BASIC, as well as professional developers.
It took a while for other development systems to catch up, and all the while Turbo Pascal was getting better: ever faster, with more units (including Turbo Vision of course), support for programs over 64K, and on the “professional” side, Turbo Profiler, Turbo Debugger, etc. Turbo C and then Turbo C++ brought all that to the C side of things on DOS of course, but slightly later.
So for a long time Turbo Pascal was the development tool of choice at least for hobbyists and teachers. (Pascal as a language was already popular in education before Turbo Pascal; UCSD Pascal in particular was fairly popular on some other platforms such as the Apple II. Turbo Pascal is still used in DOSBOX in many universities’ software development classes...)
But in the 90s, Windows took off, and Borland took just a little too long to make the transition with its Pascal products. Turbo Pascal for Windows was released in 1991, the same year as Visual Basic, but it wasn’t all that good, and developers had to wait for version 1.5 in 1993 for a usable platform. By that point, C and C++ had cemented their positions as the languages of choice for professional development (Microsoft C and its SDK of course, then C++ with MFC in 1992, Zortech C++, and Borland C++ with its Windows IDE, OWL and Turbo Vision in 1992), and Visual Basic as the development environment of choice for hobbyists and bespoke application development.
Delphi did allow Pascal (in some form) to make a comeback later on, in 1995-1996, in particular thanks to its nice database integration and rapid application development model. Delphi is still being developed, along with its C++ counterpart, C++Builder, and is still in use, in particular in Eastern Europe; some universities use it to teach programming. Delphi aficionados aren’t even limited to Windows any more — the Lazarus IDE is a cross-platform, Delphi-compatible development environment.
All this is very PC-centric, and that’s another reason for Pascal’s downfall: outside education, it never really made it off micros, and even there, once PCs took over, only Borland developed it. It had been the language of choice on Apple computers, especially on Lisas with the Lisa Workshop, and Macs with the Macintosh Programmer’s Workshop which initially only supported Pascal, but that didn’t last much longer either — CodeWarrior took over in the late 90s, with no Pascal support, and then Objective-C was the default language for Mac OS X. (Wirth, the inventor of Pascal, moved on to Modula and Oberon.)
Skype was developed in Delphi -- which goes along with the Eastern European link since the original developers were Estonian. I suspect that relatively little of the current Skype code base is still in Delphi since Microsoft has owned it for many years now.
Commented
Jun 14, 2018 at 16:47
I suspect it was, at least in part, due to the offerings from Microsoft getting a lot better. MFC was launched in 1992, I believe, and that, combined with C++, made a huge difference in productivity, compared to the painful old world of C and Windows API.
Also, Visual Basic arrived in 1991, although it was widely available before then in beta, and that made life very easy.
Finally, I think Microsoft did a very good job of convincing developers and IT Managers that these new tools were the standard going forward and other options were "risky" and not guaranteed to be compatible.
The singular problem with Pascal in contrast to C was that C is a much more generic language than Pascal with a more flexible typing system.
In Pascal, notably, I/O is a first class concept, with direct, and "special", support in the language. The original Pascal typing system wasn't flexible enough to handle outliers such the I/O system which need to support multiple types. nil is a keyword in Pascal because of the strict typing issues.
In C, there was no concept of I/O, and when implemented, it was done using the standard C structures, functions, and typing system that had no special support within the compiler. The I/O system was no different than any other function call.
This made C both more extendable, and more portable in the large.
Obviously, later Pascal implementations added better support to the compiler to handle special cases like I/O, and loosening up the type system. But the competing implementations just did things in different ways, thus limiting portability.
While you couldn't trivially port a Mac C application to Windows, due to the dramatically different interfaces to the overall environment, you could readily port the business logic parts that did not have those dependencies.
Now, since C the language left things like I/O up to the implementors, there was the potential for the world to run a gamut of implementation of core functionality. In fact a lament from the author of BDS-C, for CP/M, is that when he had his first exposure to C, the library he had access to differed in significant ways from what K&R eventually published. That's why his BDS-C compiler can't necessarily compile K&R compatible C programs (he had other incompatibilities as well, not simply the library). So, that was an early example of that phenomenon.
But K&R came out early enough, 1978 I think, and it was such a simple book, "heck, why not just implement this and move on". We need an I/O library, here's a I/O library.
Yet, Windows, Mac, and Unix, all had their own, internal I/O libraries upon which Standard I/O were implemented upon. This demonstrated the flexibility of the language to let developers expose the functionality that they wanted to offer, yet still retain some modicum of portability for those who were interested in that.
The early Pascals were very good. Borland's work, Think/LightSpeed Pascal on the Mac, plus all the work Apple did. UCSD P-System was quite advanced.
But, as with everything else, they were just a bit too early. C became popular because the industry had experience with Pascal, and folks enjoyed the portability and flexibility that it offered.
file with no of ... specifier, and blockread and blockwrite procedures. The solution to no filenames was less universal...
reset procedure, while Turbo Pascal created a new procedure assign.
One factor leading to the downfall of Pascal is that even though the major Pascal vendors on the PC and Macintosh both extended Wirth's language in similar ways, there was never any kind of "official" standard. By contrast, a document was published around 1989 which called itself an official standard for C, even though its quality as a "standard" (a document which defines categories of objects and conformance to each) is abysmal at best. The C Standard describes four categories of objects:
A Hosted Implementation that can correctly process at least one (possibly contrived and useless) program that exercises each of the points in the "Translation limits" section can call itself "Conforming". A Conforming implementation may impose arbitrary "translation limits" on source texts (e.g. no program may contain more than one line which has exactly twelve characters) without any obligation to document them, and may behave in arbitrary fashion if such requirements are violated.
A Freestanding Implementation can call itself "Conforming" under similar circumstances.
A program which every implementation would be required to process identically in the absence of the One Program Rule, and which at least one (possibly contrived) implementation does process correctly, can call itself "Strictly Conforming". Note that because of the OPR there's no requirement that a Strictly Conforming Program will be actually usable on any non-contrived implementations (e.g. one could use trillion-level-deep recursion within a Strictly Conforming Program if one can determine what output it should produce and contrive an implementation which checks whether it's given that exact source text and, if so, produces the correct output).
A "Conforming" program is just about any blob of text which yields a desired behavior when fed to at least one (possibly contrived) Conforming C implementation. There are a few additional constraints, but they don't mean much.
The C89 document was useful when it was interpreted as a set of baselines and guidelines which should be followed when practical. On the other hand, looking at Pascal implementations on the Macintosh and PC, it's clear that their vendors had developed a common shared understanding about how that language should work as well. The fact that C could claim to have an "official standard", however, gave it an edge which allowed it to take over.
Pascal was the implementation language for the Accent operating system and, for most of the user-mode software that ran on PERQ workstations in the 1980s. Except...
...It wasn't Pascal, it was PERQ Pascal which was enhanced in ways that made it significantly more friendly to software developers, while possibly making it harder for computer science profs to explain to intro-to-programming students.
I never had much contact with real Pascal, so I can't really say how much more of a pain it would have been to write the PERQ software if we'd been forced to use it.
