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.
> 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".
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
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.
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.
Note that {} is a comment so this is raw machine code expressed in bytes where you can substitute in addresses or other values. Not as cool as what came later.
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.
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.
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)
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.
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.
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.
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)
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.
As a Mac developer (system 6, 7) in the late 80s, I always wrote in C. But Mac devs couldn't escape Pascal, because the many Mac OS functions (in the ROM) were from Pascal.
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.
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).
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.
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
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.
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.
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.
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.
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 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.
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.
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.
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.)
> 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.
Sadly, another case of YouTube sucking the brains out of the web. I'm much more inclined to read a blog post about Pascal than sit for an hour to listen to somebody yak.
Maybe you have it backwards and the audience is actually on YouTube and not looking for blogs. If so, then it would be sad if this were a blog post and not a video.
Maybe somebody who prefers blog posts to video will write an app that converts videos into blog posts. Seems like that should be doable with modern AI systems. Maybe it could even add and annotate images from the video. It would be an interesting feature for something like Instapaper.
> Maybe somebody who prefers blog posts to video will write an app that converts videos into blog posts.
They exist, even ones using LLMs. And they're all pretty terrible. I would absolutely use one because I can't stand getting this sort of information as a video (or even just audio). Being able to have an accurate transcript would make such videos useful to me.
But, so far, I haven't seen one that's even close to good enough.
Yes -- while many people don't want to admit it, and I myself kind of resists it, but YouTube has become a major source of content and knowledge (and increasingly TikTok, especially for younger audience). And there are lots and lots of high quality stuff, not any less worthy of a good reporting coming out of nytimes or New Yorker. It's happening, regardless of whether you want it or not.
Yeah, I read through the entire article without figuring out if it answers the question in the title. Too much ambiguity and hand waving without providing any actual examples or real arguments.
> like variables, loops, and control structures—Pascal presents these concepts in a way that feels grounded and accessible
How is any of that not "accessible" in popular languages that are beginner friendly like in Python and JavaScript? "Feels", are we actually talking about technical stuff that can be substantiated with examples or just sentiments?
> But learning debugging from a language like Pascal can be eye-opening because it forces you to think about what’s really happening in your code. Profiling, too, is something Pascal can handle well, even though resources for it are scarce.
What? Debugging and profiling in procedural languages are becoming more and more standardized with IDEs like VSCode which provide a universal/common interface regardless of which language you use, and they are getting pretty good. How does debugging/profiling Pascal force me to think about my code? I have been programming for 20 years and seen lots of languages and IDEs, and I am really curious to know what I am missing. This article does not say ANYTHING specific, just these handwavy words like "eye-opening".
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.