A new Lazarus arises – for the fourth time – for Pascal programming fans Lazarus 4 is the latest version of the all-FOSS but Delphi-compatible IDE for the FreePascal compiler. The Sons of Kahn and the assembly language of the internet READ MORE The IDE is developed independently from the underlying Pascal language that it's written in, so this doesn't mean a whole new version of FreePascal: …
If Pascal had remained in the form that Mr. Kernighan describes, it would certainly by now be relegated to the annals of history.
Fortunately, it's moved on, like most languages, and most of the issues he describes are no longer relevant. One might criticise the lack of forethought in design for some of the issues, e,g, statement separator vs terminator.
Still, it's an interesting historical observation.
What he wrote is no longer valid in Borland Pascal for at least the last thirty years, if not earlier. Anders Hejlsberg did improve Pascal a lot - and that's why Microsoft poached it to desing new Microsoft development frameworks. He is a far better language designer than Kernigan and Stroustrup. And still Pascal is a much safer language than C/C++. Hejlsberg COW strings doesn't allow the ptifalls of C.
I still find incredible that too many people still think actual Pascal is what Wirth designed fifty years ago. It is like people though C is the same K&R C of the same time, and C++ never improved.
The problem is now Pascal lacks someone like Hejlsberg to move it forwart and keep it relevant. The actual owner of Delphi is just milking the last desperate cows, and FPC/Lazarus don't have someone wiith this skils. And many of their contributors really write ugly Pascal code (and with amateurish formatting). Opening many of their libraries make you long for the old TP/Delphi ones.
The dark side of Delphi was it made so easy to write decent Windows applications that it attracted too many lame developers who never spent the time to really understand the language and improve their skills. And Borland failed to sell Delphi to more skilled deveopers, aiming it a Visual Basic ones.
BWK's comparison between C and Pascal liked to a Learjet and Cub Piper is probably unfairly boosting C. A F104 Starfighter† might be a fairer comparison.
I never actually used Pascal until later in a mathematics operation research course for a dynamic programming assignment - Pascal rather than Fortran because the lab had a fleet of microcomputers (Exidy Sorcerers?) running custom software including a Pascal system.
Ironically I investigated C after reading Software Tools in Pascal by Brian W. Kernighan & P.J. Plauger which was the project that led to the opinions expressed in the linked paper.
C in 1981 like Pascal are very different beasties from their contemporary descendents. Likewise some of BWK's coding idioms such as exiting a loop using "break" probably not de rigueur today [doesn't preserve the loop invariant and you can't assert the negated loop guard (~G & Inv)].
† aka the widow maker.
I need to mention here that the book does not go into Windows programming, OOP, software components, or the Lazarus GUI builder.
Since he is 'distilling' his previous pre-GUI tutorials, I can understand skipping Windows programming, because they stopped at BP 7, and OWL is no longer relevant. And the book is about FreePascal, not Lazarus. But no OOP? That doesn't make sense to me. Sure, skip over Delphi extensions, but OOP is a pretty valuable tool for Pascal programmers.
Interesting article.
Almost completely and utterly wrong, but interesting. Explains a lot about Rust.
Things like ECS and messages are orthogonal to OOP.
Though you pretty much need OOP to implement either of them in a reasonable fashion - otherwise, how does one extend or replace parts of an existing component or message?
There's a reason why almost every large C library has objects, despite it not being part of the language.
Though you don't need OOP to use them - declarative is very powerful.
"Almost completely and utterly wrong, but interesting."
An admirable illustration of the "all you have is a hammer" principle in taking an inappropriate use of OO as a counter example of the whole in favour of sequential data processing and pipelines.
As a counter example I'd offer my little Object Pascal file card program with different card types for text, tabular and image data, an absolute natural for OO in presentation. For storage, however, I had two options, a database (underlain by a set approach) such as SQLite or text which involved sequential processing.
Or my crossword assistant. It would be unreasonable to expect SWMBO to construct a grep command so it gets encapsulated in OP with the output displayed in a TMemo object.
Successful application development requires thinking in whatever mode is appropriate - OO, sets (OO fundamentalists freak out at the idea of an RDMBS), sequential or anything else that springs to mind.
Pragmatism is the true approach.
There's a reason why almost every large C library has objects, despite it not being part of the language.
Pretty much true almost trivially so.
Any language that has an aggregate data type (struct, record) and procedures than can pass such aggregates by reference can implement objects.
I always think a OO language is just the non OO one where the object reference (self, this) has crawled under the procedure name and advertised (->) itself to the left of the now rechristened method (or member function. :)
Polymorphism and Inheritance especially in OOLs lacking generics (templates) are frequently abused in an inelegant attempt to remedy that deficiency.
Just yesterday I had reason the refresh my memory concerning an Pascal derivative Pascal Plus which I recalled from a Uni course which used it as a paper† language for software development exercises (text: Sequential and Concurrent Program Structures Welsh, Elder & Bustard - one of the authors might have been the lecturer. ;) I was reminded that abstract data types and generics together are often a lot more practical than inheritance and polymorphism alone.
† I have no idea whether the language was ever implemented..
"I always think a OO language is just the non OO one where the object reference (self, this) has crawled under the procedure name and advertised (->) itself to the left of the now rechristened method"
In order to do that the language also needs to provide for the definition of methods accompanying data structures. That's the feature that makes it an OO language.
Code can be written in an OO style in any language that provides some form of data structure, much as a Basic style program can be written in an other language; it's just that adding OO features to the language makes it easier. (Writing an OO program that is, not a Basic one!)
Of course. There is a reason Go, Rust, etc. can't do OOP and even ecxeptions. It's most "programmers" can't understand OOP truly - and it makes compiler far more complex to write. And when most people start programming with JavaScript you kow they'll never learn. So let's go back 50 years in IT history. OOP is not roman numerals, it's we're noe in the Middle Ages of IT where much of the previous achievements was forgotten.
One day someone will rediscover OOP, and tout it as the best discovery of all time....
Well at least Python is OOP and far better to code with - if it coud just compile applications...
"Object Oriented design is the roman numerals of computing." – Rob Pike
I was beginning to wonder whether Bell Labs was a grumpy old men factory.
The Rob Pike quote mentions Object Oriented Design which was one of the many snake oil development "methodologies" pimped back then† and mostly deserved the comment. Reading Derrick Wippler's critique of OOP I can't say I disagree. :)
† methodology "evangelism" has never died and upon signing up the disciples for the requisite tooling is a rather lucrative calling.
Anyone who doesn't see the value of OOP should at least investigate Borland's VCL approach to the Windows API. An excellent hierarchy poster was included in older versions of Delphi and Borland's C++, I used to have it hanging in my cube in the early 2000s. VCL is one of the things I really missed when I moved to C-Sharp. (along with truly data aware components)
Of course, OOP can be abused. Just look at ORMs like EntityFrameworks. The article you referenced liked abstraction but not inheritance. They go hand in hand, and TBH, I've had more difficulty debugging contractor code due to bad abstraction rather than bad inheritance. Particularly with interfaces.
You can screw up with non-OOP languages too. Buffer overflows are still one of the biggest security threats. We've been talking about them for 30 years.
> I need to mention here that the book does not go into Windows programming, OOP, software components, or the Lazarus GUI builder.
More seriously, it explicitly says that it is omitting all consideration of the RTL (FPC standard libraries) and FCL (FPC Class Libraries).
These are, by now, utterly immense, and suffer from patchy documentation (much machine-generated), sparse indexing, and members of the user community who tell newcomers that they should be using some facility that is completely unfindable unless you know where to look.
What is worst, a lot of FPC libraries are barely commented or not commented at all. Pure amateursih programming - I don't understand why many "programmers" believe that commenst are for "losers", and that harcore ones can get everything by just reading code. And if there is something OOP makes harder, is reading code, since you have to follow inheritance.
If the "community" had asked for some kind of comments that could have led to machine-generated documentation, it woudl have been far, far better.
If the "community" had asked for some kind of comments that could have led to machine-generated documentation, it woudl have been far, far better.
Unfortunately I can't agree with this. My real-world experience with comment-based machine-generated documentation was that the only thing you could assume about the documentation was that it would be completely unrelated to the code. Even the best programmers often forgot to update the documentation comments so the resulting documentation was the worst of both worlds: it was neither up to date, nor did it correctly document any earlier version of the system!
That was supposed to be one of the main reasons for the OO approach in the first place: the code would be "self-documenting" because many relationships would be explicitly defined in the object hierarchies and declarations. Of course, it didn't work as hoped but it was probably still an advance on documentation based on text comments completely unverified by the compiler.
Machine generated comments don't work because they are making assumptions about code at a specific point of time. Generally things that are easy to see, like the methods of a class and their parameters. These tend to change over time and the auto-generated stuff never gets updated. It's not really useful anyway. Maybe someday we'll see good AI generation that evaluates what the code actually does, with some prompting from the dev about what it's intended to do.
Comments should NOT be a step-by-step discussion of the code, unless it's obscure or extremely complex. For example, it might include details on how to calculate the check-bit on a UPC or credit card number. Comments should be the intent and expectations of a method or block of code. "This method will sanitize the input string so a random hacker can't rape our system...." It could then add details as it's updated for future attacks. "* added regex to strip unwanted characters" "* clipped length to match the DB field size" etc
Ironically, a lot of what is needed for comments is put in there as methods are being stubbed out, then removed as devs do the implementation. If they had just cleaned up and moved their notes into a comment block for the original stub out, it would have been plenty. It's common for methods to get their implementation changed over time, but what they are attempting to do generally stays the same because when their purpose changes they are either overloaded or replaced completely.
Turbo Pascal and Delphi came with excellent manuals that made most "entry level" books useless unless you "sourced" the IDE "somewhere" and didn't buy it. Books were usuful for advanced programming topics.
Anyway, in TP times I believe among the best books were Rubenking ones. Which fully addressed OOP and the Turbo Vision library, the OO framework that allowed DOS UIs far more advanced than anything you can find under Linux today. And working in 640KB....
I've used both but my initial step was Pascal to C. I found them to be the pessimal* distance from each other for learning one from the other in that they do similar things in quite different ways. It's a very long time since I used C. Come to think of it, it's a long time since I've used Pascal either except for a few toy applications for my own use but as they've been GUI applications for Linux they were written with Lazarus.
* I thought I'd made it up but it really is a word.
If you don't specifiy what "Pascal" you used your post just looks like FUD. Unlike C or C++ (where there are standards most compilers adheres to), there were and are many different versions of Pascal - some greatly improved from the original Wirth one, others not so much.
The main issue of "Pascal" was it was not portable across platforms. Apple did use it extensively, but had its own compier and language extensions. Borland after some attempts on other platfors did target Windows exclusively - and the Linux version "Kylix" was so-so and anyway badly received by Linux fanboys who didn't like a "commercial" application tainting the purity of Linux - and Linux still lacks an IDE with Delphi GUI development capabilities - Lazarus is close but it's almost unknown. And IMHO FPC spends too much efforts in supporting marginal very old platforms.
Tben there were other proprietary "Pascal" for different platforms (HP, etc.) - but nothing that could be easily ported. Once Unix and especially Windows (because ot its large user base) were written in C, it became a de facto standard for easy integration with the OS (despite many Pascal are ABI compatible with C calls).
Now Delphi targets other platforms too, but it is too late.
I learnt Pascal on Borlands TurboPascal - then Borlands Turbo C because these were the compilers available to me until the day when some kindly American took pity on me, and gave me my first Linux Distribution.
All these languages that I had no idea how to use available to me.
Pascal is good for teaching you the disciple needed to write large C programs. But quickly it's like pushing rope. C relies on extensive use of the macro pre-processor for productivity, which has fallen out of favour (for mostly good reasons) so lots of people never learn "productive C".
I think learning Object Pascal is good before learning C - so one can learn to be grateful and pragmatic, while discipled. Quickly one longs for the container libraries and algorithms in the STL with C++ being a sweet spot, with some of the object Pascal affordances reframed though a C pragmatic view.
Wrong. Youn can write any application with a modern Pascal (and many did, even if you didn't know it because you have no way to know from the compiled code...) - and ther's a good chance they are safer than C/C++ ones unless the developer tried to write them using C-like constructs (i.e. using PChars instead of strings).
C macros are just code snippets. C++ "smart" pointers are needed because C++ lacks a "finally" statement because Stroustrup couldn't understand the need to free objctes properly in large complex applications. "Containers" and templates/generics are available in any modern Pascal, and have been for years, and while useful, they are a way to write some code faster letting the compier do some work for you (just like macros).
Still, I have to find a framework that matched the power of VCL to write Windows applications....
> C++ "smart" pointers are needed because C++ lacks a "finally" statement because Stroustrup couldn't understand the need to free objects properly in large complex applications.
With RAII you don't need 'finally', period. It is a real problem to rely on programmers to code consumer release instructions in the finally block, sooner or later a resource leak will occur because he/she forgot to code one of those instructions.
The main issue of "Pascal" was it was not portable across platforms.
UCSD p-System was in that, like Java, it defined a virtual processor and compiled to that processor's "machine" code, the virtual processor being implemented on a number of different platforms. The original Apple Pascal was UCSD with a 6502 implementation of the p-machine.
Kylix was badly received because it didn't work well. The IDE was Delphi on a customised version of WIne with a cross-compiler. I had code that compiled under Delphi but threw a spurious compilation error under Kylix. The real problem was that it got left behind. It was released, IIRC, towards the end of the version 2 kernel era and didn't get updated for version 4 when a lot of the underlying libraries changed. Nothing to do with Linux "purity", Borland let it die.
The problem with implematations like UCSD Pasca it was slower and didn't let programs easy access the underlying operating sustem. Useful for mainframes and some CLI OS, but not good for GUI OS. Maybe Apple Passcal in the beginning was UCSD derived, but later it wasn't - especially since Apple was the first to turn it into an OOP language - or the Koll brother would be unable to write Photoshop with it. UCSD Pascal is one of the reason Pascal got a bad name - and JRT Pascal didn't help too.
I wrote Kylix was so-so, and it was version 1 and even then it used WINE only partially fo emulate some WinAPI calls. Anyway even JBuilder first IDE was written in Delphi untile the version wholly built in Java was available. I remember the discussion back them, Borland was not welcome on Linux.
And Linux desktop remains a niche market for the lack of good development environments and libraries too. Pure, and useless. Everytime I use a Linux desktop I found myself more than thirty years in the past. Even some DOS GUI applications were better.
Agreed UCSD was non-GUI. I was using it on a Z80 and there was no underlying OS, only the BIOS. But I did use it to control micro-spectrophotometry equipment which required low-level access to the H/W for the ADC board on the S-100 bus, the extra 4-bits of ADC I added on a home-built board, the stepping motor for the diffraction grating and the HP plotter. Don't ask me how I did it because it was a long time ago and seems extremely improbably when I write it but it all worked. AFAICR it included the ability to write and call Z80 assembly so that was probably involved as well.
Actually, FPC and Lazarus have supported all Raspberry Pis from v1 onwards, and before that other ARM platforms like the NSLU-2.
They've never supported IBM mainframes and a number of others- notably the Itanic- haven't got very far, but apart from that their platform coverage is comprehensive.
I did a lot of (Modular) Pascal programming in the past, including writing code for an image processing system for microscopy. I might want to check out how easy it would be to port this stuff (I still have all the code backed up) to the newer version of Pascal. Could be fun.
Definitely worth investigating. You will find a high level of compatibility with the various "standard" Pascal implementations (ISO, Turbo, Delphi and so on), and it's fairly trouble-free particularly on Windows or Linux.
And the Lazarus IDE gives you very good debugging facilities.
There's mailing lists and a forum which is generally helpful, until some retard starts off yes another "Why isn't Pascal more popular when it's better than everything else?" thread.
My position is that it will probably "see me out". But I'm not entirely happy with the bloat that's crept into the language, or- as I've said somewhere above- the documentation situation.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
