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?

  • 9
    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. Commented Jun 14, 2018 at 10:07
  • 7
    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
    Commented Jun 14, 2018 at 14:12
  • 9
    Why are you scare quoting C?
    – bishop
    Commented Jun 14, 2018 at 16:23
  • 3
    I have an entirely different theory ... C had nothing to do with the demise of Pascal. Pascal competed against C reasonably effectively right into the early 90s. Yes, C gained a reputation as being the more serious alternative, but there was a core of happy Pascal users, myself included, right up to the mid 90s. We happily moved to object-oriented Pascals when they became available ... and then, largely, to Java. Circa 97, Java became the new Pascal, at least for a large bunch of us. Its goals were similar, it had a roughly equivalent spirit, but it was better supported, so we moved.
    – Jules
    Commented Jun 17, 2018 at 8:14
  • 3
    The SE network should have a place to recommend people go for opinion based questions. Sites like Quora (quora.com) are a good place to ask this kind of question. In fact, you can pretty much ask any question you like over there.
    – cbmeeks
    Commented Aug 23, 2018 at 13:10

6 Answers 6


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.

  • 5
    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
    Commented Jun 14, 2018 at 22:05
  • For atmospheric science and other computationally intense models Fortran is still faster than C/C++. ArsTechnica had an article on this arstechnica.com/science/2014/05/… Commented Aug 8, 2018 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
    Commented Sep 17, 2018 at 22:36
  • Microsoft embraced C with Windows, not Pascal. Commented Dec 20, 2020 at 0:05
  • This answer really doesn't have anything to do with the question. The real answer for why C (and then C++) came to dominate on PCs is because it is the "native" language of Windows development and Visual C++ was really good.
    – JeremyP
    Commented Dec 21, 2020 at 9:00

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

  • 10
    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
    Commented Jun 14, 2018 at 9:47
  • 1
    Ah yes good point @Raffzahn! Commented Jun 14, 2018 at 9:50
  • 6
    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. Commented Jun 14, 2018 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
    Commented Jun 14, 2018 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. 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.

  • 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. Commented Jun 14, 2018 at 13:37
  • 4
    @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 Commented Jun 14, 2018 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. Commented Jun 14, 2018 at 14:53
  • @BillHileman I only knew it because it was installed on the computers at school in the early '90s. Commented Jun 14, 2018 at 14:58
  • 1
    And yet the Windows API used the Pascal calling convention. Commented Dec 23, 2020 at 3:48

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
    Commented Jun 14, 2018 at 18:09
  • 2
    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
    Commented Jun 17, 2018 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
    Commented Jun 17, 2018 at 8:02
  • Standard Pascal was a pain. Turbo Pascal was much better. I just reread the documentation for the sibling PolyPascal where it was demonstrated how to write an interrupt handler in Pascal. It could have been done ... Commented Dec 20, 2020 at 0:10

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.

  • 6
    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
    Commented Jun 14, 2018 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
    Commented Jun 14, 2018 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
    Commented Jun 14, 2018 at 16:20
  • 2
    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
    Commented Jun 17, 2018 at 5:07
  • 2
    ... 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
    Commented Jun 17, 2018 at 5:11

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
    Commented Jun 14, 2018 at 22:12

Not the answer you're looking for? Browse other questions tagged .