Except he missed the part where Modula-2 was made available in 1978, exactly to fix all the original issues with standard Pascal, everything that he complains about, minus type safety.
The thing we are still trying to add back into C, 50 years later.
And C++. While it does have slightly better types than C, I can still apply functions that the compiler doesn't even warn me about and that crash my program at runtime. If I'm lucky. When the phase of the Moon is adversarial, my program continues running in a corrupt state.
Apparently, this is a game that two can play. Niklaus Wirth, the creator of Pascal, had this to say in turn:
"From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword."
Here is C.A.R Hoare's on his "The 1980 ACM Turing Award Lecture", guess to what programming language he is indirectly making a point of, regarding 1980 language designers and users have not learned this lesson.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
Interesting paper, thanks. The findings concerning C seem reasonable. I would add the very weak type checker and the silly syntax, of which the majority of people only use a fraction (many C constructs are surprising and not generally known) to the issue of the small Hamming distance from one valid syntax construct to another, not intended one. Though I doubt that (Common) Lisp is a valid alternative for the typical C use cases.
Looks like in the 70s and 80s, it was wild west for programming language design. So many ideas floating around. But over the decades, most converged to the Algol-style (statements, curly braces, often using semicolons, type before identifier, etc.). Look at what we did to programming:
- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
Compare with these ones that didn't catch on as much as the ones above:
- ML/Haskell, Erlang, Elixir, APL, Common Lisp (and other Lisps), Lua, Pascal, Delphi, BASIC, Visual Basic, VBA, VBScript, SmallTalk,... → each one bringing something refreshingly new to the PL design space
It feels like you're mixing together a lot of ideas that don't really fit together very well. In terms of syntax, only four of the languages you describe as "more or less the same" in terms of how they look use "type before identifier" like you mention. On the other hand, four of them use the ML-style syntax of identifier-colon-type, one uses identifier before type with no colon, and the final one doesn't even have type annotations. At least four of them don't require semicolons either, and I'd argue that at least in Go, having semicolons at all would probably strike people as odd. You've also left out Python, which doesn't fit any of those syntax descriptions you gave and more popular than at least half of the ones you did include.
The timeline of 70s and 80s also doesn't really seem to fit with what you're saying either. Of the languages you mention either as "more or less the same" or "refreshingly new", the ones from either the 70s or 80s are C, C++, ML, Smalltalk, Pascal, and Smalltalk; all of the other "refreshingly new" ones are from either before or after those years. Common Lisp was from the 80s, but the syntax originated with LISP in the 50s, so if you're going to go with the most common variant, I'd argue you should also remove ML from the list and replace it with OCaml, which is from the 90s.
Even more significantly, it feels like you're comparing apples and oranges with the discussion of syntax at the beginning and then talking about bringing something new to the PL design space after. I'd guess that most people involved in PL design find syntax to be the least interesting aspect of it, and I think it's hard to argue that none of the languages you described as looking similar brought anything new to the PL design space.
Python is like Algol in terms of syntax, certainly, and in fact is almost an ideal Algol syntactically: It has no (or few) block delimiter characters or keywords, but imposes proper indentation as a syntactic requirement.
While I started with Basic and and Turbo Pascal, I started to appreciate a lot the curly braces and semicolons because it makes a lot of sense for me (*). Therefore I see the convergence as a good thing, keeping the best parts of everything and improving with good parts from others.
* As opposed to BEGIN-END in SQL, indenting in Python or weirdness of Cobol in the 90s.
>But over the decades, most converged to the Algol-style (statements, curly braces, often using semicolons, type before identifier, etc.). Look at what we did to programming:
>- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
The upside being that if you come from C or Java you will fill at home with Go.
It is interesting to see this Great Convergence. Even PHP, which started off as a quick-and-dirty language with deliberately vague expressions, converges to the same standard.
In my 30-something years of programming (admittedly my first programs were toy-like Pascal pieces of code), I saw only one improvement in this Algol-like style that I considered major: named arguments. Their use improves code readability, at least for me.
I miss Pascal. Learned Object Pascal end of 90s but used it nearly never in my professional career (only a few months with Delphi during a student job). I really never used C or C++ in my professional career which is also interesting.
Nowadays it's all Javascript and more specifically Typescript in my case.
Interestingly, Donald Knuth created an entire new system of programming to make up for the deficiencies of Pascal in the programs he was trying to write (TeX and METAFONT):
Folks keep talking about how Modula-2 was released in 1978, to fix Pascal's defects. Well, yes, but.
I used Pascal a lot for about ten years starting in the late 70's: multiple flavors of UCSD Pascal, consecutive versions of Turbo Pascal, and VAX Pascal, on six distinct hardware platforms. Pascal was readily available for all of them; Modula-2 had no market share at all, so far as I could ever tell.
And market share is the right word: most compilers cost money in those days, sometimes quite a lot of money. Turbo Pascal took off because Borland sold it for $50, as opposed to something like $700 for Microsoft's compilers.
I wrote a letter to Borland International, asking if they were going to release a Turbo Modula-2, and was told yes. I'd have been first in line. It was never released.
So yeah, Modula-2 existed, technically, but it mostly wasn't relevant, at least not for microcomputer programmers.
It's a significantly incomplete list - and absolutely not a list of "quotes" as none of the items in your list appear in the article:
>Lack of external static storage class, the pinnacle of C programming.
>Lack of oh so powerful C strings, terminating in zero (hopefully).
>"There is no way to override the type mechanism when necessary, nothing analogous to the "cast" mechanism in C."
>"begin" and "end" are bulky compared to { and }.
In my opinion these are some of the less significant arguments. Your post never stated that it contains merely a subset a subset and instead claims to refute or weaken the overall proposal. I agree with the previous poster that this is a form of lying.
For instance, you ignored one of the very first and most significant points, "The size of an array is part of its type" which means that " it makes it difficult indeed to create a library of routines for doing common, general-purpose
operations like sorting"
Incidentally, those are examples of quotes i.e. verbatim excerpts from the article.
Null-terminated strings is an endless source of bugs in C progras. I with C used fixed size strings (may be with varint instead of 8-bit length field) or Pascal got more tratcion.
And very annoyingly they can't be sliced except if you are only trimming off the front. If you need to chop off anything at the end, you either need to make a copy or do an icky and not thread safe hack of swapping out a character for the null character and then swapping it back when you're done.
> Pascal, in common with most other Algol-inspired languages, uses the semicolon as a statement separator rather than a terminator (as it is in PL/I and C). As a result one must have a reasonably sophisticated notion of what a statement is to put semicolons in properly.
I wonder how the non-programmers succeed to write commas correctly, because those follow the same logic: e.g. "red, green, blue". In author's opinion, I guess it should be "red, green, blue," instead.
Have you ever used a Pascal compiler that's strict about this? It's surprisingly annoying even today. Now imagine it's 1981 and you're editing your programs with a line editor. In C code, you can freely swap lines around. If you try the same in Pascal code, you'll spend a lot of time fixing up semicolons.
> There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string:
'This is a '' character'
That doesn’t seem like a good explanation. There’s nothing preventing a tokenizer from interpreting two quotes not followed by a third quote as an empty string literal. In fact, that’s what current Pascal compilers accept (e.g. `writeln('')`).
However, an empty string and nil are also the same in Pascal, there is no distinction between an empty string and the absence of a string. This is because in early computing, strings weren’t separate objects that you pointed to (and hence could be a null pointer), but more like (usually fixed-size) arrays allocated as part of a larger contiguous memory structure. The array could be empty (based on some length variable), but it couldn’t not be there as part of the fixed memory layout.
Actually, in certain systems strings couldn’t even be empty, in the sense that there was no stored size in addition to the fixed-length array. Instead you padded the rest of the array with spaces. The CHAR type in SQL (as opposed to VARCHAR) is a remnant of that practice.
Empty string and nil are not at all the same in Pascal. Pascal, even in its most basic version, still had pointers, and nil was the null pointer. You could have pointers to strings (and other kinds of arrays), as well.
What made standard Pascal problematic wrt string handling is that it did not have array NEW nor pointer arithmetic. So if you wanted to heap-allocate ARRAY[1..100] OF CHAR, that was fine; but there was no way to get a pointer to N bytes on the heap where N is determined at runtime; and even if you could do that, somehow, you still wouldn't be able to use that pointer as an array by indexing through it.
Interestingly enough standard Pascal did support allocating variable-length data structures, but only in form of variant records (roughly analogous to discriminated unions in ML or enums in Rust, but with multi-level nesting and the ability to define a common sequence of fields shared by all variants at any level).
Even in Modula-2, 1978, exactly because Niklaus Wirth was the very first to acknowledge the limitations of the original Pascal, designed as a programming language for teaching purposes.
Yes, most Pascal dialects, namely UCSD Pascal and Object Pascal also got around fixing them, as did ISO Extended Pascal, the follow up revision that was largely ignored, because by then it was all about Object Pascal.
Why is it that Pascal is supposedly so good for Rapid Application Development? Is it simply a historical accident, or does Pascal have some features that make it easier? What features would need to be added to C to make C a viable language for RAD?
There are many unique features of Object Pascal as used in Delphi which makes it very easy to write components in:
* Components have a support for customizable UI interfaces for setting the property of components called property sheets and these property sheets are applicable on a component level or at the level of individual property fields in the component. These property sheets show up when you are trying configure a component in the design mode within the IDE. We are not talking about simple text entry type of fields - you can actually do very sophisticated property sheets with tabs, multiple forms etc and what not. It is EXTREMELY configurable and also relatively easy to develop.
* Delphi uses a binary "form" file into which each GUI form persists its interface. So everytime you place a component on a form in the GUI IDE or set its properties, the form and its components have a way of persisting their values into this "form" file. The reverse also happens - so when a form is loaded into the IDE or during runtime, the form fields are read off the "form" file by the form and its components. So the actual .pas file where you are adding code for the events etc is not filled up with a lot of UI related property setting code and so the code looks really clean with clear separation of design and code.
* Components can be installed into the IDE during development very easily
One important aspect (since the topic is the language) is there is nothing special about components in Delphi and Lazarus - they are just built on the language's RTTI features.
In Free Pascal (and Delphi) all classes have a "metaclass" (a class that describes the class) and can be used in conjunction with the RTTI to obtain information about an object at runtime - including its actual class, exposed properties and any optional metadata (like attributes in FP).
This functionality is used by Delphi/Lazarus to serialize and deserialize objects on disk (the form files you mention are such serialized objects but you can serialize other types of objects and in Lazarus -perhaps Delphi too- you can use several file formats) as well as implement the object inspector.
In a way Delphi/Lazarus work kinda like how game engines like Unreal work in that you are working with "live" instances of objects, using generic object inspectors and saving them on disk is done by serializing them (though obviously it is the opposite since Delphi predates most game engines using this approach :-P).
The important aspect with all the above isn't so much the form/component serialization but the language features that make it possible in the first place: metaclasses and RTTI that provides enough information to instantiate and describe objects and classes at runtime.
My own game engine[0] is written in Free Pascal and Lazarus and uses the exact same language features to provide object serialization, property editing and some other stuff (like object diffing that is used for many undo/redo operations). Instead of TComponent/TPersistent (the types Delphi/FCL provide for serialization), it has its own base types that use a more compact file format, optional compressed streams (e.g. for texture data) and external references (for shared assets stored in separate files), but still relies on the same base functionality provided by the language/compiler.
It has little to do with the language itself, moreso with the tools.
One thing that very clearly distinguished (extended dialects of) Pascal from C in the era where the two were competing was that Pascal's units were self-describing. That is, when you compiled a unit, you got a single file with all the metadata for that unit as well as binary object code for linking. Then, when another unit or program did a USES declaration, that would locate the file by name and use the metadata as needed. Conversely, in C you had to deal with header files, and while on the surface it looks kinda sorta like the INTERFACE section of the Pascal unit, it's not quite that because e.g. it needs to #include things it depends on - and that is textual inclusion, not just a metadata reference.
This all meant that working with dynamically loaded type information was much easier in Pascal tooling - it just needed to parse the metadata embedded in the compiled unit files, and each file would only contain metadata for its own types and functions, without contamination from other units that it relies on. This is great for things like code completion and visual UI designers.
Object Pascal as defined by Borland/Inprise/Embarcadero's Delphi has plenty of features that make it easier to build components. C++ Builder offers a similar experience. Straight C would certainly be possible, GTK is a step in that direction, but likely more awkward to use.
I would add that Delphi also had a culture of component libraries and sharing code.
There were free intro libraries (no code), shareware component libraries, and usually a developer version available that came with source code. Plus a culture of open source libraries.
This community was a key strength of Delphi compared to some other choices. I suspect if Borland had really leaned into a combination of open source, plus better support for commercial proprietary solutions, that would have kept the ecosystem alive.
Also of note is that Delphi came with some source code for library components (often useful when understanding usage or debugging or extending).
One aspect of Pascal that helps is compilation speed. Pascal's nature allows for single-pass compilers. It may not sound like a big deal, but it's a huge cumulative effect.
That definitely was a big deal in the 80s when I used it. You could compile a program in seconds, all in memory, while a C program needed 5 passes, each pass writing and reading from quite slow hard disks of the time.
Those were not conceptual passes, but actual standalone programs executed in that order, to compile a C program. Each program operated within 64KB RAM, shared with the OS and all the drivers.
Delphi and Lazarus have heritages that date back to, or are inspired by, Turbo Pascal and Object Pascal, both of which extended the language in useful ways to make it suitable for real-world use.
When we say "Pascal" today we speak of a much more ergonomic language than the Pascal of 1981.
At the time it appeared, it was more powerful than BASIC or COBOL. We learned Pascal in college and even the technically less inclined colleagues were able to do the assignments pretty well. We used Turbo Pascal, which had a decent IDE, my brother also continued to use Delphi for another ~ 10 years and loved it for being so easy to do some quick and dirty things when needed. Honestly I don't remember almost any details after 30 years, other than it was simple to use and quick to learn and write something in it, while a lot more friendly than C or C++.
I ran a BBS for a few years in 1992-1994, at some point running under OS/2, but honestly I never bothered to find out the programming language used for it, there was no source code attached and all the software at that time was pirated.
My first thought when reading the title was: because you're not living in the 1980s anymore. But it's an article from 1981, so it's got to be something else.
It won't be C. The reason as I see it is because of commodification. Executives want things as cheap and drop-in as possible. With C, you need a certain amount of skill. With a language like Rust that advertises memory-safety, they like that because it means you don't need as much skill anymore.
A similar thing is happening with game engines. If everyone is taught Unreal engine then you don't get in-house engines anymore which requires skill, because it's easier and cheaper to get some replaceable grunt to implement it in Unreal, perhaps with some off-the-shelf assets, which is perceived as "good enough".
It will be interesting to see how AI generation of code changes development tooling and the skills required.
> With C, you need a certain amount of skill. With a language like Rust that advertises memory-safety, they like that because it means you don't need as much skill anymore.
this is a surprising statement --- in tust you need to formalize the flow of mutability, which is a skill requirement.
so why do you think rust for the boss seems cheaper than C?
I can't give you a non-speculative answer because in truth, my coding is from the Pascal era.
The way I look at it in terms of cheaper is that you don't need to be as careful, less need to worry about memory leaks which lead to exploits, etc. I.e. you don't have to track every little thing yourself.
Starting to make inroads with larger projects now.. Firefox's audio subsystem is in Rust, while Chromium's is C++ (w/ tools to help detect leaks).
Heh so it seems because the Pascal arrays and strings were so atrocious, Mr.Kernighan avoided them completely in C. Everyone is supposed to roll their own, with quite disastrous consequences.
Everyone tries to roll their own strings in C, and eventually give it up, because the 0-terminated strings are so deeply embedded in the language and the library.
Even D still has a nod to C strings in it, in that string literals like "abc" have a 0 appended to them that is not included in the array length. "abc" can implicitly convert to a char*, which makes it very convenient when calling printf.
On the other hand: having your standard string type limited to 255 characters - requiring a completely different set of functions to manipulate longer ones - is painful in its own way.
(You can avoid some of the pain by using a big-endian length, and converting immutable Str64K pointers to Str255 by taking a pointer to the second byte of the length. But that's a terrible hack.)
The problem of the original standard Pascal is that you couldn't roll your own strings in it, because it didn't have pointer arithmetics or heap-allocated variable-length arrays, at all.
I was using Pascal to program Mac apps in the late '80s. I was forever finding myself wanting a string, but having an array of characters. What a pain.
Related:
Why Pascal Is Not My Favorite Programming Language - https://news.ycombinator.com/item?id=37044792 - Aug 2023 (2 comments)
Why Pascal Is Not My Favorite Programming Language (1981) [pdf] - https://news.ycombinator.com/item?id=22222117 - Feb 2020 (62 comments)
Why Pascal Is Not My Favorite Programming Language (1981) - https://news.ycombinator.com/item?id=19221143 - Feb 2019 (55 comments)
Why Pascal Is Not My Favorite Programming Language – Current Status - https://news.ycombinator.com/item?id=8273608 - Sept 2014 (1 comment)
Why Pascal is Not My Favorite Programming Language (1981) - https://news.ycombinator.com/item?id=8260694 - Sept 2014 (64 comments)
Except he missed the part where Modula-2 was made available in 1978, exactly to fix all the original issues with standard Pascal, everything that he complains about, minus type safety.
The thing we are still trying to add back into C, 50 years later.
And C++. While it does have slightly better types than C, I can still apply functions that the compiler doesn't even warn me about and that crash my program at runtime. If I'm lucky. When the phase of the Moon is adversarial, my program continues running in a corrupt state.
Apparently, this is a game that two can play. Niklaus Wirth, the creator of Pascal, had this to say in turn:
"From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword."
Source: Niklaus Wirth, A Brief History of Software Engineering, 2008 (https://people.inf.ethz.ch/wirth/Miscellaneous/IEEE-Annals.p...)
Not only Niklaus Wirth,
Here is C.A.R Hoare's on his "The 1980 ACM Turing Award Lecture", guess to what programming language he is indirectly making a point of, regarding 1980 language designers and users have not learned this lesson.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
'Throughout the paper, Kernighan sets up a strawman of "standard Pascal" in "its pure form".'
http://lambda-the-ultimate.org/classic/message4322.html#4671
Via dang's recap (... - Current Status -):
"People who are still trying to refer to the article are unaware of the capabilities of current Pascal (Delphi/FPC) implementations."
https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pr...
Also see
"Software Fault Prevention by Language Choice: Why C is Not My Favorite Language"
https://people.eecs.berkeley.edu/~fateman/papers/software.pd...
Interesting paper, thanks. The findings concerning C seem reasonable. I would add the very weak type checker and the silly syntax, of which the majority of people only use a fraction (many C constructs are surprising and not generally known) to the issue of the small Hamming distance from one valid syntax construct to another, not intended one. Though I doubt that (Common) Lisp is a valid alternative for the typical C use cases.
Looks like in the 70s and 80s, it was wild west for programming language design. So many ideas floating around. But over the decades, most converged to the Algol-style (statements, curly braces, often using semicolons, type before identifier, etc.). Look at what we did to programming:
- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
Compare with these ones that didn't catch on as much as the ones above:
- ML/Haskell, Erlang, Elixir, APL, Common Lisp (and other Lisps), Lua, Pascal, Delphi, BASIC, Visual Basic, VBA, VBScript, SmallTalk,... → each one bringing something refreshingly new to the PL design space
It feels like you're mixing together a lot of ideas that don't really fit together very well. In terms of syntax, only four of the languages you describe as "more or less the same" in terms of how they look use "type before identifier" like you mention. On the other hand, four of them use the ML-style syntax of identifier-colon-type, one uses identifier before type with no colon, and the final one doesn't even have type annotations. At least four of them don't require semicolons either, and I'd argue that at least in Go, having semicolons at all would probably strike people as odd. You've also left out Python, which doesn't fit any of those syntax descriptions you gave and more popular than at least half of the ones you did include.
The timeline of 70s and 80s also doesn't really seem to fit with what you're saying either. Of the languages you mention either as "more or less the same" or "refreshingly new", the ones from either the 70s or 80s are C, C++, ML, Smalltalk, Pascal, and Smalltalk; all of the other "refreshingly new" ones are from either before or after those years. Common Lisp was from the 80s, but the syntax originated with LISP in the 50s, so if you're going to go with the most common variant, I'd argue you should also remove ML from the list and replace it with OCaml, which is from the 90s.
Even more significantly, it feels like you're comparing apples and oranges with the discussion of syntax at the beginning and then talking about bringing something new to the PL design space after. I'd guess that most people involved in PL design find syntax to be the least interesting aspect of it, and I think it's hard to argue that none of the languages you described as looking similar brought anything new to the PL design space.
I'd hesitate to say that Lua "didn't catch on". It's extremely popular as an embeddable scripting language, particularly in game development.
Another counterexample to consider is Python. It's quite unlike Algol, but that certainly hasn't stopped it from becoming popular.
Python is like Algol in terms of syntax, certainly, and in fact is almost an ideal Algol syntactically: It has no (or few) block delimiter characters or keywords, but imposes proper indentation as a syntactic requirement.
While I started with Basic and and Turbo Pascal, I started to appreciate a lot the curly braces and semicolons because it makes a lot of sense for me (*). Therefore I see the convergence as a good thing, keeping the best parts of everything and improving with good parts from others.
* As opposed to BEGIN-END in SQL, indenting in Python or weirdness of Cobol in the 90s.
>But over the decades, most converged to the Algol-style (statements, curly braces, often using semicolons, type before identifier, etc.). Look at what we did to programming:
>- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
The upside being that if you come from C or Java you will fill at home with Go.
It is interesting to see this Great Convergence. Even PHP, which started off as a quick-and-dirty language with deliberately vague expressions, converges to the same standard.
In my 30-something years of programming (admittedly my first programs were toy-like Pascal pieces of code), I saw only one improvement in this Algol-like style that I considered major: named arguments. Their use improves code readability, at least for me.
Ada83 had named arguments. It is effectively Pascal++ with the operator precedence fixed to be useful rather than a mathematician's fever dream.
I miss Pascal. Learned Object Pascal end of 90s but used it nearly never in my professional career (only a few months with Delphi during a student job). I really never used C or C++ in my professional career which is also interesting.
Nowadays it's all Javascript and more specifically Typescript in my case.
That PDF would be probably much longer about Javascript but it seems Kernighan is quite okay with that language nowadays https://www.youtube.com/watch?v=AB60_uUetJs
Interestingly, Donald Knuth created an entire new system of programming to make up for the deficiencies of Pascal in the programs he was trying to write (TeX and METAFONT):
http://literateprogramming.com/
WEB is expressive enough that there is a tool to directly transpile to C for compiling:
https://tug.org/web2c/
Folks keep talking about how Modula-2 was released in 1978, to fix Pascal's defects. Well, yes, but.
I used Pascal a lot for about ten years starting in the late 70's: multiple flavors of UCSD Pascal, consecutive versions of Turbo Pascal, and VAX Pascal, on six distinct hardware platforms. Pascal was readily available for all of them; Modula-2 had no market share at all, so far as I could ever tell.
And market share is the right word: most compilers cost money in those days, sometimes quite a lot of money. Turbo Pascal took off because Borland sold it for $50, as opposed to something like $700 for Microsoft's compilers.
I wrote a letter to Borland International, asking if they were going to release a Turbo Modula-2, and was told yes. I'd have been first in line. It was never released.
So yeah, Modula-2 existed, technically, but it mostly wasn't relevant, at least not for microcomputer programmers.
Some of his grievances:
Lack of external static storage class, the pinnacle of C programming.
Lack of oh so powerful C strings, terminating in zero (hopefully).
"There is no way to override the type mechanism when necessary, nothing analogous to the "cast" mechanism in C."
"begin" and "end" are bulky compared to { and }.
This is not a very accurate summary of said article. In fact it is inaccurate enough to call it lying.
That's not a summary. That's a number of quotes demonstrating Mr. Kernighan's judgements about PL virtues that didn't stand the test of time.
It's a significantly incomplete list - and absolutely not a list of "quotes" as none of the items in your list appear in the article:
>Lack of external static storage class, the pinnacle of C programming.
>Lack of oh so powerful C strings, terminating in zero (hopefully).
>"There is no way to override the type mechanism when necessary, nothing analogous to the "cast" mechanism in C."
>"begin" and "end" are bulky compared to { and }.
In my opinion these are some of the less significant arguments. Your post never stated that it contains merely a subset a subset and instead claims to refute or weaken the overall proposal. I agree with the previous poster that this is a form of lying.
For instance, you ignored one of the very first and most significant points, "The size of an array is part of its type" which means that " it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting"
Incidentally, those are examples of quotes i.e. verbatim excerpts from the article.
then maybe amend your comment and start with "some of his grievances"?
BEGIN and END are still bulky, Even C got it wrong by making () mandatory instead of {}, which is something go fixed.
Null-terminated strings is an endless source of bugs in C progras. I with C used fixed size strings (may be with varint instead of 8-bit length field) or Pascal got more tratcion.
And very annoyingly they can't be sliced except if you are only trimming off the front. If you need to chop off anything at the end, you either need to make a copy or do an icky and not thread safe hack of swapping out a character for the null character and then swapping it back when you're done.
One that you are missing (and a pretty painful one, for that matter) is "lack of flexible array parameters".
Also, the problem with pascal string was the length being limited to 255 characters, which wasn't enough even at the time.
> Pascal, in common with most other Algol-inspired languages, uses the semicolon as a statement separator rather than a terminator (as it is in PL/I and C). As a result one must have a reasonably sophisticated notion of what a statement is to put semicolons in properly.
I wonder how the non-programmers succeed to write commas correctly, because those follow the same logic: e.g. "red, green, blue". In author's opinion, I guess it should be "red, green, blue," instead.
Have you ever used a Pascal compiler that's strict about this? It's surprisingly annoying even today. Now imagine it's 1981 and you're editing your programs with a line editor. In C code, you can freely swap lines around. If you try the same in Pascal code, you'll spend a lot of time fixing up semicolons.
>
> then any arbitrary arithmetic expression involving apples and oranges is perfectly legalSame in Kotlin sadly. The whole point of giving a different names to a type is to make them incompatible.
> There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string:
That doesn’t seem like a good explanation. There’s nothing preventing a tokenizer from interpreting two quotes not followed by a third quote as an empty string literal. In fact, that’s what current Pascal compilers accept (e.g. `writeln('')`).However, an empty string and nil are also the same in Pascal, there is no distinction between an empty string and the absence of a string. This is because in early computing, strings weren’t separate objects that you pointed to (and hence could be a null pointer), but more like (usually fixed-size) arrays allocated as part of a larger contiguous memory structure. The array could be empty (based on some length variable), but it couldn’t not be there as part of the fixed memory layout.
Actually, in certain systems strings couldn’t even be empty, in the sense that there was no stored size in addition to the fixed-length array. Instead you padded the rest of the array with spaces. The CHAR type in SQL (as opposed to VARCHAR) is a remnant of that practice.
Empty string and nil are not at all the same in Pascal. Pascal, even in its most basic version, still had pointers, and nil was the null pointer. You could have pointers to strings (and other kinds of arrays), as well.
What made standard Pascal problematic wrt string handling is that it did not have array NEW nor pointer arithmetic. So if you wanted to heap-allocate ARRAY[1..100] OF CHAR, that was fine; but there was no way to get a pointer to N bytes on the heap where N is determined at runtime; and even if you could do that, somehow, you still wouldn't be able to use that pointer as an array by indexing through it.
Interestingly enough standard Pascal did support allocating variable-length data structures, but only in form of variant records (roughly analogous to discriminated unions in ML or enums in Rust, but with multi-level nesting and the ability to define a common sequence of fields shared by all variants at any level).
You are right regarding nil, I was mixing this up with Turbo Pascal/Delphi strings.
Pascal taught a generation of coders that you test for end-of-file before trying to read any data from the stream.
When they hit C, they wrote code around fgets that processes the last line twice:
Or processes the EOF value from getc as a character:I think almost all of those criticisms are solved in newer versions of Pascal.
Even in Modula-2, 1978, exactly because Niklaus Wirth was the very first to acknowledge the limitations of the original Pascal, designed as a programming language for teaching purposes.
Yes, most Pascal dialects, namely UCSD Pascal and Object Pascal also got around fixing them, as did ISO Extended Pascal, the follow up revision that was largely ignored, because by then it was all about Object Pascal.
Folks should also appreciate that BK was also working on the “Software Tools in Pascal” book.
This was an update to the earlier “Software Tools” book, which was written using RATFOR.
If you read the book, it has a very “C in Pascal” coding style, and you can see how uncomfortable it is by doing so.
Kernighan probably disliked PL/I as well, but it had better memory safety than C; Multics was never plagued with buffer overflows.
Pascal implementations typically support index and range checking, while Ada provides even more extensive memory and concurrency safety.
Fortunately for C, clang's -fbounds-safety seems to be making progress. It's implemented in Apple's LLVM fork, so this now works on macOS:
https://clang.llvm.org/docs/BoundsSafety.htmlWhy is it that Pascal is supposedly so good for Rapid Application Development? Is it simply a historical accident, or does Pascal have some features that make it easier? What features would need to be added to C to make C a viable language for RAD?
There are many unique features of Object Pascal as used in Delphi which makes it very easy to write components in:
* Components have a support for customizable UI interfaces for setting the property of components called property sheets and these property sheets are applicable on a component level or at the level of individual property fields in the component. These property sheets show up when you are trying configure a component in the design mode within the IDE. We are not talking about simple text entry type of fields - you can actually do very sophisticated property sheets with tabs, multiple forms etc and what not. It is EXTREMELY configurable and also relatively easy to develop.
* Delphi uses a binary "form" file into which each GUI form persists its interface. So everytime you place a component on a form in the GUI IDE or set its properties, the form and its components have a way of persisting their values into this "form" file. The reverse also happens - so when a form is loaded into the IDE or during runtime, the form fields are read off the "form" file by the form and its components. So the actual .pas file where you are adding code for the events etc is not filled up with a lot of UI related property setting code and so the code looks really clean with clear separation of design and code.
* Components can be installed into the IDE during development very easily
One important aspect (since the topic is the language) is there is nothing special about components in Delphi and Lazarus - they are just built on the language's RTTI features.
In Free Pascal (and Delphi) all classes have a "metaclass" (a class that describes the class) and can be used in conjunction with the RTTI to obtain information about an object at runtime - including its actual class, exposed properties and any optional metadata (like attributes in FP).
This functionality is used by Delphi/Lazarus to serialize and deserialize objects on disk (the form files you mention are such serialized objects but you can serialize other types of objects and in Lazarus -perhaps Delphi too- you can use several file formats) as well as implement the object inspector.
In a way Delphi/Lazarus work kinda like how game engines like Unreal work in that you are working with "live" instances of objects, using generic object inspectors and saving them on disk is done by serializing them (though obviously it is the opposite since Delphi predates most game engines using this approach :-P).
The important aspect with all the above isn't so much the form/component serialization but the language features that make it possible in the first place: metaclasses and RTTI that provides enough information to instantiate and describe objects and classes at runtime.
My own game engine[0] is written in Free Pascal and Lazarus and uses the exact same language features to provide object serialization, property editing and some other stuff (like object diffing that is used for many undo/redo operations). Instead of TComponent/TPersistent (the types Delphi/FCL provide for serialization), it has its own base types that use a more compact file format, optional compressed streams (e.g. for texture data) and external references (for shared assets stored in separate files), but still relies on the same base functionality provided by the language/compiler.
[0] https://i.imgur.com/fypn318.jpg
Cool! what is the name of your game engine? For some reason the imgur links are banned here in India and so not able to see it.
What ISP are you using? I am able to open the link on Airtel broadband and both Airtel and Jio cellular.
It has little to do with the language itself, moreso with the tools.
One thing that very clearly distinguished (extended dialects of) Pascal from C in the era where the two were competing was that Pascal's units were self-describing. That is, when you compiled a unit, you got a single file with all the metadata for that unit as well as binary object code for linking. Then, when another unit or program did a USES declaration, that would locate the file by name and use the metadata as needed. Conversely, in C you had to deal with header files, and while on the surface it looks kinda sorta like the INTERFACE section of the Pascal unit, it's not quite that because e.g. it needs to #include things it depends on - and that is textual inclusion, not just a metadata reference.
This all meant that working with dynamically loaded type information was much easier in Pascal tooling - it just needed to parse the metadata embedded in the compiled unit files, and each file would only contain metadata for its own types and functions, without contamination from other units that it relies on. This is great for things like code completion and visual UI designers.
Object Pascal as defined by Borland/Inprise/Embarcadero's Delphi has plenty of features that make it easier to build components. C++ Builder offers a similar experience. Straight C would certainly be possible, GTK is a step in that direction, but likely more awkward to use.
I would add that Delphi also had a culture of component libraries and sharing code.
There were free intro libraries (no code), shareware component libraries, and usually a developer version available that came with source code. Plus a culture of open source libraries.
This community was a key strength of Delphi compared to some other choices. I suspect if Borland had really leaned into a combination of open source, plus better support for commercial proprietary solutions, that would have kept the ecosystem alive.
Also of note is that Delphi came with some source code for library components (often useful when understanding usage or debugging or extending).
I cannot see any reason why the RAD for Pascal (i.e. Delphi, and now Lazarus) could not exist for other languages. They just happen not to.
Imagine this - if those had not exists, would anyone say Pascal was a good RAD language.
I suppose what I might be missing is why Pascal was chosen as the language for Delphi.
One aspect of Pascal that helps is compilation speed. Pascal's nature allows for single-pass compilers. It may not sound like a big deal, but it's a huge cumulative effect.
That definitely was a big deal in the 80s when I used it. You could compile a program in seconds, all in memory, while a C program needed 5 passes, each pass writing and reading from quite slow hard disks of the time.
My C and C++ compilers (Datalight, Zortech) only required 2 passes:
1. preprocessor/parser/semantic all at once
2. optimizer (optional)
3. code generator
Later on in the 80s these were merged into one executable.
CPP
C0
C1
C2
AS
LD
And an optional AR
I know what the conceptual passes are, but ZTC merged them, including the multiple conceptual passes the CPP does.
Those were not conceptual passes, but actual standalone programs executed in that order, to compile a C program. Each program operated within 64KB RAM, shared with the OS and all the drivers.
And Zortech C, for 64K machines, had two standalone programs to compile a C program to an object file.
Cudos to Zortech C
That is a good point. Repeatedly waiting for compile of build steps is a productivity killer and I think especially relevant for RAD.
I played with Lazarus recently and the whole process of creating a simple GUI was so painless.
Delphi and Lazarus have heritages that date back to, or are inspired by, Turbo Pascal and Object Pascal, both of which extended the language in useful ways to make it suitable for real-world use.
When we say "Pascal" today we speak of a much more ergonomic language than the Pascal of 1981.
Easy, see C++ Builder.
Thing is, people complain about Borland/Embarcadero extensions, but love their GCC and clang ones.
At the time it appeared, it was more powerful than BASIC or COBOL. We learned Pascal in college and even the technically less inclined colleagues were able to do the assignments pretty well. We used Turbo Pascal, which had a decent IDE, my brother also continued to use Delphi for another ~ 10 years and loved it for being so easy to do some quick and dirty things when needed. Honestly I don't remember almost any details after 30 years, other than it was simple to use and quick to learn and write something in it, while a lot more friendly than C or C++.
A huge amount of BBS software from the classic pre-Internet BBS era was written in Borland Turbo Pascal.
I ran a BBS for a few years in 1992-1994, at some point running under OS/2, but honestly I never bothered to find out the programming language used for it, there was no source code attached and all the software at that time was pirated.
In the 1980s, CNET (one of France Telecom R&D labs) wrote a UNIX clone in Pascal.
To put it in a single statement: Pascal is only suitable to study computer science. This is why he doesn't like the language.
Which is just not true. Pascal is going strong within the Lazarus / RAD community.
My first thought when reading the title was: because you're not living in the 1980s anymore. But it's an article from 1981, so it's got to be something else.
Note that Pascal of 1981 is not the same as Object Pascal compiled with FPC in 2025, although many of his points still stand.
And the issues were already sorted out in Modula-2 from 1978, Pascal's replacement as per its inventor.
For me Pascal was an awesome language in the 1980s. Oracle PL/SQL reminds me of it.
PL/SQL is based on Ada, hence the similarity.
The 80s war between C and Pascal, has been resolved, each side gave its arguments, the judge of history has decided that the clear winner was C.
The new battle has begun with three major contenders: C, Golang, and Rust. Which one will be chosen for the future?
It won't be C. The reason as I see it is because of commodification. Executives want things as cheap and drop-in as possible. With C, you need a certain amount of skill. With a language like Rust that advertises memory-safety, they like that because it means you don't need as much skill anymore.
A similar thing is happening with game engines. If everyone is taught Unreal engine then you don't get in-house engines anymore which requires skill, because it's easier and cheaper to get some replaceable grunt to implement it in Unreal, perhaps with some off-the-shelf assets, which is perceived as "good enough".
It will be interesting to see how AI generation of code changes development tooling and the skills required.
> With C, you need a certain amount of skill. With a language like Rust that advertises memory-safety, they like that because it means you don't need as much skill anymore.
this is a surprising statement --- in tust you need to formalize the flow of mutability, which is a skill requirement.
so why do you think rust for the boss seems cheaper than C?
I can't give you a non-speculative answer because in truth, my coding is from the Pascal era.
The way I look at it in terms of cheaper is that you don't need to be as careful, less need to worry about memory leaks which lead to exploits, etc. I.e. you don't have to track every little thing yourself.
Starting to make inroads with larger projects now.. Firefox's audio subsystem is in Rust, while Chromium's is C++ (w/ tools to help detect leaks).
Heh so it seems because the Pascal arrays and strings were so atrocious, Mr.Kernighan avoided them completely in C. Everyone is supposed to roll their own, with quite disastrous consequences.
Everyone tries to roll their own strings in C, and eventually give it up, because the 0-terminated strings are so deeply embedded in the language and the library.
Even D still has a nod to C strings in it, in that string literals like "abc" have a 0 appended to them that is not included in the array length. "abc" can implicitly convert to a char*, which makes it very convenient when calling printf.
On the other hand: having your standard string type limited to 255 characters - requiring a completely different set of functions to manipulate longer ones - is painful in its own way.
(You can avoid some of the pain by using a big-endian length, and converting immutable Str64K pointers to Str255 by taking a pointer to the second byte of the length. But that's a terrible hack.)
Only if stuck in standard Pascal, as Pascal evolution, Modula-2 had already fixed that by 1978.
Whereas by the time Turbo Pascal for Windows came to be, that was also sorted out in Object Pascal according to Borland linage.
As evolution to Modula-2, following up on Pascal evolution, Oberon had it sorted out as well in 1990.
The problem of the original standard Pascal is that you couldn't roll your own strings in it, because it didn't have pointer arithmetics or heap-allocated variable-length arrays, at all.
I was using Pascal to program Mac apps in the late '80s. I was forever finding myself wanting a string, but having an array of characters. What a pain.