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?

closed as primarily opinion-based by Stephen Kitt, PeterI, Raffzahn, JeremyP, Rui F Ribeiro Jun 14 at 18:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    I’ve taken the time to write an answer, but this is really opinion-based, and there are a number of inaccuracies in the question: Pascal wasn’t only used on PCs, BGI wasn’t all that great (many BASIC implementations had better graphics, and of course games programmers wrote in assembly mostly), and the fact that C was held up in standardisation committees didn’t really hurt its popularity all that much. – Stephen Kitt Jun 14 at 10:07
  • 1
    ... but then again, BGI was supplied also with Turbo C. The early-teenaged me actually wrote some 3d games with it. Luckily, slow graphics were the least of my coding problems at the time. Things I still (probably) recall: setting the border colour implicitly gives you a vsync. Geometry drawn in colour 0 inexplicably appears one pixel to the right of geometry drawn with the same coordinates in any other colour. – Tommy Jun 14 at 12:56
  • 5
    Borland Delphi (Object Pascal) was hugely popular for Windows programming well into the 2000's. Object Pascal's fortunes closely tracked Borland's choices. – Brian H Jun 14 at 14:12
  • 8
    Why are you scare quoting C? – bishop Jun 14 at 16:23
  • 1
    @bishop: A bigger question might be why people use the same name for the language Dennis Ritchie invented for the purpose of systems programming and dialects that are suitable for that purpose, as they use for dialects that are totally unsuitable for that purpose. The language which became popular should, if anything, be the non-scare-quoted one. – supercat Jun 14 at 22:01
