Pascal deserves a second look(timcoatesinsights.wordpress.com)
timcoatesinsights.wordpress.com
Pascal deserves a second look
https://timcoatesinsights.wordpress.com/2024/10/31/why-pascal-deserves-a-second-look/
68 comments
Use GoLang, it's better
Pascal's compilation time is still unparalleled in its speed and that is one of its greatest features.
True for Turbo. Not true for the truly atrocious UCSD Pascal.
Computer scientists circa 1980 were driven absolutely crazy by BASIC becoming the dominant teaching language in primary schools; with alternatives like UCSD Pascal, however, you are better off writing assembly.
Computer scientists circa 1980 were driven absolutely crazy by BASIC becoming the dominant teaching language in primary schools; with alternatives like UCSD Pascal, however, you are better off writing assembly.
Pascal = Turbo Pascal if we're taking late 80s/early 90s.
Everything else is blasphemy.
After that, Pascal = Delphi (for quite a while).
The fact that both are commercial, closed-source (and, in case of Delphi, quite pricey) packages is pretty much the sole reason Pascal lost out in popularity to languages that mere mortals could use at home without having to resort to piracy.
It took Embarcadero over a decade to realize that offering a free "Community Edition" of the IDE is a must to stay relevant. It was too late by then.
Everything else is blasphemy.
After that, Pascal = Delphi (for quite a while).
The fact that both are commercial, closed-source (and, in case of Delphi, quite pricey) packages is pretty much the sole reason Pascal lost out in popularity to languages that mere mortals could use at home without having to resort to piracy.
It took Embarcadero over a decade to realize that offering a free "Community Edition" of the IDE is a must to stay relevant. It was too late by then.
Some people in the 1990s thought that open source, particularly the GNU suite, killed off the market for “cheap and cheerful” dev tools, thus we haven’t had a Borland ever since. Today innovation in programming tools tends to come from the hugest companies (Microsoft, Oracle, Google, Facebook) and even successful open source tools such as the LLVM-based compiler suite owe a lot to big funders like Apple.
(Possibly Jetbrains is an exception, though my take is their attempts to introduce new languages like Katlin and radical frameworks like MPS haven’t been as impactful as getting the bugs and slowness out of Eclipse)
(Possibly Jetbrains is an exception, though my take is their attempts to introduce new languages like Katlin and radical frameworks like MPS haven’t been as impactful as getting the bugs and slowness out of Eclipse)
Go compiles fast: https://blog.howardjohn.info/posts/go-build-times/
34000 lines of code/min on an 8088 fast?
Much of that (potential) compilation speed is due to Wirth's personality, but his circumstances also helped.
For industrial languages, programs will be compiled a few times while developing and debugging, and then run many, many more times in production.
For a teaching language, programs will be compiled more than a few times while learning and debugging, and then run never.
This situation has the corollary that teaching languages ought almost always to opt in favour of compilation speed over speed of compiled code.
(when I started programming, developers shared a minicomputer CPU, which meant that even with Unix, which prioritises editor threads over compiler threads, ends of quarters were brutal for load average and hence system responsiveness)
For industrial languages, programs will be compiled a few times while developing and debugging, and then run many, many more times in production.
For a teaching language, programs will be compiled more than a few times while learning and debugging, and then run never.
This situation has the corollary that teaching languages ought almost always to opt in favour of compilation speed over speed of compiled code.
(when I started programming, developers shared a minicomputer CPU, which meant that even with Unix, which prioritises editor threads over compiler threads, ends of quarters were brutal for load average and hence system responsiveness)
You say this as if fast compilation speed somehow means bad performance.
This is a false dichotomy. Pascal compiles fast and runs fast.
Then there's the fact that performance of a program depends on far more things than the language it's written in — and faster iteration cycles ease optimization and profiling on the level of algorithms, which is where you have most gains.
Squeezing that potential 3% speed up from using another language is rarely worth it then.
This is a false dichotomy. Pascal compiles fast and runs fast.
Then there's the fact that performance of a program depends on far more things than the language it's written in — and faster iteration cycles ease optimization and profiling on the level of algorithms, which is where you have most gains.
Squeezing that potential 3% speed up from using another language is rarely worth it then.
[deleted]
egypturnash(2)
Turbo Pascal was in the running with assembly language for my favorite language to program the IBM PC in the 1980s. ISO Pascal didn't have the facilities to do systems programming, like trapping an interrupt, but Turbo Pascal did. Even BASIC had PEEK and POKE which are unsafe but let you target hardware registers.
I fell out of the Pascal habit when I got to college because Turbo wasn't available for the Sun 68k and SPARC not to mention HP PA RISC workstations we had and soon I got my first 32-bit "home" computer and was using Linux so of course I switched to C, though I think mostly it was a step back.
I fell out of the Pascal habit when I got to college because Turbo wasn't available for the Sun 68k and SPARC not to mention HP PA RISC workstations we had and soon I got my first 32-bit "home" computer and was using Linux so of course I switched to C, though I think mostly it was a step back.
The last version of TP I used was I think 7? and it added in inline assembler. It was super nice for 14 year old me to learn assembly just enough to do the things TP couldn't do (like control a mouse on DOS). It was my gateway to a life of software development.
I used that a bit (absolutely great) but that was near the end of my TP career, for the most part I wrote library subroutines in assembly.
For instance, the 8086 had a REP MOVS instruction that copies a block of bytes, the TP standard library used that for the copy data function. 80186 added REP MOVSW which would move 2 bytes at a time and be about two times faster on my 80286 machine. I had several replacements for library subroutines which took advantage of 80286 instructions to get much better performance.
For instance, the 8086 had a REP MOVS instruction that copies a block of bytes, the TP standard library used that for the copy data function. 80186 added REP MOVSW which would move 2 bytes at a time and be about two times faster on my 80286 machine. I had several replacements for library subroutines which took advantage of 80286 instructions to get much better performance.
[deleted]
Inline Assembly was already on Turbo Pascal 4.
Wikipedia claims that TP 6 added inline assembly, I looked at the TP 4 manual and found you can write
procedure FillWord(var Dest,Count,Data: word);
begin
inline(
$C4/$BE/Dest/ { LES DI,Dest[BP] }
$8B/$8E/Count/ { MOV CX,Count[BP] }
$8B/$86/Data/ { MOV AX,Data[BP] }
$FC/ { CLD }
$F3/$AB); { REP STOSW }
end;
It is about having the feature available in some form.
Well, prior to 7 I had the yellow one. 6? and no books or manuals, just some snippets from a Peter Norton book I got from the library enough times that the librarian asked me to not check it out for two weeks once. I got 7 for christmas and it came with the manual and maybe I mis-remember the difference between "added" and "I learned about it then"
Ah yes, and then was it Borland Pascal? I seem to recall a nice IDE through my old rose tinted glasses. But 8086? PC assembly I didnt get along with, having been spoiled with DevPac and 68000 Amiga world. But I had a lot of fun with the box drawing characters in the IBM PC 'font' putting together a small Pascal windowing utility blitting chunks of memory to swap overlapping window focus.
> Turbo Pascal was in the running with assembly language for my favorite language to program the IBM PC in the 1980s.
Teaching myself programming as a kid in the late 80s I encountered the limits of BASIC and then Turbo BASIC pretty soon. Everyone I knew was dabbling in Turbo Pascal but for some reason I can't really recall I rented K&R at the local library and went for Turbo C. I got an incredible amount of mileage out of that decision.
Learning x86 assembly was par for the course back then. Everything was so slow and that was the way to get everything out of the machine. I even remember me going to some length dabbling with the timer for the CPU hogging DRAM refresh cycle to squeeze out the last few percent of CPU power that poor 8086 had. Basically moving away from the conservative settings towards a point where the DRAM was just not becoming "forgetful".
Teaching myself programming as a kid in the late 80s I encountered the limits of BASIC and then Turbo BASIC pretty soon. Everyone I knew was dabbling in Turbo Pascal but for some reason I can't really recall I rented K&R at the local library and went for Turbo C. I got an incredible amount of mileage out of that decision.
Learning x86 assembly was par for the course back then. Everything was so slow and that was the way to get everything out of the machine. I even remember me going to some length dabbling with the timer for the CPU hogging DRAM refresh cycle to squeeze out the last few percent of CPU power that poor 8086 had. Basically moving away from the conservative settings towards a point where the DRAM was just not becoming "forgetful".
I saw Pascal on the VAX (sucked) in school before I really got into Turbo.
I saw C before I started using Turbo because I had a C compiler for the 6809 using this Unix-clone OS
https://en.wikipedia.org/wiki/OS-9
on a TRS-80 Color Computer and I was checking out the K&R C book and also the AT&T UNIX manual from the public library a lot: I had a project of implementing many of the "software tools" such as wc for OS-9 as well as developing tools compatible with ones people were using on CP/M bulletin boards like
https://en.wikipedia.org/wiki/LBR_(file_format)
and
https://en.wikipedia.org/wiki/SQ_(program)
(Now I tried that last one in Microsoft BASIC and boy the bit handling was painful)
I saw C before I started using Turbo because I had a C compiler for the 6809 using this Unix-clone OS
https://en.wikipedia.org/wiki/OS-9
on a TRS-80 Color Computer and I was checking out the K&R C book and also the AT&T UNIX manual from the public library a lot: I had a project of implementing many of the "software tools" such as wc for OS-9 as well as developing tools compatible with ones people were using on CP/M bulletin boards like
https://en.wikipedia.org/wiki/LBR_(file_format)
and
https://en.wikipedia.org/wiki/SQ_(program)
(Now I tried that last one in Microsoft BASIC and boy the bit handling was painful)
OS-9 was a gateway for a lot of good developers. Constrained (8/16-Bit) enough to make you think but having a lot of the tools and ideas from mainframe/Unix world.
It was part of the strange CoCo experience. The CoCo had a superior CPU in that the 6809 was a great target for conventional compilers (as opposed to the 6502 which would drive you to virtual machine techniques like UCSD or Wozniak’s SWEET16)
Yet the 32 column text size was worse than the already bad 40 cols common on micros. It did not have the great audio of the C64 but the shack sold numerous upgrades like the Orchestra 90, you could even pack in four upgrade cards with the multi-pack. It was insane how many upgrade you could buy (like a digitized tablet, many kinds of dot matrix and letter quality printers, speech synthesis oak). Disc drives cost more than the Coco but they were way faster than the affordable 1541 that C64 users had)
I had a DEC printing terminal (with an acoustic coupler modem on the side!) and a TRA-80 Model 100 attached and could log in with three user sessions. I had a UART for one serial connection, the bit banger was fast enough for a printing terminal!
My Coco 1 starting burning up power supplies so I got a Coco3 which had 80 col text and a real windows + mouse experience for OS-9 but the third party software situation was terrible so I got a 286 machine in 1987, a time where I see Byte magazine is overrun with ads for PC clime builders. I got the money from a consulting project I did, I was told years later how much value my project made and should have asked for enough money to buy a 386.
Yet the 32 column text size was worse than the already bad 40 cols common on micros. It did not have the great audio of the C64 but the shack sold numerous upgrades like the Orchestra 90, you could even pack in four upgrade cards with the multi-pack. It was insane how many upgrade you could buy (like a digitized tablet, many kinds of dot matrix and letter quality printers, speech synthesis oak). Disc drives cost more than the Coco but they were way faster than the affordable 1541 that C64 users had)
I had a DEC printing terminal (with an acoustic coupler modem on the side!) and a TRA-80 Model 100 attached and could log in with three user sessions. I had a UART for one serial connection, the bit banger was fast enough for a printing terminal!
My Coco 1 starting burning up power supplies so I got a Coco3 which had 80 col text and a real windows + mouse experience for OS-9 but the third party software situation was terrible so I got a 286 machine in 1987, a time where I see Byte magazine is overrun with ads for PC clime builders. I got the money from a consulting project I did, I was told years later how much value my project made and should have asked for enough money to buy a 386.
Long before Python and Java, there was $49.95 Turbo Pascal for DOS!
https://en.wikipedia.org/wiki/Turbo_Pascal
https://en.wikipedia.org/wiki/Turbo_Pascal
With a great TUI experience, that apparently is now so fashionable, as if modern computers couldn't do more than DOS.
I loved Turbo Vision, but that was almost 40 years ago.
We can do better.
I loved Turbo Vision, but that was almost 40 years ago.
We can do better.
I always liked Pascal but apart from being “nicely structured and thus good for beginners” the article doesn’t convince me that I should use it again. Probably would use Ada instead anyways, as that has some really good ideas and I always got along with it
Same but in both case, I am not sure what to actually program with Ada every time I try to learn it again. I am a bit to used to web/data programming I guess.
How about "performs as fast as C++, compiles as fast as Java"?
One of the first languages I learned, along with Basic and PL1. But I bought a Mac, and, at the time, they were programmed in C.
Pascal was the language that AP Computer Science was taught in in the mid-90s when I took it. We used Turbo Pascal 6.0 for DOS, and I have fond memories. I think I'd still prefer C, but I appreciate the nostalgia.
Turbo Pascal 6 was the first high-level language I learned after BASIC and my first job out of college was doing Delphi development. I loved programming in Pascal, not so much because of the syntax (it gets a bit clunky at times) but because of the speed and ease-of-use of the development environments. Similar to having a REPL in a language, fast compilation is amazingly helpful for development iteration. If you can test ideas quickly, you can reason about things more quickly (at least in my experience).
[deleted]
I expected perhaps a reference to Brian W. Kernighan's excellent critique of Pascal from a systems programming perspective:
https://www.lysator.liu.se/c/bwk-on-pascal.html
I love Pascal's clarity, and enjoyed writing several years of Pascal and two years worth of Modula-2 in the 1980s and 1990s, but one has to admit Brian has some good points.
If Pascal was still actively used by more people, a new version of its ISO standard could incorporate many things that "happened since" if the community so choose.
https://www.lysator.liu.se/c/bwk-on-pascal.html
I love Pascal's clarity, and enjoyed writing several years of Pascal and two years worth of Modula-2 in the 1980s and 1990s, but one has to admit Brian has some good points.
If Pascal was still actively used by more people, a new version of its ISO standard could incorporate many things that "happened since" if the community so choose.
> Brian W. Kernighan's excellent critique of Pascal
Well, most of it was obsolete before the paper appeared (see Apple and Lisa Pascal), and the reason Pascal became very popular in the eighties was not the version Wirth created, but products like Turbo, VAX or Object Pascal, or the ones mentioned, and of course later also Delphi. Even Wirth himself demonstrated in his Oberon System, that the system could not be implemented without direct memory read write and pointer arithmetics (via SYSTEM module, and mostly without support of a type checker). The Pascal ISO standard came much too late and had little significance.
Well, most of it was obsolete before the paper appeared (see Apple and Lisa Pascal), and the reason Pascal became very popular in the eighties was not the version Wirth created, but products like Turbo, VAX or Object Pascal, or the ones mentioned, and of course later also Delphi. Even Wirth himself demonstrated in his Oberon System, that the system could not be implemented without direct memory read write and pointer arithmetics (via SYSTEM module, and mostly without support of a type checker). The Pascal ISO standard came much too late and had little significance.
That version not only did exist, it was called ISO Extended Pascal, however by then Apple's and Borland's Object Pascal was what everyone cares about.
That critic has nothing of excellent other than for UNIX heads.
It ignores that for quite some time, outside UNIX, C only existed in various dialects of K&R C like Small-C, RatC, and whatever else was around on CP/M, competing mainframes and what not.
Also ignores the existence of Modula-2, released three years prior to that rant.
That critic has nothing of excellent other than for UNIX heads.
It ignores that for quite some time, outside UNIX, C only existed in various dialects of K&R C like Small-C, RatC, and whatever else was around on CP/M, competing mainframes and what not.
Also ignores the existence of Modula-2, released three years prior to that rant.
That wasn't a "rant", no matter how much it offends you.
Here's what it actually was: Kernighan and Plaugher wrote a book called "Software Tools". The code in it was written in RATFOR, which is a preprocessor for FORTRAN. After that book was written, Kernighan got the idea of re-writing it using Pascal. And it was hard - much harder than he expected. So after he did so, he asked himself, "Why was that so hard? Pascal should have been much better than RATFOR, and it wasn't. Why not?"
That's what the paper is about. (It's not even about C, so what C dialects existed, and where they existed, is completely irrelevant.) And the paper says that's what it's about.
And, having used an ISO standard Pascal, every word of it is true. (The only exception was that we had separate compilation.) Almost everything he said, I ran into. The problems were real, and they were painful.
Why didn't he use Modula-2? Because he didn't write the book in Modula-2. And why didn't he do that? He started the book in March 1980. Modula-2 probably had much less traction than Pascal at that time, so Pascal was a more reasonable language to pick for the book.
Here's what it actually was: Kernighan and Plaugher wrote a book called "Software Tools". The code in it was written in RATFOR, which is a preprocessor for FORTRAN. After that book was written, Kernighan got the idea of re-writing it using Pascal. And it was hard - much harder than he expected. So after he did so, he asked himself, "Why was that so hard? Pascal should have been much better than RATFOR, and it wasn't. Why not?"
That's what the paper is about. (It's not even about C, so what C dialects existed, and where they existed, is completely irrelevant.) And the paper says that's what it's about.
And, having used an ISO standard Pascal, every word of it is true. (The only exception was that we had separate compilation.) Almost everything he said, I ran into. The problems were real, and they were painful.
Why didn't he use Modula-2? Because he didn't write the book in Modula-2. And why didn't he do that? He started the book in March 1980. Modula-2 probably had much less traction than Pascal at that time, so Pascal was a more reasonable language to pick for the book.
Not only it is a rant, it shows the ignorance of the Pascal ecosystem, or the unwillingness to actually learn or make a fair point.
Otherwise getting an augmented Pascal system like plenty folks were doing shouldn't have been a big problem.
The situation with C is fully relevant, because it shows the duality of his views, in a text that is used as a kind of biblical message by many UNIX monks.
I also have used ISO Pascal, only because the university professor was religious about it on assignments, as the DG/UX Pascal compiler had enough extensions to our disposal.
Otherwise getting an augmented Pascal system like plenty folks were doing shouldn't have been a big problem.
The situation with C is fully relevant, because it shows the duality of his views, in a text that is used as a kind of biblical message by many UNIX monks.
I also have used ISO Pascal, only because the university professor was religious about it on assignments, as the DG/UX Pascal compiler had enough extensions to our disposal.
The success of the extensions added to UCSD, Apple, Lisa and Turbo Pascal demonstrate that Kernighan's findings, which only focused on Wirth's original Pascal, were not as wrong as you assume. Lisa, Turbo, Object and VAX Pascal essentially supported the same kind of pointer manipulation as C. And if we take a close look at the Oberon System, even Wirth depended on this feature (although it was actually a backdoor of the language and bypassed the type checker), or he directly escaped to assembler.
Same can expressed to the success of the extensions added to K&R C, starting by inline Assembly, but apparently extensions in C were good to have, bad in Pascal.
Two weights, two measurements.
Two weights, two measurements.
Apparently K&R C (which was the version at the time of Kernighan's paper) wasn't good enough itself, and it's fair to say that ANSI C also borrowed features from Pascal (e.g. function prototypes). So the influence was mutual. And I think it's pretty evident that the extensions made by UCSD and later Pascals to Wirth's original version were essential for the success. I don't think that the typical Turbo Pascal user cared much about Wirth's original version.
That was written about the "standard Pascal" (the first standard). Turbo fixed most of that. (Maybe all, in that Turbo became a de-facto standard, so that even the "all the extensions are non-standard" didn't really apply.)
Pascal was the very first language I ever learned, way back in the 70s. I have a soft spot for it to this day.
I wouldn't use it for a real project, though. It has meaningful problems and limitations that other languages don't have.
I wouldn't use it for a real project, though. It has meaningful problems and limitations that other languages don't have.
Pascal was my first "real" programming language and the language used in my CS undergrad. I even used it to develop for a bare metal 68000 system and a MicroPDP-11. But once I learned C and found how much easier it was to do embedded development, I left it behind. I have Lazarus and FreePascal and play with them now then, but it's more a nostalgia thing than anything else. I should probably try developing something useful with it one of these days.
[deleted]
Just no.
my 2 cents
we need a good free open source rad tools
the rad market is dominated by very expensive commercial products, clarion, windev (pcsoft), outsystems , embarcadero, progress and few more
pascal, give the impression of a potentially nice (could be) rad tool, that make easy things trivial and hard things possible, but i think in practice it is not really
we need a nice foss rad devolpment environment, built around nicer and more modern languages , pascal is not a nice language , lazarus and other pascal ide are attractive though
we need a good free open source rad tools
the rad market is dominated by very expensive commercial products, clarion, windev (pcsoft), outsystems , embarcadero, progress and few more
pascal, give the impression of a potentially nice (could be) rad tool, that make easy things trivial and hard things possible, but i think in practice it is not really
we need a nice foss rad devolpment environment, built around nicer and more modern languages , pascal is not a nice language , lazarus and other pascal ide are attractive though
[deleted]
It doesn't deserve a second look.
The only things Pascal has going for it nowadays are: (1) static executables and (2) some good libraries (and not many at that). As a language it's extremely primitive and unergonomic, and the Free Pascal maintainers don't really want to improve it because they are used to it.
As an implementation, it's the slowest compiled language there is. Everything is heap allocated (and reallocated) and it doesn't even have an efficient allocator, not to mention garbage collector.
The only reason there is to use Pascal nowadays is when you need one of the two things I mentioned and the results offset the torture that is programming in that language.
The only things Pascal has going for it nowadays are: (1) static executables and (2) some good libraries (and not many at that). As a language it's extremely primitive and unergonomic, and the Free Pascal maintainers don't really want to improve it because they are used to it.
As an implementation, it's the slowest compiled language there is. Everything is heap allocated (and reallocated) and it doesn't even have an efficient allocator, not to mention garbage collector.
The only reason there is to use Pascal nowadays is when you need one of the two things I mentioned and the results offset the torture that is programming in that language.
"Everything is heap allocated"
Well, the second look would prove it false, so maybe it is worth it after all.
Well, the second look would prove it false, so maybe it is worth it after all.
Yeah, well... you won't get very far with just TP-style objects and strings and without dynamic arrays.
> As an implementation, it's the slowest compiled language there
Are you talking about the Free Pascal implementation here?
Are you talking about the Free Pascal implementation here?
Yes, but Delphi is no rocket either.
Turbo Pascal will always have a sweet spot in my heart, it was the first language I learned in my first year at the uni.
I had a "Borland Turbo Pascal" book, a pirated TP and the IBM PC of my roommate. And a 8" disquette.
In still see myself after all these years programming Convey ' game of life (the lines in the screen updated 1 line per second) and wondering at 4 am how I can add a disease or Godzilla crossing the ecosystem.
Great memories.
I had a "Borland Turbo Pascal" book, a pirated TP and the IBM PC of my roommate. And a 8" disquette.
In still see myself after all these years programming Convey ' game of life (the lines in the screen updated 1 line per second) and wondering at 4 am how I can add a disease or Godzilla crossing the ecosystem.
Great memories.
I recently ported an old Pascal game to Free Pascal. I had never really used Pascal before this particular project.
Learning the language was interesting, but there's a lot about it that seemed pretty irritating, the main one being the separation of variable declarations and code (similar to the original C spec). It also took me way too long to figure out how to properly construct an 'if-then-else' block without the compiler complaining about the syntax.
Can't say I would probably use it in a new project.
Learning the language was interesting, but there's a lot about it that seemed pretty irritating, the main one being the separation of variable declarations and code (similar to the original C spec). It also took me way too long to figure out how to properly construct an 'if-then-else' block without the compiler complaining about the syntax.
Can't say I would probably use it in a new project.
You had to differentiate between C and Pascal strings, and you'd better well have declared that Mac OS call-back function in C with the 'pascal' keyword, lest you be shocked when your software crashes and you debug it in MacsBug to find the order of arguments is reversed on the stack! Doh!
In the early 90s I coded lots in Modula 2 (for what it's Wirth) on Solaris, but never got much chance to do Pascal directly.