Fashion as much as anything. A lot of people have the idea that Pascal is somehow not "modern", but these same people almost universally haven't used it lately or even at all.
Mostly companies just want to use what everyone else is using to ensure there's broad support and to make individual programmers easier to hire and fire.
But there's nothing stopping you from using it now if you want to. Personally, I quite like Object Pascal.
I think your first link [freepascal.org] speaks volumes. I clicked on it and was taken to a page which looked like it was stuck in a 1990s timewarp. Opened it on my phone and, as expected, no concessions to mobile layout at all. Just that massive page of text rendered in microscopic size on my phone screen.
Back to the site on my laptop and I look for the two things I want to see up front when deciding whether I'm interested in dipping a toe into a new programming language:
1: What are its selling points?
2: What does the syntax look like.
Nothing at all there to give me any info. Just a load of text outlining the differences between the latest point versions. So I click on 'Documentation' thinking there might be a 'Quickstart Guide' or something of that ilk there, that will give me some of the info I want. Nope. Just various in-depth User Guides as downloadable PDFs or HTML versions.
OK. Let's try the HTML version. I click on that and the entire screen fills up with a massive index of all the chapters and sub-sections in the guide. None of them called anything remotely welcoming like 'Start Here' or 'Quickstart'
Oh, and not that it's strictly necessary. But the only visuals I saw on my abortive mission onto that website were a tiny badly cut-out clipart picture of a cheetah [the project icon?] at the top of the front page and a couple of other nondescript icons at the bottom, one of which was a broken link.
Pascal may be the best programming language in the world and 'fashion' may have played some part in its alleged demise. But some people [and projects!] don't exactly do themselves any favours by actually making an effort to sell themselves, do they?
freepascal.org is about the Free Pascal Compiler, not Pascal as a language. Both gcc.gnu.org and clang.llvm.org don't contain example C code and both look more dated than freepascal.org. The Embarcadero website on the other hand seems pretty modern with all the modern annoyances including slow page load time, popups and a blinking title text.
> I clicked on it and was taken to a page which looked like it was stuck in a 1990s timewarp. Opened it on my phone and, as expected, no concessions to mobile layout at all. Just that massive page of text rendered in microscopic size on my phone screen.
Sure, maybe check https://cppreference.com/ on your phone too. C++ is a popular language and has modern updates all the time, as you can see on that very site, yet the top reference site has a non-responsive design arguably "stuck in 1990s".
Judging an old and mature project by whether its website design is updated to 2020s is shallow.
To be fair; the real comparisons they're making are to things like Ruby, Rust, Python, etc. These are all languages that have done extraordinary jobs at evangelism and at setting up communities that are structured to have friendly, non-adversarial cultures. It's not an accident that these languages have become obscenely popular.
The "design" in terms of how it looks is, as you say, irrelevant. The "design" in terms of what information is conveyed, is deeply flawed in the sense that it's excellent for anyone who's already using the compiler - and completely useless for someone swinging by wondering about getting into Pascal in 2021. I.e. "preaching to the choir", as they say.
A fair amount of why websites started to also look different over time, is they structurally altered themselves to convey additional information. For example, a lot of programming language/compiler sites have images at the top now giving "strangers" a quick glimpse at the syntax.
It's all about crafting your website so it's useful to complete strangers, rather than only useful to the existing in-crowd.
Please give it your best effort to manage your emotions. Your title makes you come off as ungrateful, presumptuous, and oblivious to the point the parent commenter was trying to share. While your comment had necessary helpful detail, the delivery negates all willingness to assimilate the data you are so painstakingly delivering.
Do better! Be better! Let's start over again on a different foot.
The utter superficiality of your comment is the perfect demonstration of the fashion driven nature of software development. You're not worried about the language. You're worried about the marketing and whether or not you feel cool.
You might as we be asking if this is the right language to wear this season or if your bum looks big in this compiler.
>The utter superficiality of your comment is the perfect demonstration of the fashion driven nature of software development. You're not worried about the language. You're worried about the marketing and whether or not you feel cool...
You walk into a bookshop, undecided on what you want to read next. On every shelf are books in plain white covers. You pick one out at random and look at the front. There is no illustration at all to give you any hint as to what it's about. Just the plain white cover with the title of the book. You flip it over. On the back cover, instead of a summary of the plot, there is just an index of chapter titles.
If that's not enough for you upon which to base your decision on whether or not to purchase, then you're an incredibly shallow and fashion-led reader
[Feel free to create similar analogies. For example; a supermarket in which every tin, packet and bottle has a plain white label with 'Food' written on the front and nothing but an ingredients list on the back]
Programming languages have network effects. More popularity -> more utility. Popularity of language is not determined rationally.
C had small edge in utility at first, then it ballooned into huge base of programmers. Familiar syntax can sell completely new language with different semantics. Choosing syntax from C has lead to success of C++, Java, JavaScript, JSON, ... despite completely different semantics.
Pascal and successors Modula Oberon and Ada with similar syntax features did not succeed. It had little to do with language features, ease to learn (except surface syntax) or semantics.
Probably, I programmed both back then and Pascal had the better development experience as a language but C had the libraries and the mindshare so it kinda depends where you draw the lines for developer experience.
Turbo Pascal was in it's day a joy to work with as a language - clean, fast (compilation and runtime), good documentation, decent tooling.
Most people at the time had never heard of Modula-2, and in any case had no ready access to a compiler for Modula-2. You have already had pointed out that the dialects you promote were all mutually incompatible, with no preprocessor to help paper over differences. Anybody wanting to write portable code was stuck.
And, the article was about Pascal, not about Modula-2. Are you wishing he had also written an article about Modula-2 that you could also critize, maybe for not being about Modula-3 or Oberon instead?
I'm not sure Pascal entirely lost due to just C. Borland's Turbo Pascal was quite popular and was broadly used in the mid 80s. Apple even used their own Object Pascal variant through-out the 80s. Pascal was primarily used for application development and for this case it was leagues ahead of C and C++. Turbo Pascal thrived up until Delphi was released in 1995, which then became the new lead Pascal. Unfortunately, Delphi would come to face it's killer within a year.
When Java came out in 1996 it became an overnight juggernaut in application development. Java had a ton of hype when it was still in beta in 1995 and TIME magazine even listed it as one of the best products of the year--when it wasn't even released yet.
Microsoft poached Anders Hejlsberg, the primary language designer of Turbo Pascal and Delphi, from Borland in 1996 to have him work J++ their variant of Java. J++ followed the Sun Java spec with a few deviations, but it was just another testament to how quickly Java was taking over.
Borland was now competing with something that was free and they needed to pivot and well...they didn't.
> I'm not sure Pascal entirely lost due to just C. Borland's Turbo Pascal was quite popular
Look at which one is being used to this day to write essentially every modern operating system, and even the interpreters and compilers for other languages. JavaScript engines are written in C, not Pascal.
I think it obviously did lose, though judging from the moderation it clearly still has some fanatical followers.
Both Turbo Pascal and Object Pascal had so many extra non-standard and un-Pascal-like features that they were barely even the same language.
As I mentioned in another comment, allowing you to write bare assembly language inline wasn't exactly a feature of the original Wirth Pascal. The analogy I used at the time was that (Wirth) Pascal was like a pair of blunt-pointed kindergarten scissors, while C was more like a chainsaw. Borland added enough non-standard features to make it more like maybe a kitchen knife, but in the long run that still wasn't enough.
Very true, Borland didn't pivot, they found a buyer (Embarcadero) and the top executives got paid. Then Embarcadero had to get their money, so Delphi prices kept getting raised higher. Totally out of the price range of normal users or independent developers.
Arguably what saved Pascal/Object Pascal was the open-source projects of Free Pascal/Lazarus and PascalABC (popular in Russia). Plus there were huge fans of Turbo Pascal, who got it released as freeware, as Borland had switched to selling the Delphi IDE.
This combination (Free Pascal/Lazarus, freeware Turbo Pascal, PascalABC, etc...) of open-source freeware Pascal eventually put pressure on Embarcadero to release the free Delphi Community Edition (2018). That was 5 to 10 years late in the game. A lot of user base and previous strong fans had significantly diminished.
However, it does appear that Object Pascal has found a decent level, at presently between the top 15 to 20 programming languages (were it was between top 1 to 10 in the 80s and 90s). It is possible for Object Pascal to see a bit of a resurgence, based around the free open-source dialects of Pascal and Embarcadero's strong push to put Delphi in schools (example- Turkey bought 1 million licenses for their schools or South Africa replacing Java with Delphi).
Although an interesting reading from Kernighan in the temporal and industry context (let us remember he worked for years building UNIX, the greatest reason C still survives, and published the reference C book), it is also interesting to see that at least six of his arguments against Pascal (namely, 1, 2*, 5, 6, 8*, 9, where only part of the arguments 2 and 8 should be considered) are actually considered best practices nowadays, and are related to type safety and functional programming.
I am not a Pascal expert, but I believe that arguments 3, 4, 7 and 8 are not valid any more, possibly they were not even valid a decade later, which would invalidate the whole essay.
And some of the "advantages" of C over Pascal, presented by Kernighan, are exactly the origin of many CVEs we have nowadays, such as unbounded arrays and unverified casting of types.
I really like Kernighan's code and texts, but it is important to remember he is really biased in this text, and hasn't provided any of the advantages of Pascal over C, except it is easier to learn.
I won't promote Pascal, but one can see that a language two years older than C has some language constructs [1] not seen even on modern programming languages! Kernighan, though, purposely left it all out of his evaluation.
Re 1/2 - I don't follow? The criticism is not against fixed array types or statics. It's that it has those traits and there is no escape hatch. Functional languages with strong type systems are flexible enough to operate over arrays/strings generically. And static/global is absolutely used. The difference is nowadays there are stronger controls to access (e.g. rust's lifetimes and borrow checking).
I don't know much about Pascal but it sounds really hard to do things which aren't supported by the development environment.
I always think it ironic that the C order of variable declaration prevailed for so many years (C++, C#, Java) yet in recent times several newer languages have discovered that the Pascal declaration order is handy for compiler type inference.
While I appreciate the increased readability, I kind of like C being economical, in that it does not need all those pesky 'var', 'fn', etc. (On the other hand, I think C creators may have gone a bit too far with this when they decided that overloading the keyword 'static' was a good idea.)
Also the main reason behind the religous war in C++ of west const versus east const.
Microsoft now got a couple of top devs on their C++ team that are on east const, so while we have about 25 years of Microsoft documentation, code samples and libraries using west const, the C++/WinRT team is now pushing for east const everywhere.
If this is an exercise in reading comprehension I suppose we should begin by trying to identify the author's purpose — persuade, inform, or entertain — and distinguish between facts and opinions.
In the 1980s, Pascal was all the rage. The Apple Lisa and Macintosh programming manuals had two examples for every API call: Assembly language, and Apple Pascal.
But I think when Microsoft settled on C for Windows programming, Apple and others jumped on the bandwagon. And since the languages are actually very similar, I think that Pascal was mostly seen as irrelevant after that. It lacked a distinct niche apart from C.
If we didn't already know it was not reliable, this alone would suffice to demontrate it. Citing TIOBE is like saying you're OK because anyway your mother loves you.
Pascal was crowded out of its niche by Delphi. It could have been supplanted by Modula-2, instead, or Oberon, UCSD Pascal, Object Pascal, Apollo Pascal, or any number of other languages with syntactic similarities to Pascal. But it wasn't.
Pascal was displaced by K&R C for mainstream work, which was soon supplanted by C90. C90 has been displaced from serious development work by various C++ versions, although it hangs on in restricted niches, for historical reasons, usually as C99 and sometimes C11. C++98 has been largely supplanted by C++11, which is beginning to be supplanted by C++17 and C++20.
It doesn't make sense to say that Pascal is alive when there is no one, anywhere writing code that could be compiled by any actual Pascal compiler, and no actual Pascal compilers for any current machine.
Delphi is the product name of the IDE. The programming language that Delphi uses is Object Pascal. Check the wikipedia or Embarcadero's website to confirm.
Object Pascal is an extension of Pascal, that adds OOP. It is much tighter than the relationship of C to C++. You can write Object Pascal procedurally, where it closely resembles ISO 1983 or 1990 Pascal.
By the way, there was a 1993 technical committee to add OOP to Pascal, which a lot comes from the various Object Pascal dialects. Be that as it may, the Borland/Embarcadero Object Pascal became the de facto standard. The other dialects of Object Pascal follows them.
To say nobody uses Pascal/Object Pascal is disingenuous. Clearly people use and pay for Delphi (Embarcadero), Oxygene (Rem Objects), and Smart Pascal. Free Pascal/Lazarus and PascalABC are open-source projects with over 20 year histories, so they are not going anywhere, and are very much used.
Pascal did not fail. It was quite a succesful learning language. To illustrate algorithms, it was not much better than C; as a system language it was
much worse. So, it was replaced.
ADA is its spiritual successor, which is still being used in some industrial/military applications.
(Turbopascal not counting, as it is the same as Pascal).
I learned Pascal in High Scool, in 98, where it was taught as a 'learning language'. Something to learn intro into programming and basic CS concepts, but then to move on into other languages for real work.
So, even in the 90s, it was not thought as a production level language. ADA was at the time, and of course Java was coming up in the scene as a replacement for C++ which was the default 'large programs' language.
Python and PHP were just starting to take off as the web was becoming popular.
Once the dust settled, ADA remained a niche language, and Pascal pretty much disappeared from school settings, as either Python or Java became the default languages for intro to programing.
There was never any such language as "ADA". The name started out and is still Ada.
There were once COBOL, FORTRAN, LISP, ALGOL, and BASIC, some since renamed to Fortran, Lisp, and Algol. Pascal was always Pascal. COBOL is still COBOL, and BASIC is still BASIC. "Visual Basic" is a wholly different language.
or even nicer was modular 2. But natively, *nix and windows were C bindings, turbo pascal and delphi were the closest for pascal to be popular, but embedded systems also started going C, then C++ came along and OO was supposed to be a magic solution, and object pascal was a late response to the OO phase.
One of the factors was Microsoft. The rival Borland was big on Pascal with the venerable Turbo Pascal.
During the years where the mainstream office business landscape transitioned from DOS to OS/2, no wait, Windows, broadly speaking there where two types of application programmers. Those that used C or C++ and those that didn't.
For the later camp MS promoted various flavours of Basic, which also had to do with Office and scripting an Works for DOS etc. But I suspect it was also a "theological" battle against Borland.
On the other platforms Pascal was succesful, but the Amiga and the Atari tanked. The Macintosh escaped that destiny barely. Maybe Swift is the new Pascal?
When they tried competing with Turbo Pascal, they initially didn't do it by trying to crush it with QuickBasic or QuickC but by introducing QuickPascal, which was source compatible with Turbo Pascal:
Actually, the record shows that Microsoft did very much try to crush Borland. While Microsoft did initially offer QuickPascal and embraced it (had no choice because of Pascal's popularity), Borland crushed them with Turbo Pascal 5.5 (1989) that had their version of Apple's Object Pascal (created in 1986) extensions. From Turbo Pascal 5.5 and up, it was using Borland's version of Object Pascal.
Note, C++ took a bit to take off, so didn't start to go toe to toe with Pascal until around 1992. C++ didn't get ISO until 1998. C# didn't happen until 2000. So Borland and Pascal were a thorn to Microsoft for years, not to mention Java (1995) and Sun.
Borland was eventually forced to sue Microsoft for unfair competitive practices. Microsoft was arguably playing dirty, and hired away many of Borland's top engineers. This included the creator of Turbo Pascal, Anders Hejlsberg. Who then Microsoft had him create C#, along with other ex-Borland engineers. In addition, there was all kinds of allegations during the 90s about Microsoft blocking or hiding APIs from Borland and negatively affecting their software.
Pascal was conceived as a language for learning programming, which I gather it does well. Perhaps the very features that prevent a student from shooting him/herself in the foot, get in the way when writing production code?
Pascal represented a worse compromise between to-the-metal programming and structured programming concepts than C did.
Now, arguably, you would say that some of the abstractions offered were reasonable tradeoffs, but at the time, things like the nature of strings and the second class support for pointers and the difficulty of (and awkward syntax for) memory management meant that it was fundamentally limited in applicability.
As someone who started their computer science studies with Pascal and then switched to C (I use C for comparison because it was the dominant programming language in 1990s computer science programs) , I can say that C just offered more to the aspiring software developer. For most people who coded in the 90s Pascal meant Turbo Pascal. While the language itself was great, MS-DOS where it ran not so much.
Especially when you compared MS-DOS to Unix (I say Unix because this was before Linux was dominant) systems which most computer science students were being introduced to at the time. With C you got access to all the Unix dev tools and you could do Unix systems programming. I think too a lot of young computer science students go through a phase of all things difficult are good and C on Unix made for a great learning opportunity.
Speaking as myself, the problem was the ecosystem not the language per say. I think for most of us it isn't even a contest between MS-DOS or Unix.
There are so many varied responses here but only ones like this make sense. Unix's language was C. Eventually, windows' API would be C. Then the rest would simply be history.
Surprised there isn't a book on this that explains it.
Turbo Pascal was a very fast compiler, written in assembler.
I'm a Delphi developer, and have spent about 24 of the past 36 years programming in Pascal. The Delphi XE7 compiler (now about 8 years old) can on a one year old Lenovo laptop with 16 GB RAM compile 1.35 million LOC (in 80 different files) in 11 seconds. The 64-bit compile takes roughly twice as long.
One of the design features of Pascal was a one pass compile which explains the speed. Note also that the Delphi/Turbo Pascal compilers are smart and discard all unused code.
Pascal was super popular for applications development on the original 68k Macs, Amigas and Atari ST's. I don't know if these machines fall into your "extremely tiny" envelope but we're talking 68000 @ 7 MHz with usually 512K or maybe 1M of RAM.
A little later, Turbo Pascal ran like greased lightning on a 386 or 486 box. There was really nothing else like it, which is partly why it enjoyed such immense popularity.
The line between Pascal and Object Pascal is very small. Some people might be thinking of the relationship between C and C++, but it is a different situation with Pascal and Object Pascal.
Object Pascal is an extension of Pascal. For instance, many of Apple's Object Pascal extensions were incorporated into Turbo Pascal. From Turbo Pascal version 5.5 and up, it is Borland's version of Object Pascal. You can use Objects and do OOP in Turbo Pascal.
Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains were competing and gaining critical mass:
TP 3.0 generated COM files (near code, near data, far heap-allocated data).
TP 4.0 generated EXE files (far code, near data, far heap-allocated data).
(the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)).
A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition).
Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm).
Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die.
[edit]
Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).
> Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings.
I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform.
(Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations.
My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++).
Borland Pascal compilers that I mentioned had exactly the same memory models than their C++ counterparts, specially the Windows 3.1 versions, there was no difference between TPW 1.5 and TC++ 3.1.
Borland Pascal 7.0 introduced support for protected mode.
> Borland Pascal compilers that I mentioned had exactly the same memory models than their C++ counterparts, specially the Windows 3.1 versions, there was no difference between TPW 1.5 and TC++ 3.1.
The Turbo C 1.0 User's Guide [1] page 244 (257) "Turbo C's Six Memory Models" lists these as tiny, small, medium, compact, large, huge. Also, page 220 (233) "The near, far, and huge Modifiers".
You claim that these same capabilities were present in TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5. Can you provide a reference for that?
There's no reason to believe that the language would be. Performance of the compiled code clearly depends on the quality of the compiler. Iirc, Turbo Pascal passed arguments to functions in registers when it could, C compilers back then didn't. Pascal's calling convention also used less space (hence it being an optimization option on some C compilers). On a 8 bit machine, that was important, less so on the 32 bit machines of the 90s.
In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code.
While I was fond of Turbo Pascal in its days, C was just so much more flexible.
You have to be careful by what you define as "success" and "failure". Many/most languages never really fail, they just become more and more niche.
So taking your question to be, why isn't Pascal used as much as some of the other languages from antiquity, like C, sh/bash/ksh/etc, or even Lisp, my opinion is that it was a combination of it being an "old" language and an interpreted language.
If you take a look at a timeline of programming language creation and usage [0], you see only a few compiled languages from before the 1980s survived and pretty much no interpreted languages did. The interpreted languages that did survive were mostly created in the late 1980s or early 1990s (Perl, Ruby, Python, Javascript).
I kind of take this to mean that the programmer productivity gained from interpreted languages was overshadowed by the computational speedup from their compiled counterparts during the pre 1980s time. When computer's computational speed finally caught up so that interpreted languages made more sense, Pascal was now 20+ years old and was overshadowed by the newer interpreted languages that took advantage of newer ideas in programming language design and/or were more feature rich in the programming language fads of those eras.
"sh" holds a kind of special place, as it's the workhorse of interacting with Unix-like environments, so it became pretty well entrenched. If you look at a lot of the more "modern" interpreted languages, you can see a lot of them were meant to supplant or complement tools specific to the command line or the command line itself (e.g. AWK -> Perl).
I don't claim to have any deep knowledge so all this is my very biased and weak opinion.
As far as I remember, Pascal admitted single-pass analysis. Such languages are especially amenable to being interpreted, i.e. immediately translated into executable actions (vs. some sort of bytecode).
I'm not familiar with "single-pass analysis", but I do know that Pascal can be compiled with a single pass recursive descent compiler, which made Turbo Pascal orders of magnitude faster than any other compiler at the time. In an era when C programmers could have coffee while waiting for things to compile, a pascal program hit enter, saw the results, and moved on.
C was also designed for single-pass compilation. Among many other things that people now dislike about C, this is why C requires forward declarations.
C compilers became slow because of the optimizations they accreted. Plus, I imagine it just wasn't a priority for the vendors in the way it was for Borland Pascal. I'm curious how the Borland C compiler compared in speed to their Pascal compiler and to other C compilers.
TinyC/tcc [1] still is a single-pass compiler and can go all the way to ELF files (or directly running via tcc -run) in a few milliseconds - sometimes an order of magnitude faster than the minimal start-up time of an interpreter like Python. But yes, gcc will generate faster running object code..a long standing trade off (like -O0 vs -O3, etc.).
Sure, not many programmers are today, sadly. I was referring to syntax analysis, or “parsing.” Some (admittedly, relatively simple) grammars allow syntax analysis to be done in one pass, so that an intermediate representation (e.g. in the form of an AST) becomes unnecessary; the latter is only needed if the grammar is complex and thus requires two or more passes for further analysis and/or machine code generation. Writing an interpreter for a command language is straightforward - exactly because analysis of its syntax can be done in one pass. Pascal is not a command language, but its grammar is (was?) still simple enough for many students of programming having gone through this (still highly recommended) exercise when Pascal was a teaching language.
Single-pass compile was a basic requirement back when your compiler only had access to a 64KB address space for its code and data. But it forces program organization into a clunky bottom-up sequential shape that just doesn't jive with the most basic concerns for larger-scale, professional software development. There's a reason why most of us don't code in FORTH, and why more recently Rust even chose the 'crate' rather than the single program file as its compilation unit.
All is true; note that “compile” is not the same as syntax analysis - because the former implies generation of code whereas the latter does not. (This is why we have two classes of language “translators”, one is compilers and the other, interpreters - although this distinction in modern practice has become somewhat blurry, because an interpreter may generate some sort of byte code which it then immediately executes.)
Wirth devised P-Code, only as means to ease porting the language into new platforms, it was the UCSD Pascal that based an whole system on it.
Most Pascal compilers were actually compiled, either directly, or by converting the above P-Code into machine code via an additional pass, e.g. Corvus Systems
Now wait a minute. If you say that JavaScript is an interpreted language, you would also have to call Java an interpreted language. Do you agree with that?
They both work in exactly the same way. Your source code is compiled to bytecode. That bytecode is then interpreted by a virtual machine. [1] That interpreter may then start a Just In Time compiler (JIT) to compile some of the bytecode down to machine code.
Other than implementation details, both languages work the same way.
Python also works like this, except it does not have the JIT. But it also has a compiler which generates bytecode.
And even if a JIT generates what we fondly call "machine code", that code is interpreted too! What the CPU executes internally looks nothing like the machine code that we see as programmers.
It's interpreters all the way down.
[1] I don't mean in the sense of something like VMware; I'm talking about a software virtual machine that executes an instruction set which we call bytecode.
> As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
Ignoring templates and generics, any Turing-complete language can be compiled down to bytecode or machine code.
So when developers talk about a “compiled language” they really mean if the standard tooling supports a compiler; and if programs are generally distributed already-compiled.
There are implications (good and bad) to programs that are already compiled, versus a just-in-time compilation via a runtime engine; which is largely transparent to developers and end-users.
GP's point is about languages through history. Compiled-to-machine-code V8 JS came out in 2008.
It's not just about compile-to-byte-code. It's about the "scriptyness" of that bytecode as well. Python bytecode operates at a much higher level of abstraction than machine code or even JVM.
Also we tend to classify languages with more dynamic type systems as "interpreted". It's a nebulous boundary. Not black-and-white whatsoever.
I've tried it in the early '90s when I was a noob. I couldn't get a simple program to work due to limitations of max 255-byte strings and fixed-length arrays. Google and StackOverflow didn't exist back then, so that was it. I went back to my pile of shareware floppies and found another language.
I used Turbo Pascal a lot as a teenager. Then I switched to Java and never looked back. For me the main reason was garbage collection.
String size was limited to 255 (non-Unicode) characters, array size needed to be specified at compile time, everything beyond this required manually allocating and unallocating memory... okay for school projects, but too much work for anything more complicated. The standard library didn'd support some simple functionality I had to write in assembler, such as detecting when a key is pressed and when it is released (how can you write an action game without this?), or using 256 colors (the standard library supported 16 colors at most).
The "smart" marketing move to rename a successful product and company to something obscure also didn't help. Why not call it "Visual Pascal" instead?
C had `malloc` and (real) pointers pretty much from day 1, and allows you to treat the result of `malloc` as an array.
Pascal's `new` did not let you do this, as I recall (it didn't even allow you to allocate a chunk of memory of arbitrary size... meaning that you can write `malloc` in C, but you can't write `new` in Pascal -- edit: before someone starts jumping on me with the claim that "Golly-Gee-Whiz Pascal '92" lets you do this, I am talking about Pascal, the language as designed by Niklaus Wirth, not about some bastardized non-standard extension. And yes, I fully concede that arbitrary pointers are dangerous, and are prone to producing nasty bugs. They also provide a whole lot of power).
Not that I recall, and even if it had, that wouldn't help, as there was no way to cast the resulting chunk of memory to whatever arbitrary type you needed it to be.
Yes. My TP programs were more than 50% inside asm...end blocks and would break even if you switched out the graphics card let alone tried them on a different architecture.
As I remember it, you could absolutely do all that in Pascal if you put your mind to it. But raw pointer manipulation was a bit more convoluted than in C so you usually resorted to inline asm. Today all that convolutedness might have been seen as "safety features" and the language marketed as a C-replacement. :)
Lack of portability: the 'standard' Pascal was very limited and each implementation added its own incompatible extension.
So when a free C compiler was released..
The seems to be an intractable problem. To survive a technology needs to be a commodity, but for a product to succeed the business needs lockin. So there is no growth around standards by people making money off of them.
Basically Turbo Pascal overshadowed all other Pascal dialects and then Borland got greedy, decided that Fortune 500 were going to be their main customers in detriment of the small dev shops.
Additionally Anders got fed up with the ongoing culture and finally accepted the invitation of former ex-colleges to join Microsoft.
So J++ was born, then .NET, and most of the folks on Windows just moved from Delphi into C#.
> and then Borland got greedy, decided that Fortune 500 were going to be their main customers in detriment of the small dev shops.
AIUI, that only happened very recently, well past the C# thing and perhaps only after the change from Borland to Embarcadero. For a long time, Delphi was actually a very reasonably accessible and effective competitor to Visual Basic.
They were "Inprise" for a while in there, too. I think the "Inprise" crap was where they took their finger off the button. "Sure, let's drop a name that pretty much every working programmer associates with quality tooling and start using a bland, corporate-speak name that no one has ever heard of. What could possibly go wrong?"
Inprise sounds like a name out of Mike Judge's Office Space.
They eventually figured this out and changed back to Borland, but by then it was too late.
Borland/Inprise/Embarcadero with high and then prohibitive prices put multiple nails in the Pascal coffin, but it fate was predetermined even before this.
Pascal occupies roughly the same niche as C. C is the language in both Unix and DOS/Windows were written which defined it success.
C was chosen by Microsoft for DOS and later for Windows - using it for app development was the path of the least resistance (Visual C, then Visual Studio, API for C/C++, Documentation examples in C/C++).
C is the language of Unix, it was used for kernel, user-space and most 3rd party apps. History of open-source and Unix is connect. It's not an accident that the first open source compiler which become popular and widely used (GCC) was a C compiler.
Once C because "an official" language for both Unix and Windows Pascal had no chances.
> C was chosen by Microsoft for DOS and later for Windows
Maybe for Windows (but then again, PASCAL was the supported language for the Apple Mac in the same timeframe), but MS had both PASCAL and C compilers for DOS. (And of course BASIC compilers, plus whatever weird stuff their Fox Pro thing was about. No it was not a hypertext browser, just some weird programming system that I can't find more info about.) The early Windows 16-bit ABI was rather influenced by PASCAL conventions, which introduced some awkwardness when trying to code to it from C.
First versions (at lest 2.0 and older) indeed where written in Assembly. I've seen somewhere that later version used C, but now cannot find any information about this.
Studying electrical engineering starting 1985 our school used Pascal for first year and then ran with Modula 2 for subsequent years. In those days we were mostly on time share Vaxen, even as EE students only maybe 20% of students had any kind of PC or real computer at home.
As of now I can't remember exactly why, but it seemed obvious to me at the time C was the place to be going forwards, maybe because I was working part time doing embedded design, or I had turbo C and a copy of Microsoft C fell my way, I can't really remember, but I do remember feeling that Pascal and Modula 2 were both a relative dead end when it came to useful skills for future employment.
Same thing on Apple and Google platforms, not only Microsoft.
That is why learned to stick with platform vendor stacks instead of third party languages.
As long as the platform remains relevant the languages will stick around, e.g. Objective-C and Android Java, they might be "deprecated" but removing them would just kill the whole platform.
For identical reasons, I learned to stick with portable, more or less standardized languages, and never get sucked into proprietary walled gardens. People trying to keep up on new "frameworks" released every two years are wasting their short lifetimes chasing phantoms.
"This was, of course, partially of Wirth's own making". … "He refrained from ... names such as Pascal-2, Pascal+, Pascal 2000, but instead opted for Modula and Oberon".
167 comments
[ 2.7 ms ] story [ 215 ms ] threadMostly companies just want to use what everyone else is using to ensure there's broad support and to make individual programmers easier to hire and fire.
But there's nothing stopping you from using it now if you want to. Personally, I quite like Object Pascal.
Free Pascal: https://www.freepascal.org/
Lazarus: https://www.lazarus-ide.org/
Delphi: https://www.embarcadero.com/products/delphi
Back to the site on my laptop and I look for the two things I want to see up front when deciding whether I'm interested in dipping a toe into a new programming language:
1: What are its selling points?
2: What does the syntax look like.
Nothing at all there to give me any info. Just a load of text outlining the differences between the latest point versions. So I click on 'Documentation' thinking there might be a 'Quickstart Guide' or something of that ilk there, that will give me some of the info I want. Nope. Just various in-depth User Guides as downloadable PDFs or HTML versions.
OK. Let's try the HTML version. I click on that and the entire screen fills up with a massive index of all the chapters and sub-sections in the guide. None of them called anything remotely welcoming like 'Start Here' or 'Quickstart'
Oh, and not that it's strictly necessary. But the only visuals I saw on my abortive mission onto that website were a tiny badly cut-out clipart picture of a cheetah [the project icon?] at the top of the front page and a couple of other nondescript icons at the bottom, one of which was a broken link.
Pascal may be the best programming language in the world and 'fashion' may have played some part in its alleged demise. But some people [and projects!] don't exactly do themselves any favours by actually making an effort to sell themselves, do they?
Sure, maybe check https://cppreference.com/ on your phone too. C++ is a popular language and has modern updates all the time, as you can see on that very site, yet the top reference site has a non-responsive design arguably "stuck in 1990s".
Judging an old and mature project by whether its website design is updated to 2020s is shallow.
The "design" in terms of how it looks is, as you say, irrelevant. The "design" in terms of what information is conveyed, is deeply flawed in the sense that it's excellent for anyone who's already using the compiler - and completely useless for someone swinging by wondering about getting into Pascal in 2021. I.e. "preaching to the choir", as they say.
A fair amount of why websites started to also look different over time, is they structurally altered themselves to convey additional information. For example, a lot of programming language/compiler sites have images at the top now giving "strangers" a quick glimpse at the syntax.
It's all about crafting your website so it's useful to complete strangers, rather than only useful to the existing in-crowd.
Do better! Be better! Let's start over again on a different foot.
You might as we be asking if this is the right language to wear this season or if your bum looks big in this compiler.
If that's not enough for you upon which to base your decision on whether or not to purchase, then you're an incredibly shallow and fashion-led reader
[Feel free to create similar analogies. For example; a supermarket in which every tin, packet and bottle has a plain white label with 'Food' written on the front and nothing but an ingredients list on the back]
C had small edge in utility at first, then it ballooned into huge base of programmers. Familiar syntax can sell completely new language with different semantics. Choosing syntax from C has lead to success of C++, Java, JavaScript, JSON, ... despite completely different semantics.
Pascal and successors Modula Oberon and Ada with similar syntax features did not succeed. It had little to do with language features, ease to learn (except surface syntax) or semantics.
Turbo Pascal was in it's day a joy to work with as a language - clean, fast (compilation and runtime), good documentation, decent tooling.
Let's just say that the ability to include inline assembly language wasn't exactly a feature of Wirth's original Pascal.
The best feature of the classic Borland languages was the debugger, IMO.
FPC can even compile to JavaScript and it works with WebGL https://github.com/genericptr/Pas2JS-WebGL#pas2js-webgl
But decades ago is precisely the timeframe we're talking about here.
Pascal lost to C for the reasons Kernighan mentions (among others), which is the question the OP was asking.
Also considering that most of the complains were fixed in Modula-2, made available initially in 1978.
And, the article was about Pascal, not about Modula-2. Are you wishing he had also written an article about Modula-2 that you could also critize, maybe for not being about Modula-3 or Oberon instead?
When Java came out in 1996 it became an overnight juggernaut in application development. Java had a ton of hype when it was still in beta in 1995 and TIME magazine even listed it as one of the best products of the year--when it wasn't even released yet.
Microsoft poached Anders Hejlsberg, the primary language designer of Turbo Pascal and Delphi, from Borland in 1996 to have him work J++ their variant of Java. J++ followed the Sun Java spec with a few deviations, but it was just another testament to how quickly Java was taking over.
Borland was now competing with something that was free and they needed to pivot and well...they didn't.
Random articles for further reading: https://en.wikipedia.org/wiki/Anders_Hejlsberg
https://en.wikipedia.org/wiki/Visual_J%2B%2B
http://content.time.com/time/subscriber/article/0,33009,9839...
https://en.wikipedia.org/wiki/Turbo_Pascal
https://stackoverflow.com/questions/8460037/list-of-delphi-l...
Look at which one is being used to this day to write essentially every modern operating system, and even the interpreters and compilers for other languages. JavaScript engines are written in C, not Pascal.
I think it obviously did lose, though judging from the moderation it clearly still has some fanatical followers.
Both Turbo Pascal and Object Pascal had so many extra non-standard and un-Pascal-like features that they were barely even the same language.
As I mentioned in another comment, allowing you to write bare assembly language inline wasn't exactly a feature of the original Wirth Pascal. The analogy I used at the time was that (Wirth) Pascal was like a pair of blunt-pointed kindergarten scissors, while C was more like a chainsaw. Borland added enough non-standard features to make it more like maybe a kitchen knife, but in the long run that still wasn't enough.
Which one? Unless you forgot to type ++.
In any case, it's not inc(Pascal), now, is it?
On what basis do you say this? Was Turbo Pascal, say, leagues ahead of Turbo C?
Arguably what saved Pascal/Object Pascal was the open-source projects of Free Pascal/Lazarus and PascalABC (popular in Russia). Plus there were huge fans of Turbo Pascal, who got it released as freeware, as Borland had switched to selling the Delphi IDE.
This combination (Free Pascal/Lazarus, freeware Turbo Pascal, PascalABC, etc...) of open-source freeware Pascal eventually put pressure on Embarcadero to release the free Delphi Community Edition (2018). That was 5 to 10 years late in the game. A lot of user base and previous strong fans had significantly diminished.
However, it does appear that Object Pascal has found a decent level, at presently between the top 15 to 20 programming languages (were it was between top 1 to 10 in the 80s and 90s). It is possible for Object Pascal to see a bit of a resurgence, based around the free open-source dialects of Pascal and Embarcadero's strong push to put Delphi in schools (example- Turkey bought 1 million licenses for their schools or South Africa replacing Java with Delphi).
I am not a Pascal expert, but I believe that arguments 3, 4, 7 and 8 are not valid any more, possibly they were not even valid a decade later, which would invalidate the whole essay.
And some of the "advantages" of C over Pascal, presented by Kernighan, are exactly the origin of many CVEs we have nowadays, such as unbounded arrays and unverified casting of types.
I really like Kernighan's code and texts, but it is important to remember he is really biased in this text, and hasn't provided any of the advantages of Pascal over C, except it is easier to learn.
I won't promote Pascal, but one can see that a language two years older than C has some language constructs [1] not seen even on modern programming languages! Kernighan, though, purposely left it all out of his evaluation.
[1]: https://en.m.wikipedia.org/wiki/Pascal_(programming_language...
I don't know much about Pascal but it sounds really hard to do things which aren't supported by the development environment.
var age : integer; pascal
var age int - Go
var age : int - Swift
var age = 52; - Dart
var age: Int = 10 Kotlin
https://cdecl.org/
Also the main reason behind the religous war in C++ of west const versus east const.
Microsoft now got a couple of top devs on their C++ team that are on east const, so while we have about 25 years of Microsoft documentation, code samples and libraries using west const, the C++/WinRT team is now pushing for east const everywhere.
https://stackoverflow.com/questions/2660633/declaring-pointe...
But I think when Microsoft settled on C for Windows programming, Apple and others jumped on the bandwagon. And since the languages are actually very similar, I think that Pascal was mostly seen as irrelevant after that. It lacked a distinct niche apart from C.
Pascal was displaced by K&R C for mainstream work, which was soon supplanted by C90. C90 has been displaced from serious development work by various C++ versions, although it hangs on in restricted niches, for historical reasons, usually as C99 and sometimes C11. C++98 has been largely supplanted by C++11, which is beginning to be supplanted by C++17 and C++20.
It doesn't make sense to say that Pascal is alive when there is no one, anywhere writing code that could be compiled by any actual Pascal compiler, and no actual Pascal compilers for any current machine.
Object Pascal is an extension of Pascal, that adds OOP. It is much tighter than the relationship of C to C++. You can write Object Pascal procedurally, where it closely resembles ISO 1983 or 1990 Pascal.
By the way, there was a 1993 technical committee to add OOP to Pascal, which a lot comes from the various Object Pascal dialects. Be that as it may, the Borland/Embarcadero Object Pascal became the de facto standard. The other dialects of Object Pascal follows them.
To say nobody uses Pascal/Object Pascal is disingenuous. Clearly people use and pay for Delphi (Embarcadero), Oxygene (Rem Objects), and Smart Pascal. Free Pascal/Lazarus and PascalABC are open-source projects with over 20 year histories, so they are not going anywhere, and are very much used.
I learned Pascal in High Scool, in 98, where it was taught as a 'learning language'. Something to learn intro into programming and basic CS concepts, but then to move on into other languages for real work.
So, even in the 90s, it was not thought as a production level language. ADA was at the time, and of course Java was coming up in the scene as a replacement for C++ which was the default 'large programs' language.
Python and PHP were just starting to take off as the web was becoming popular.
Once the dust settled, ADA remained a niche language, and Pascal pretty much disappeared from school settings, as either Python or Java became the default languages for intro to programing.
There were once COBOL, FORTRAN, LISP, ALGOL, and BASIC, some since renamed to Fortran, Lisp, and Algol. Pascal was always Pascal. COBOL is still COBOL, and BASIC is still BASIC. "Visual Basic" is a wholly different language.
I doubt looking like Pascal helped these more powerful languages gain popularity.
(Measurement unit joke.)
(Another one.)
(Another one, but of a riddle)
During the years where the mainstream office business landscape transitioned from DOS to OS/2, no wait, Windows, broadly speaking there where two types of application programmers. Those that used C or C++ and those that didn't.
For the later camp MS promoted various flavours of Basic, which also had to do with Office and scripting an Works for DOS etc. But I suspect it was also a "theological" battle against Borland.
On the other platforms Pascal was succesful, but the Amiga and the Atari tanked. The Macintosh escaped that destiny barely. Maybe Swift is the new Pascal?
https://en.wikipedia.org/wiki/Microsoft_Pascal
When they tried competing with Turbo Pascal, they initially didn't do it by trying to crush it with QuickBasic or QuickC but by introducing QuickPascal, which was source compatible with Turbo Pascal:
https://winworldpc.com/product/quickpascal/1x
Note, C++ took a bit to take off, so didn't start to go toe to toe with Pascal until around 1992. C++ didn't get ISO until 1998. C# didn't happen until 2000. So Borland and Pascal were a thorn to Microsoft for years, not to mention Java (1995) and Sun.
Borland was eventually forced to sue Microsoft for unfair competitive practices. Microsoft was arguably playing dirty, and hired away many of Borland's top engineers. This included the creator of Turbo Pascal, Anders Hejlsberg. Who then Microsoft had him create C#, along with other ex-Borland engineers. In addition, there was all kinds of allegations during the 90s about Microsoft blocking or hiding APIs from Borland and negatively affecting their software.
Now, arguably, you would say that some of the abstractions offered were reasonable tradeoffs, but at the time, things like the nature of strings and the second class support for pointers and the difficulty of (and awkward syntax for) memory management meant that it was fundamentally limited in applicability.
Especially when you compared MS-DOS to Unix (I say Unix because this was before Linux was dominant) systems which most computer science students were being introduced to at the time. With C you got access to all the Unix dev tools and you could do Unix systems programming. I think too a lot of young computer science students go through a phase of all things difficult are good and C on Unix made for a great learning opportunity.
Speaking as myself, the problem was the ecosystem not the language per say. I think for most of us it isn't even a contest between MS-DOS or Unix.
Surprised there isn't a book on this that explains it.
Borland compilers were basically the same, and if one cared about speed, the only way to achieve it was hand written Assembly.
I'm a Delphi developer, and have spent about 24 of the past 36 years programming in Pascal. The Delphi XE7 compiler (now about 8 years old) can on a one year old Lenovo laptop with 16 GB RAM compile 1.35 million LOC (in 80 different files) in 11 seconds. The 64-bit compile takes roughly twice as long.
One of the design features of Pascal was a one pass compile which explains the speed. Note also that the Delphi/Turbo Pascal compilers are smart and discard all unused code.
A little later, Turbo Pascal ran like greased lightning on a 386 or 486 box. There was really nothing else like it, which is partly why it enjoyed such immense popularity.
Turbo Pascal compiled fast. The generated code ran at more or less the same speed as output of random other compilers.
Object Pascal is an extension of Pascal. For instance, many of Apple's Object Pascal extensions were incorporated into Turbo Pascal. From Turbo Pascal version 5.5 and up, it is Borland's version of Object Pascal. You can use Objects and do OOP in Turbo Pascal.
TP 3.0 generated COM files (near code, near data, far heap-allocated data).
TP 4.0 generated EXE files (far code, near data, far heap-allocated data).
(the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)).
A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition).
Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm).
Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die.
[edit]
Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).
And Turbo C 2.0 was quickly replaced by Turbo C++.
I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform.
(Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations.
My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++).
[1] https://en.wikipedia.org/wiki/Microsoft_Pascal
Borland Pascal 7.0 introduced support for protected mode.
The Turbo C 1.0 User's Guide [1] page 244 (257) "Turbo C's Six Memory Models" lists these as tiny, small, medium, compact, large, huge. Also, page 220 (233) "The near, far, and huge Modifiers".
You claim that these same capabilities were present in TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5. Can you provide a reference for that?
[1] http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...
In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code.
While I was fond of Turbo Pascal in its days, C was just so much more flexible.
So taking your question to be, why isn't Pascal used as much as some of the other languages from antiquity, like C, sh/bash/ksh/etc, or even Lisp, my opinion is that it was a combination of it being an "old" language and an interpreted language.
If you take a look at a timeline of programming language creation and usage [0], you see only a few compiled languages from before the 1980s survived and pretty much no interpreted languages did. The interpreted languages that did survive were mostly created in the late 1980s or early 1990s (Perl, Ruby, Python, Javascript).
I kind of take this to mean that the programmer productivity gained from interpreted languages was overshadowed by the computational speedup from their compiled counterparts during the pre 1980s time. When computer's computational speed finally caught up so that interpreted languages made more sense, Pascal was now 20+ years old and was overshadowed by the newer interpreted languages that took advantage of newer ideas in programming language design and/or were more feature rich in the programming language fads of those eras.
"sh" holds a kind of special place, as it's the workhorse of interacting with Unix-like environments, so it became pretty well entrenched. If you look at a lot of the more "modern" interpreted languages, you can see a lot of them were meant to supplant or complement tools specific to the command line or the command line itself (e.g. AWK -> Perl).
I don't claim to have any deep knowledge so all this is my very biased and weak opinion.
[0] https://ccrma.stanford.edu/courses/250a-fall-2005/docs/Compu...
C compilers became slow because of the optimizations they accreted. Plus, I imagine it just wasn't a priority for the vendors in the way it was for Borland Pascal. I'm curious how the Borland C compiler compared in speed to their Pascal compiler and to other C compilers.
[1] https://github.com/TinyCC/TinyCC
Sure, not many programmers are today, sadly. I was referring to syntax analysis, or “parsing.” Some (admittedly, relatively simple) grammars allow syntax analysis to be done in one pass, so that an intermediate representation (e.g. in the form of an AST) becomes unnecessary; the latter is only needed if the grammar is complex and thus requires two or more passes for further analysis and/or machine code generation. Writing an interpreter for a command language is straightforward - exactly because analysis of its syntax can be done in one pass. Pascal is not a command language, but its grammar is (was?) still simple enough for many students of programming having gone through this (still highly recommended) exercise when Pascal was a teaching language.
Most Pascal compilers were actually compiled, either directly, or by converting the above P-Code into machine code via an additional pass, e.g. Corvus Systems
https://en.wikipedia.org/wiki/Corvus_Systems
For some reason, Pascal sat in my mind as an interpreted language. Maybe my whole arguments falls apart then.
They both work in exactly the same way. Your source code is compiled to bytecode. That bytecode is then interpreted by a virtual machine. [1] That interpreter may then start a Just In Time compiler (JIT) to compile some of the bytecode down to machine code.
Other than implementation details, both languages work the same way.
Python also works like this, except it does not have the JIT. But it also has a compiler which generates bytecode.
And even if a JIT generates what we fondly call "machine code", that code is interpreted too! What the CPU executes internally looks nothing like the machine code that we see as programmers.
It's interpreters all the way down.
[1] I don't mean in the sense of something like VMware; I'm talking about a software virtual machine that executes an instruction set which we call bytecode.
It just so happens that the “machine” is an abstraction of a CPU.
Interpreted Javascript doesn’t fit this bill. If compiled to web assembly then it would.
> As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
So when developers talk about a “compiled language” they really mean if the standard tooling supports a compiler; and if programs are generally distributed already-compiled.
There are implications (good and bad) to programs that are already compiled, versus a just-in-time compilation via a runtime engine; which is largely transparent to developers and end-users.
It's not just about compile-to-byte-code. It's about the "scriptyness" of that bytecode as well. Python bytecode operates at a much higher level of abstraction than machine code or even JVM.
Also we tend to classify languages with more dynamic type systems as "interpreted". It's a nebulous boundary. Not black-and-white whatsoever.
String size was limited to 255 (non-Unicode) characters, array size needed to be specified at compile time, everything beyond this required manually allocating and unallocating memory... okay for school projects, but too much work for anything more complicated. The standard library didn'd support some simple functionality I had to write in assembler, such as detecting when a key is pressed and when it is released (how can you write an action game without this?), or using 256 colors (the standard library supported 16 colors at most).
The "smart" marketing move to rename a successful product and company to something obscure also didn't help. Why not call it "Visual Pascal" instead?
This also holds true for C until C99, I think.
Pascal's `new` did not let you do this, as I recall (it didn't even allow you to allocate a chunk of memory of arbitrary size... meaning that you can write `malloc` in C, but you can't write `new` in Pascal -- edit: before someone starts jumping on me with the claim that "Golly-Gee-Whiz Pascal '92" lets you do this, I am talking about Pascal, the language as designed by Niklaus Wirth, not about some bastardized non-standard extension. And yes, I fully concede that arbitrary pointers are dangerous, and are prone to producing nasty bugs. They also provide a whole lot of power).
C compilers available for 8 and 16 bit computers weren't even fully K&R C.
Additionally Anders got fed up with the ongoing culture and finally accepted the invitation of former ex-colleges to join Microsoft.
So J++ was born, then .NET, and most of the folks on Windows just moved from Delphi into C#.
AIUI, that only happened very recently, well past the C# thing and perhaps only after the change from Borland to Embarcadero. For a long time, Delphi was actually a very reasonably accessible and effective competitor to Visual Basic.
https://www.computerworld.com/article/2589416/inprise-to-cha...
Inprise sounds like a name out of Mike Judge's Office Space.
They eventually figured this out and changed back to Borland, but by then it was too late.
Pascal occupies roughly the same niche as C. C is the language in both Unix and DOS/Windows were written which defined it success.
C was chosen by Microsoft for DOS and later for Windows - using it for app development was the path of the least resistance (Visual C, then Visual Studio, API for C/C++, Documentation examples in C/C++).
C is the language of Unix, it was used for kernel, user-space and most 3rd party apps. History of open-source and Unix is connect. It's not an accident that the first open source compiler which become popular and widely used (GCC) was a C compiler.
Once C because "an official" language for both Unix and Windows Pascal had no chances.
Maybe for Windows (but then again, PASCAL was the supported language for the Apple Mac in the same timeframe), but MS had both PASCAL and C compilers for DOS. (And of course BASIC compilers, plus whatever weird stuff their Fox Pro thing was about. No it was not a hypertext browser, just some weird programming system that I can't find more info about.) The early Windows 16-bit ABI was rather influenced by PASCAL conventions, which introduced some awkwardness when trying to code to it from C.
Eventually costing them $2bn
The wording here makes it almost sound like reluctance, but wasn't there a rather substantial signing bonus to go along with that?
As of now I can't remember exactly why, but it seemed obvious to me at the time C was the place to be going forwards, maybe because I was working part time doing embedded design, or I had turbo C and a copy of Microsoft C fell my way, I can't really remember, but I do remember feeling that Pascal and Modula 2 were both a relative dead end when it came to useful skills for future employment.
Microsoft tech stack is the exception, but it's because Microsoft controls Windows the OS.
That is why learned to stick with platform vendor stacks instead of third party languages.
As long as the platform remains relevant the languages will stick around, e.g. Objective-C and Android Java, they might be "deprecated" but removing them would just kill the whole platform.
Poor brand management —
"This was, of course, partially of Wirth's own making". … "He refrained from ... names such as Pascal-2, Pascal+, Pascal 2000, but instead opted for Modula and Oberon".
"Pascal and its Successors" 2002
https://www.swissdelphicenter.ch/en/niklauswirth.php
" … the programming language Component Pascal which is a superset of the language Oberon-2 developed by Niklaus Wirth."
https://blackboxframework.org/