up vote 10 down vote accepted

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.

  • 2
    What's ironic is that C has a number of deficiencies, some of which have never really been addressed, that make it less suitable than FORTRAN for things like high-end number crunching. I suspect the real problem is that until 1995 the syntax of FORTRAN was sufficiently horrid that people preferred that of C, despite its shortcomings, and Fortran-95 came too late to win back programmers who had switched to C. – supercat Jun 14 at 22:05
  • For atmospheric science and other computationally intense models Fortran is still faster than C/C++. ArsTechnica had an article on this… – Michael Shopsin Aug 8 at 20:44
  • 1
    @MichaelShopsin: It's too bad that some C compiler developers have weakened the language so it can efficiently handle tasks for which Fortran would be more suitable, rather than trying to maximize its suitability for low-level programming tasks where it would have no real competition. – supercat Sep 17 at 22:36

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.)

  • 6
    Pascal was the language of choise for the Apple Lisa and all Mac development thruout the 1980s. Apple did only support Pascal and it took quite some time until third party offered a usable C integration for MacOS (While BASIC on the Mac was more of a hobbyists thing). Similar for the IIgs. – Raffzahn Jun 14 at 9:47
  • 1
    Ah yes good point @Raffzahn! – Stephen Kitt Jun 14 at 9:50
  • 5
    Another important point about Borland Pascal compared to its competitors was its licensing. First, they were happy to install it on multiple computers, as long as you only used it one one computer at a time. Second, and more importantly, they didn't put and licensing or royalty restrictions on the binaries their compilers produced. – David Richerby Jun 14 at 14:40
  • 3
    Just a fun fact: Delphi is still used as the programming language for the world's greatest miniature train ("MiWuLa") in Hamburg – Ole Albers Jun 14 at 15:47
  • 2
    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. – John Coleman Jun 14 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.

  • 1
    A common slogan on the Microsoft Campus, if I recall correctly, was "Delete Phillipe" as they were working on QuickBASIC. I jumped on QB when it became available, and was anxiously awaiting Borland's answer in the rumored Turbo BASIC, which never arrived. When Khan (sp?) said something to the effect of "BASIC is brain dead" I gave up on Borland. – Bill Hileman Jun 14 at 13:37
  • 2
    @BillHileman Borland released Turbo BASIC in 1987, though they discontinued it two years later. It was bought back by its original developer and was available as PowerBASIC, and was still in development at least until recently, according to Wikipedia – David Richerby Jun 14 at 14:45
  • @DavidRicherby thanks, I did not remember that. I was aware of PowerBASIC though I never looked at it. I did take a look at TrueBASIC but I stuck with the myriad of MS flavors throughout my career. – Bill Hileman Jun 14 at 14:53
  • @BillHileman I only knew it because it was installed on the computers at school in the early '90s. – David Richerby Jun 14 at 14:58

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:

  1. 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.

  2. A Freestanding Implementation can call itself "Conforming" under similar circumstances.

  3. 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).

  4. 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.

  • 5
    There was a standard for Pascal: ISO7185. The problem is that there were a couple of serious defects in it that made it impractical to use except as a teaching language. Also, C89, also called ANSI C was a proper standard. I don't know why anybody would think it was not. – JeremyP Jun 14 at 15:56
  • @JeremyP: C89 made no particular effort to mandate that implementations usefully support enough behaviors to be suitable for any particular purpose. Much of its usefulness stems from cases where implementations treat UB as an invitation to process code "in a documented manner characteristic of the environment", but the Standard gives no guidance whatsoever as to when implementations should do that. A proper language Standard would make it possible to perform most tasks using programs written in such a way that every conforming implementation must either... – supercat Jun 14 at 16:14
  • ...(1) perform the task in a manner meeting requirements, or (2) indicate via some recognizable means that it cannot or will not do so, or (3) wait indefinitely without doing either. Under a very literal reading of N1570 6.5p7, it's actually impossible for programs to do much of anything without invoking UB (storage is written using lvalues, but generally not by lvalues). That would be fine if compiler writers recognized that quality implementations should seek to process programs in efficient and usable fashion when practical whether or not the Standard actually requires it. – supercat Jun 14 at 16:20
  • 1
    The problem with ISO standard Pascal is that the language described by it is basically not a useful language for most of the purposes Pascal ended up being used for. The standard describes a language that was effectively useful only for very simple interactive processes and for batch processing systems. Its file handling capabilities were almost non-existent (essentially depending on the existence of an external job control language or similar system to identify which files the program would use). Essentially, ISO Pascal is only really useful in a mainframe type environment, which ... – Jules Jun 17 at 5:07
  • 1
    ... despite being where the language originated from isn't where it ended up being used. Hence, every actually useful version of Pascal had its own non-standard enhancements for operations such as opening and closing files, referencing libraries of functions and procedures, and so on. C, on the other hand, came from a background where interactive processing was the normal way of operating, and therefore things such as opening files by name were part of its standard library from the very beginning, making it much more standardized across different versions even before ANSI C. – Jules Jun 17 at 5:11

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.

  • Business logic written in Turbo Pascal on the PC would have been largely compatible with MPW Pascal or Think Pascal on the Macintosh, since they both extend the language in similar ways [e.g. with String types that behave as an Array of Char whose first byte is used to hold the length]. I forget whether USCD-Pascal did strings the same way, but I'd guess it probably did. – supercat Jun 14 at 18:09
  • I think the problem is less the rigidity of the type system (although it was a factor), but the problem of lack of standardisation of the IO system. Standard Pascal's IO was very minimal: it didn't even have a concept of a filename, presumably (due to its origins on CDC mainframes) because files were expected to be likely to come from/be written out to tapes rather than disks. The lack of flexibility of typed files had a practically universal solution: the type file with no of ... specifier, and blockread and blockwrite procedures. The solution to no filenames was less universal... – Jules Jun 17 at 8:01
  • ... e.g. UCSD Pascal added an extra optional parameter to the reset procedure, while Turbo Pascal created a new procedure assign. – Jules Jun 17 at 8:02

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.

  • 1
    Likewise, very few programs are written in the language described by the C Standard. Instead, they're written in something closer to the language described by K&R's "The C Programming Language, Second Edition" with a few extensions that are described in later versions of the Standard. The standards for both Pascal and C are usable only as baselines, but at least in the 1980s and 1990s C and Pascal compiler writers realized that the set of features and guarantees required to make a compiler useful went beyond the set of features and guarantees mandated by the corresponding language Standard. – supercat Jun 14 at 22:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.