Slashdot Mirror
Ask Slashdot: Is Pascal Underrated?
An anonymous reader writes In the recent Slashdot discussion on the D programming language, I was surprised to see criticisms of Pascal that were based on old information and outdated implementations. While I'm sure that, for example, Brian Kernighan's criticisms of Pascal were valid in 1981, things have moved on since then. Current Object Pascal largely addresses Kernighan's critique and also includes language features such as anonymous methods, reflection and attributes, class helpers, generics and more (see also Marco Cantu's recent Object Pascal presentation). Cross-platform development is fairly straightforward with Pascal. Delphi targets Windows, OS X, iOS and Android. Free Pascal targets many operating systems and architectures and Lazarus provides a Delphi-like IDE for Free Pascal. So what do you think? Is Pascal underrated?
Pascal is straight forward, something missing from most modern language which hide substantial implicit variations in how the language behaves by handing behind syntax like Perl or impossibly verbose statements like VB. I worked with Delphi professionally and still think fondly of it. Is a third-generation language, so is closer to system behavior, but is also a great teaching language which is sorely lacking from modern programming.
Here's to losing my Karma Bonus again....
One early problem with Pascal was fragmentation: while there were various decent, proprietary, dialects that let you actually write code that did stuff, *standard* Pascal was as much use as a chocolate teapot. Standard Pascal had lousy I/o and minimal libraries. the standard didn't even specify how to open a file, whereas C always had a decent subset of the Unix API as part of the de-facto K&R standard.
Had Pascal come a few years later when the IBM PC had crushed all before it, then something like Turbo Pascal might have been far more successful. However, back when there was more than one type of PC to worry about, C's huge standard library, and it's preprocessor for fixing minor dialect issues made it unbeatable for writing portable code.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
I have to agree, but it's too bad in some ways, IMO.
I used to get so much joy programming the metal or tinkering with the assembly that came out of the compiler.
Doing that is still possible, but it doesn't pay the bills.
The dream of abstraction is a bit of a nightmare for those that like to get into the guts of the machine.
GPU programming is another example, though Mantle allows the programmer to get a bit closer to the hardware.
I used Pascal in some college courses, and felt that my productivity went down by about 50% compared to C, just because of all the extra typing, and the reduced readability: begin using words for punctuation does not work as well as using punctuation for punctuation end
You felt Pascal was less readable than C ?
My university actually taught/used Pascal in the classroom in the early/mid 1980s and I graded programs written in it. Kernighan's criticisms of Pascal on BSD are spot on - I know, I tried using it for a (more) serious project. The semester project for my Operating Systems class was to simulate an interactive operating system - in Pascal.
The system used for the class was the University's IBM 4381 mainframe running MUSIC ("McGill University System for Interactive Computing") and the version of Pascal had *lots* of libraries and features.
I was a undergraduate research assistant (working on an AI project, funded by NASA, in LISP and Prolog) and had an account on the VAX-785 running 4.3BSD and wanted to use *that* (on my schedule) instead of standing in line to use the IBM. My instructor said "sure", but I'd have to port the support libraries he wrote for the assignment. Unfortunately, the version of Pascal on BSD was just the basic language - as specified in the Language Definition book by Jensen and Wirth. Porting the code from the "richer" version of Pascal on the IBM/MUSIC to the "basic" version on VAX/BSD was simply not possible.
So, I asked my instructor if I could, instead, do the semester project in C. He said "sure", but, again, I'd have to port his libraries from Pascal to C. Now... I didn't know C at the time, but porting his code to it and doing my semester project in it was a great introduction - and I passed the class. All-in-all, this experience help me out immensely with my CS career as I do a LOT of cross-platform work in many programming languages - though not Pascal :-)
It must have been something you assimilated. . . .
Pascal was my first procedural language, after spending a year with BASIC on PET computers in the classroom (1982). We used TurboPascal on CP/M, and it allowed me to start writing serious software, as act as a gateway to C and later C++.
Today? I'd probably want to start a new student with C# or Java, but the concepts working with C and Pascal are more relevant to understanding the underlying mechanics of compiling code and coding "closer to the metal".
On the other hand, early BASIC was probably an easier transition to Assembler (who codes in that any more, though?).
The prevalence of java isn't due its* APIs, it's** because "everyone else does it, too" in the enterprise, meaning a large pool of mediocre and therefore interchangeable code grinders. That this then results in lots of APIs that no single person can keep in his head all at once is only to be expected, but hey, we have GUI-enabled IDEs to solve that problem for us, don't we? But that last bit really isn't the selling point. It's that pool of readily available interchangeable people. It isn't a coincidence that the off-shoring out-sourcing craze throve on "low-skill tasks, like programming". That's typically (often stunningly low quality) java because those out-sourced-to people wouldn't have a prayer of writing C and having it run and not crash consistenly. Those who employ java coders generally aren't going for the high-brow stuff, they have boring business logic to get written and run.
* possessives get no apostrophe.
** apostrophes indicate contractions, which you can expand.
IMHO it takes a very experienced programmer to avoid pitfalls like the fine difference between integer and floating point division. As in 22/3 vs. 22/3.0 where the difference is easily overlooked.
Pascal uses entirely different operators which makes the difference stand out more. The above example would be 22 div 3 vs. 22/3 (optionally you could write 22/3.0 but it would be the same as 22/3).
C - the footgun of programming languages
I worked on an industrial project that consisted of a couple of million (with an "M") lines of Pascal. We used IBM's Pascal/VS dialect. Pascal/VS had extensions that made it very, very close to Modula-2. We used Pascal because it was portable (across IBM platforms) and strongly-typed. At the time, it was the only strongly-typed language available to us. Our error rate (bugs reported by customers) was incredibly low, because it was really hard to make many of the screw-ups that were then common in PL/1, Fortran, and c. We ended up with a system that ran across IBM's product line (mainframes, workstations, PC's).
As Pascal aged (we could see that support would be ending), we moved to C++ by converting the entire code base into a subset of C++ (using a software package we purchased and thousands of lines of AWK and sed). We used C++ as a "strongly typed subset" of "c" for about 10 years, before we started converting to objects and methods.
That project started in the 80's and is only now (almost 30 years later) being rolled up and decommissioned. The original architecture was very structured, streamlined, and simple; with an incredible amount of effort going into defining data structures (as befit the restrictions of Pascal, like no dynamic arrays). It held up very, very well. Still blows the doors off its competition in performance, but the company is getting out of development and support, and needs something it can buy (even if it's slower and has less function.)
40 is old for a software developer. Someone who is 40 today entered college just as web browsers were being invented. You could not just connect the dots on library calls to put together an application then. Now you can.
I have a strong sense of wanting to know how things work that comes from having built a lot of software in the 80's and 90's, when you had to know the internals to make progress. That is downright counterproductive in web development now. By the time you learn enough to understand how a library works, the developer who just learned enough to use it already shipped their code. That's the sort of disconnect between age ranges at work now.
. What can you do in Pascal that you can't do in C++, or Python, or Java?
So the world only needs 3 languages? Everything from Lua to OjectiveC to Javascript to Haskell... we already have C++, Python, and Java.
And frankly that's an odd 3 to choose. Why Python? Why not Javascript? Why not Lisp?
Maybe we just need Pascal, Lisp, and C#.
"all the extra typing"? I don't even know what to say to that. 99% of programming, is design and debugging. 1% is the actual "typing out the code". If you lost 50% of your time to typing out the code due to typing out begin and and I've got serious concerns about the design.
and reduced readability
begin
Formatting, indentation, and syntax highlighting make using being and end work just fine as block markerers.
end
Plus I admit I hate python's semantic white space. At least begin and end don't get mangled simply by copy and pasting a snippet. And since all the semantic information is in the content, the IDE can do the pretty formatting FOR YOU to improve readability.
Wow, I hope you're not suggesting 22 div 3 vs. 22/3 is more intuitive to a novice for what it does compared to 22/3 and 22/3.0!
A properly designed compiler (like Turbo Pascal and later Delphi) makes no distinction nor software penalty for using either convention. This is nit picking at such a minor detail, although as a software developer I like to emphasize that I am using an integer division as opposed to floating point, thus deliberately use the div operator when appropriate. For a novice, it shouldn't make any difference at all.... particularly for the kinds of applications developed by a typical novice that would have any sort of confusion over this issue (or some C++ developer tasked to do some Object Pascal debugging).
Whenever I find myself needing to manage a group of younger dudes, I look around for some big problem they've been stuck on. And then I solve it, while lecturing on the context of how software like that has been built in various decades. Once someone has watched you quietly take out software enemy #1 on a project, they stop trying to mess with you on their reports.
For a beginner, Pascal may seem more readable. For an experienced programmer, C wins. Words like 'begin' and 'end' look too similar to user-defined variables, whereas the curly braces stand out well.
Actually, for a certain programmer of long experience, I can say that I've never been suckered into thinking a stand-alone word like "begin" or "end" was a variable expression or fragment thereof.
I can say that words like "begin" and "end" stand out more (geographically speaking) than the smaller single-character braces, which aren't even fat characters. Just skinny little wiggly lines that are relatively easy to skip over, even when syntax-highlighted.
Two things that do frost me about brace-style programming languages:
1. Any language that doesn't mandate that dependent clauses be wrapped in some sort of delimiter pair is inherently dangerous. I've been burned more than once by code that didn't contain braces that went haywire because I put a simple debug print right after an "if" and forgot what it did to the existing logic. IIRC, pascal begin/end are not optional.
1a, You want to see REAL mayhem, look at one of the COBOL programs I've had to support where generations of "patch-style" programmers have had their way with complex conditional logic. In the original COBOL, even a pair of curly braces was too obvious. COBOL goes on and on until someone slaps down a single dot. At which point the entire if/then/else-pius-nested-conditionals comes to an abrupt end. I've seen stuff where a page and a half separated the primal "IF" from the ending ".".
2. A lot of begin/end languages have unique keywords to bracket clauses. if/endif, loop/endloop, do/while. Brace-delimited languages often use braces for multiple types of controlled clauses, which means it's much easier to lose track of what pairs with which. Not a few C and Java programs I've seen have even resorted to appending comments to their closing braces to make it clear what paired with what.
Pascal, the base language created by Niklaus Wirth, was a nice little strongly-typed toy language. I say "toy" for a very good reason: it had no standard way to modularize. In theory, you'd have to write every program all in one source file! There was also no way around the type system, which is good for purity, but makes low-level systems programming impossible (try doing a CRC on record including floats when you can't convert it to bytes!)
They released a new standard in 1990, which I understand did not correct these flaws. There was a further standard released in the same year called "Extended Pascal" which did. However, there are only a few compilers that just use that standard with no extensions.
That's the important thing here. When you see someone saying how great "Pascal" is, they are invariably not talking about Pascal. They are talking about Delphi or they are talking about Object Pascal. While those are both great languages, they are also both different languages. A typical Delphi program cannot be built with an Object Pascal compiler, nor with a standard Pascal compiler. Calling them "Pascal" is about as accurate as throwing Ada on the list, and calling them all "Algol".
So the real answer here is, No. Pascal is not underrated. Those languages Delphi and Object Pascal might be, but Pascal is not.