Ask HN: Why Did Pascal Fail?
I’m puzzled.
A typed, compiled language easy to program.
Why did Pascal fade instead of growing?
A typed, compiled language easy to program.
Why did Pascal fade instead of growing?
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?
Borland started raising the prices of their compilers to the point that the hobbyist could no longer justify it, and market share fell accordingly.
Since Turbo Pascal/Delphi was the only Pascal with a complete library, the fortunes of the language went with it.
There is a fairly reasonable open source Pascal these days, the Free Pascal project, on top of which is built a GUI IDE, Lazarus. They try to maintain feature parity with Delphi, which is now far, far too expensive, they do a fairly good job with it.
It is possible to crank out a Windows GUI program in Lazarus pretty darned quickly. It's my preferred programming environment to this day.
Edit: it is funny that Lazarus is cross platform, while Delphi still only runs on Windows (although it can compile to other platforms).
Borland fixed that, and brought Pascal to parity with C. (Maybe even ahead of C, because Pascal had better type checking.) But then (or soon after), there were a variety of C compilers. Once Borland raised their prices, some of them were less expensive than Turbo Pascal. (Once gnu came out, some of them were free.)
Why was the original Pascal annoying to use? See Brian Kernighan's "Why Pascal Is Not My Favorite Programming Language". (Despite its reputation, it's not a hit piece. And, as someone who had to use the original, unextended Pascal, I can tell you that every word of it is true.)
Pascal was written by a university guy trying to create a teaching language. And he succeeded - it was a very good teaching language. C was written by a couple of lab guys trying to write real programs, not classroom exercises. Their language was better at that than Pascal was.
My only memory of the actual language experience (i.e. besides the card punch) was being marked down on an assignment for using an implicit conversion that the compiler coded personally by Niklaus Wirth permitted. I had coded it with the explicit conversion, first, and then took it out because the compiler said I didn't need it.
Pascal was better than C in exactly one respect: it used a post-fix pointer dereference operator. C could have defined a unary postfix ->.
C++ could still do that, entirely backward-compatibly, and have it call unary operator*().
https://www.lysator.liu.se/c/bwk-on-pascal.html
There is a TL;DR at the end.
It is bizarre or demonstrates a lack of knowledge to take a document from 40 years ago, and then pretend nothing changed. People wouldn't do that with C or C++, so why do it to Pascal/Object Pascal?
Take a look at the below link, Which addresses most points outlined in the paper, in terms of modern dialects of Pascal.
https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pr...
Something else to be said about Kernighan and that "hit piece" paper, was that AT&T Bell Laboratories was behind it. People should realize that AT&T was pushing C and then C++, so were very much trying to take down Pascal. This is a document that was "weaponized" to be used against competition, and very oddly, is still being used as such.
Below is a "blow by blow" comparison of C VS Pascal, using a 1989 version of C versus a 1982 version of Pascal (thus excluding Turbo Pascal and Apple's Pascal). With C being the later version, Pascal still compared favorably.
https://en.wikipedia.org/wiki/Comparison_of_Pascal_and_C
Furthermore, Pascal evolved into Object Pascal (created by Apple in 1986, from a forerunner named Clascal in 1983). Borland very soon afterwards (also 1986) added similar Object Pascal extensions to their Turbo Pascal.
Arguably Apple's Object Pascal and Borland's Turbo Pascal from the late 80s were the more feature rich and versatile language from that point, where only C++ could kind of compare (and it would have to play catch up). C# (born 2000) and Java (born 1995) didn't exist yet. If they compared the Object Pascal of 1989 to the C of 1989, a good case would be made for Pascal domination.
Here is a highly restrictive comparison of Object Pascal versus C (using C99). Object Pascal is very much comparable to both C and C++ combined. https://en.wikipedia.org/wiki/Comparison_of_Object_Pascal_an...
In regards to Brian Kernighan, it was a "hit piece". That paper had AT&T behind it (that's a smoking gun), where C and C++ were created. AT&T was actively competing against and trying to push Pascal out of the way.
It was also AT&T that pushed the C and C++ language dominance in the market, because they were behind Unix too. At that time, AT&T was one of the biggest companies in the world. As an American company, they had critical relationships and connections with other American tech companies, as well as lots of money. Something a single Swiss computer scientist (Wirth) didn't.
Niklaus Wirth, creator of Pascal and consultant on the Object Pascal creation team, has stated many times he embraced Pascal being used commercially too. His goal was both a well structured language for teaching and business.
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.
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.
http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pasc...
Edit: I said I was a bit incredulous of the claims. If true, those would be bad features.
All Pascal dialects, and the Extended Pascal standard that improved the original one, had the array of <type> construct that allows you to query for the actual bounds.
Type conversations were also available, again in all dialects.
Naturally, those variants were ignored, as Kernighan had a message to sell.
https://www.folklore.org/StoryView.py?project=Macintosh&stor...
http://preserve.mactech.com/articles/mactech/Vol.02/02.12/Ob...
Those variants were "ignored" because they largely didn't exist. Kernighan's essay was written in 1981. The first release of Turbo Pascal wasn't until 1983. The Extended Pascal standard wasn't released until 1990.
And then there is the detail that Modula-2 was released in 1978, exactly with the goal to fix all original Pascal issues for systems programming.
If there had been enough demand to also do a Modula version of the book, he might have written a more favorable article about Modula afterwards.
And based on Mesa, used at Xerox PARC.
Then again, ignoring systems languages outside Bell Labs seemed to have been a thing back in the day.
https://vintageapple.org/apple_ii/pdf/Apple_Pascal_1980.pdf http://www.bitsavers.org/pdf/dec/vax/lang/pascal/AA-H485A-TE...
Look in the acknowledgement section of his essay, and no clarification is given to the extent of research on other variants of Pascal outside of the original Pascal of 1973, and references to documents such as "An Assessment of the Programming Language Pascal" of 1975, and "Pascal User Manual and Report" of 1978. Those documents were ISO/IEEE related, to help promote an ISO standard of Pascal, versus businesses using Pascal in the commercial space like Apple and DEC (later Compaq) were doing (both major companies).
Further damning of the type of assessment that Kernighan was engaging in, was him referencing other AT&T Bell Lab comparisons between C and Pascal.
AT&T is not an innocent 3rd party, but where C and C++ were created and having a huge interest in pushing those languages, along with Unix in business and universities (which they did).
Kernighan's essay (on 1970s era Pascal), should have been seen as biased and influenced by or promoting the commercial interests of AT&T (promoting their C and Unix). It should not have been taken seriously by anyone beyond 1989, where Pascal became Object Pascal. Apple created Object Pascal in 1986 (in consultation with Niklaus Wirth), and then Borland added Object Pascal extensions to the very successful Turbo Pascal 5.5 (allowing it to do OOP too). Nearly everything in his paper was clearly and already addressed by 1989 and even various ones when he published it in 1981.
Kernighan also had plenty of time to retract or update the statements he made in his "hit piece" paper, to reflect on the ISO 1990 Pascal or the commercially used variants of Pascal such as Object Pascal. Yet, he never did so. Comparatively, it's not like C or C++ stayed the same language as it was in the 1970s, so it shouldn't be expected that Pascal is suppose to not change.
And, all Pascal dialects had some construct. They had different constructs. If you wanted to be portable, you couldn't use any of them (until the Extended standard came out). Kernighan notes those extensions, but does not accept them as a solution because of their non-portability. You may think that he is more dismissive than he should be here, but at that time, C was considerably better on code portability.
And when you say that Kernighan was acting as a propagandist, I wonder whether you are being one. You certainly seem to have a message to sell when it comes to Pascal vs C...
Nor that Modula-2, designed to fix all those issues with ISO Pascal, was in use since 1978.
Yeah, whatever.
Implementations for x86 had a mess of different pointer types, but to build the same program for a non-crippled CPU you could #define the extra keywords to the empty string.
Kernighan wrote that paper after writing "Software Tools In Pascal", and finding it considerably harder than it should have been to write that kind of thing in Pascal. (The predecessor book, "Software Tools", was written in RATFOR, and Pascal should have been miles better to write software in.)
In this book, they (Kernighan and Plaugher) tried to write code that would work in Pascal, not just in one dialect of it. That is, portability was essential to the code they were writing for the book. That may have lead to a greater emphasis on portability in Kernighan's paper than one might think warranted by the general situation.
It is also weird to put Pascal into a box, as if the language is not allowed to evolve/change. C and C++ is not the same language that it was 20 years ago. Doesn't make sense to have this expectation for Pascal.
In addition, you can't gloss over that the different dialects of Pascal addressed issues. For those that program with Pascal, these differences are often minor or considered a plus. You can choose the dialect that best suits your needs.
Many would say that it is unfair to bring up Kernighan's 40 year old paper (from 1981). Things in the Pascal world changed almost immediately after it was published.
Turbo Pascal came out in 1983, and addressed various issues. Then Apple created Object Pascal in 1986, addressing even more. Then came Delphi (1995) and Free Pascal/Lazarus (1997).
Take a look at the below link, Which addresses most points outlined in the paper, in terms of modern dialects of Pascal/Object Pascal.
https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pr...
Arguably, Kernighan created a "hit piece" paper for AT&T Bell Laboratories (they are on the document).
AT&T was pushing C and then C++, so were very much trying to take down Pascal. This is a document that was "weaponized" to be used against competition, and very strangely, it still being used as such when most of the points presented are no longer relevant.
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
" … the programming language Component Pascal which is a superset of the language Oberon-2 developed by Niklaus Wirth."
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.
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
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.
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.
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:
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.
(Measurement unit joke.)
(Another one.)
(Another one, but of a riddle)
C compilers available for 8 and 16 bit computers weren't even fully K&R C.
Still... when I see Lua, Visual Basic or Julia even now I think: this is not going to make it, it doesn't stroke the programmers ego. I'll be happy to be proven wrong.
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).
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.
Free Pascal: https://www.freepascal.org/
Lazarus: https://www.lazarus-ide.org/
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.
>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...
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]
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
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...
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.
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.
Now I'm teaching freshman software engineering students and we use Python. I personally like it but some of it is pretty idiosyncratic. It's going to be a more difficult transition from Python to compiled languages like C/C++ than it was for Pascal. The big difference is Python is used in the industry, so knowing it is worth more than knowing Pascal back in the day.
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.
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.
Object Pascal is a hybrid language, having an even tighter relationship to Pascal than does C++ to C. You can easily write it without using OOP or classes (or newer things like generics), so that it closely resembles the ISO 1983 or 1990 Pascal.
Pascal is still widely used (categorized as a top 15 to 20 language). That it is not as popular as certain corporate backed C family languages (C# or Java), doesn't mean failure. Saying Pascal "failed", is very deceptive language or arguably having an agenda. That would be like saying Go, Rust, or Swift "failed" because they aren't as popular as C# or Java (with the big corporate money behind it). Keep in mind that Object Pascal is as or more popular than those languages.
Object Pascal was created and used by Apple in the 80s and 90s (used for OS and app development). They preferred Object Pascal over C (does that mean C "failed"). The reason Apple dropped Object Pascal years later for a combination of C++ and Objective-C was partly because they moved from the Motorola 68000 chips to IBM's PowerPC and partly because Symantec's (Think Pascal) and Metrowerks (CodeWarrior) Object Pascal products had beat Apple's Macintosh Programmer's Workshop Pascal compiler in the market. As part of a series of consolidation and strategic moves, Apple moved on to Project Builder IDE that was developed by NeXT (who they bought) and began preferring Objective-C (does that mean C++ "failed"). After the move to PowerPC, a lot of Mac developers were using Metrowerks Object Pascal compiler (CodeWarrior) to port and develop applications. Borland's Turbo Pascal joined the party for a time, but was more successful on Windows. Use of CodeWarrior's Pascal compiler for Macs continued until around 2000 or so.
Object Pascal was used in IDEs and compilers by many companies in the 80s and 90s, among them is Borland (then later to Embarcadero) which shipped Turbo Pascal and Delphi (both very successful well known products) and it was quite popular in the 90s and early 2000s. During this time period, Pascal and then Delphi (the name of the IDE using Object Pascal) was often rated between 1 to 10 in language popularity. Many would say that is success.
Arguably the reduction in use and popularity comes from mishandling by Borland, who got way too greedy, and started charging extravagant prices beyond anything normal people could afford. They abandoned their common user base for enterprise customers, along with getting into an all out corporate war with Microsoft (who appears to have been trying to get rid of competitors on their OS going against Visual Basic and used for app development). This battle concluded with Microsoft picking off Borland's top engineers (including Anders Hejlsberg, who created C#), and Borland being bought by Embarcadero. However, years later, things have "stabilized" with Embarcadero releasing a free Community Edition of Delphi. Along with Free Pascal/Lazarus (a compiler originally written with Turbo Pascal by the way in 1997) slowly becoming more well known, to include Oxygene (Rem Object's Pascal IDE) and PascalABC (numerous YouTube videos in Russian on it) also starting to appear more on the common radar.
Delphi (has academic licenses) and Turbo Pascal (which is freeware now) was and is still used for teaching students their first programming language in various schools, depending on country. PascalABC (open-source) has been taught in Russian schools since the early 2000s. Free Pascal/Lazarus (open-source) has also been popping up in various school systems around the world as well.
Object Pascal has many dialects. Most notable: Delphi (Embarcadero), Oxygene (Rem Objects), Smart Pascal (transpiles to JavaScript), Free Pascal/Lazarus (open-source), PascalABC (open-source and .NET), and DWScript (open-source).
I doubt looking like Pascal helped these more powerful languages gain popularity.
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.
There you have 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++).
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.
The thing about these early language designs is that it's really only their "toy" language subset that's truly easy to program. Once you try and extend a comparatively simple language like PASCAL to deal with all the complexities of truly large-scale software development you end up with something not unlike ADA, where the verbose syntax just gets in the way of surveying a complex program effectively.
I think Go and Rust both made very good syntactical choices in picking just a handful of very short mnemonic keywords (and symbols like {}) for things that simply have to be foundational language features, while making longer names fully idiomatic for identifiers that are defined in the code.
Of course the PASCAL language family makes very different choices here (as do other languages, such as COBOL and BASIC). I'm not saying it wouldn't be cool in some way to see a language design with e.g. a Rust-like featureset and PASCALish syntax; I just don't think it would ultimately be easy to learn and use practically.