I think a large part of the problem was that standard Pascal wasn't really that great of a language other than for teaching. It only became useful when heavily extended as Turbo Pascal had done. Turbo Pascal was very successful and eventually morphed into Delphi which was also successful.
In the meantime standard K&R C was ubiquitous and anyone taking a CS degree would likely have learnt and used it. C's "close to the metal" approach was a good fit for the under-powered CPUs of the day.
Note that most of the early Turbo Pascal features were actually from UCSD Pascal and Apple's Object Pascal, only after Turbo Pascal 5.5, most of the features were from Borland, and then influenced by C++.
And people were seeing C in CS classes because it let you write the OS, which is part of what CS degrees wanted to teach. Pascal didn't really let you do that.
ISO Pascal not, ISO Extended Pascal, Concurrent Pascal USCD Pascal, Object Pascal certainly did, and several OSes do exist, that were written in them.
Ah, but Pascal dialects don't count.
In that case same applies to the C dialect, non ISO C compliant, full of compiler extensions as alternative to hand written Assembly, that is allowed in most kernels.
However the main point stands, most CS degrees used UNIX alongside the Lion's book, or Minix, thus strenghting C's position on this use case.
Where I worked, it was nothing in particular about the language (or at least the variant we used) itself. What happened was exactly what another comment said, quote:
"And then Unix happened. Every Unix system had a C compiler; and C ate Pascal's lunch. C was the cross-platform language of its day, more so than any other language that was available. And, from my point of view at the time, that's what killed Pascal."
For us, is was about a major product we had which we re-hosted to newer, much faster hardware. The original system was mostly written in Pascal, on a minicomputer. Or Fortran-77, for a (math-heavy) subset. There was nothing problematic with the Pascal code we used, but we couldn't use that on the the SGI hardware we moved to so we decided to port everything to MIPS-C, actually ANSI C (we limited features to the latter). Even the Fortran code. And from then on, everything we wrote was mostly in C, until C++ etc. became a thing. No new Pascal code was written on Unix.
It evolved in two directions. On the one side, Turbo Pascal which constantly updated the language, added OOP later on. On the other side the development of the successors by Wirth, like Modula and Oberon. All of those were quite popular here in Europe. But especially the US rather trended into the direction of C and later on C++. C was percieved a "fast" language, though there were good performing implementations of the Pascal family too. Fun fact: on the Amiga, the Modula-2 implementation even performed better than the C compilers awailable back then.
On this matter, it is especially interesting to look at Go. While it takes the syntax mostly from C, it actually draws most features from the Wirth family of languages. Which is no surprise as one of the co-creators, Robert Griesemer worked together with Wirth in the past.
> On this matter, it is especially interesting to look at Go.
I absolutely love that it's becoming widely noticed. Go is basically Pascal with nice concurrency and a gc.
I guess Go authors don't want to openly admit it for fear of bad association (I refuse to believe they just reinvented Pascal independently, not that they couldn't, but it'd be a waste of time). Pascal was ridiculed back in the day for... lack of curly braces, as far as I can tell?
>Pascal was ridiculed back in the day for... lack of curly braces, as far as I can tell?
Also for poor string and array handling. The classic implementations used a single byte to store the length of strings, and the length of an array was fixed and was part of its type. Though no-one could accuse K&R C of having good string or array facilities, the language was at least free of these absurd limitations.
These were real limitations of several real Pascal compilers back in the day. As a child, I remember them being explained in a book introducing Pascal to Basic programmers. C has never required compiler-specific language extensions to make arrays and strings practically usable (however error prone they may be).
You also have to think of the effect of this on pedagogy in the pre-Google era. Any book on C would teach you how to handle arrays and strings of arbitrary lengths. Meanwhile, a book introducing Pascal would have to either restrict itself to the ISO standard's hobbled implementation of strings and arrays, or direct the student to cross their fingers and look at their compiler's documentation. That's a significant barrier.
C required tons of extensions to be usable outside big iron UNIX where it was born.
I never saw a pure ISO Pascal compiler outside UNIX, and the only Pascal book I have, from several, that constrains itself to ISO Pascal is Niklaus Wirth book.
Additionally, Pascal naysayers keep forgeting that exactly because of ISO Pascal inadequacies as systems language, Modula-2 was born in 1978.
Quite a long time to keep comparing K&R C (with extensions) with ISO Pascal.
Specially given how many systems Apple shipped with Object Pascal in the box, or the sucess of Apollo Computers on its time.
Oddly enough, I bet the farm on Pascal. I learned Pascal in high school after taking a course in BASIC, and I read about C -- maybe in Byte Magazine. To me, Pascal seemed much more elegant and readable, and pointer arithmetic seemed like a bug factory. I was supremely confident, like any teenager, that I knew my ** and that Pascal would win out over C.
LOL, though I didn't take a course in BASIC (AP CS was taught in Pascal), I swore up and down as a teenager that Pascal "would win" and put off learning C/C++ as a result.
It didn't hurt me much since I started writing software, professionally, in C#, which I'd started writing code in shortly after it was released. I'd even offer that my background in Pascal was relatively easily translated into C# once you get past the minor syntactical differences[0].
I think discovering how wrong I had been about Pascal's future is one of the reasons I don't fanboy programming languages. Don't get me wrong, I favor C#/TypeScript over nearly everything, but I recognize that's because those are the languages I understand the most, I understand their use cases and where there are better choices, but the best choice -- for me -- is the one(s) I know and there's plenty of jobs writing code in those languages.
[0] Keywords, braces were fine; I can't think of a difference that fundamentally bothered me other than `=`/`==` and `:=`/`=`. I'd often muscle-memory the `:=`. I can still hit all three required keys in almost one swipe.
They actually made a Delphi port to Linux called Kylix which used WINE as a compatibility layer, but it didn't last long. Nowadays Embarcadero sells only insanely overpriced enterprise Delphi versions, but we now have Lazarus which is not only free but also quite mature.
the way i see it, it was competing with C# and Java, both pushed by large orgs, and in the open source world, it was C, C++ or Python and Ruby
So i think for most devs, the alternatives made more sense
I think the main reason, pascal still get some mentions, is that even today, creating a desktop UI is not as easy as it should be, most RAD tools are commercial and open source
I think where Pascal still stand a chance today, is to be used to create a GUI RAD tools for Line of Business application, this area, even today have no clear winner
Also, even for that domain i would wish for Tcl/Tk, if Tcl makes a serious come back, it should be it
Pascal is a great easy language with strong typing. It was great at protecting you from yourself. It was a great language for students. It had strong typing that was very solid. You could not easily subvert it. (This is the original, standard Pascal; I'll talk about Turbo later.)
You couldn't even run past the end of an array, because the size of an array was part of the type. You couldn't even compile code that tried to access past the end of an array.
But that was a huge problem. The type system was too strict. Take those arrays, for example. You could not have a variable-sized array, because the size was part of the type, so there was no possible type for that array to have. You literally could not talk about such a thing.
This bit me, for example, where we we trying to do a numerical simulation of EM wave interference patterns on a 2D grid, with the user specifying the size of the grid. We literally were not allowed to create a 2D array with size determined at runtime. So the initial implementation simulated it with a doubly-linked list of allocated points. That solved the type issue, but it had at least two negative results. First, in a node, the next and previous links took as much memory as the actual node data, so it was very memory inefficient. Second, having to walk a pointer to N nodes further to refer to the point directly below you on the grid was both inefficient and error-prone.
We finally improved it by allocating a fixed-sized 2D grid that was as big as we could allocate (we knew at compile time how much memory was available on the machine we were running on) and only using the part that was within the bounds the user specified, but that was also wasteful.
The runtime gave you certain functions that would deal with variable-length strings, but if you found those functions inadequate, you could not implement your own, because you could not talk about variable-length arrays.
And it wasn't just arrays. You could write only the things that fit within Wirth's vision of what you should be allowed to write. Writing your own memory allocator? What's going to be the returned type? Writing to memory-mapped hardware? No way, not allowed.
To write to memory-mapped hardware, we literally had to call a subroutine written in assembly - at which point, we lost all type safety. In the name of the language being as safe as possible, we were forced to do something completely unsafe in order to be able to work at all. (That lack of type safety caused a crash when something changed.)
That was the original Pascal. Everyone who used it seriously saw that it was inadequate for real work, so it got extended in order to be usable. But the problem is that everyone extended it in different ways. Turbo Pascal had extensions, but they weren't going to compile on other compilers - at least not until Turbo became the dominant compiler, which took a while. Code written using other compiler extensions would not compile on Turbo unless Turbo adopted their extensions - which never happened, at least so far as I know. You could not write portable software that did anything outside the standard Pascal straightjacket. (Of course, if you're writing to memory-mapped I/O, you're probably not portable to any other hardware anyway...)
For a more extended discussion of this, read "Why Pascal Is Not My Favorite Programming Language" (https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...). It's by Brian Kernighan (yes, that Kernighan), but it's not a hit piece. He wrote a book called "Software Tools" with P. J. Plaugher, in Ratfor (a Fortran pre-processor). After Pascal came out, he re-wrote the book using Pascal, and then he wondered why it was so hard. Pascal should have been far easier to write in that Ratfor. Why wasn't it? The article is trying to answer that question. It's still an interesting read if you want to know why Pascal didn't really catch on.
Just like everyone used C dialects and variants of K&R C, until ISO finally came to be, and compatible C compilers were available outside UNIX, like Small-C and RatC.
Until then it was #ifdef spaghetti soup and plenty of Assembly to make up for the shortcomings of the dialects, but naturally Mr. Kernighan wouldn't write about that part.
In the meantime standard K&R C was ubiquitous and anyone taking a CS degree would likely have learnt and used it. C's "close to the metal" approach was a good fit for the under-powered CPUs of the day.