53 points | by AlexeyBrin10 hours ago
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.
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 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)
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.
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.
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;
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)
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.
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.
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.
(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)
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.
Well, the second look would prove it false, so maybe it is worth it after all.
Are you talking about the Free Pascal implementation here?
I wouldn't use it for a real project, though. It has meaningful problems and limitations that other languages don't have.
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.
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 loved Turbo Vision, but that was almost 40 years ago.
We can do better.
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
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.
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 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.
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.
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.
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.
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.
> 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".