Why Pascal is Not My Favorite Programming Language (1981)(lysator.liu.se)
lysator.liu.se
Why Pascal is Not My Favorite Programming Language (1981)
http://www.lysator.liu.se/c/bwk-on-pascal.html
10 comments
Another problem with teaching introductory programming in a Real Language, I think, is the temptation to also teach more software engineering-like things as well.
When you start measuring your experience with programming in decades rather than years, it's hard to remember learning how to program is actually kinda hard. Thus, adding things like version control and IDEs to the mix gives you less time on teaching what should be the core of an introductory programming class: how to solve problems in code. Anything else is fluff that can be ignored until the foundations have been laid.
An additional reason I think using something "weird" like Haskell or Scheme is that it's a very good equalizer (Haskell in particular). IME, this kind of class will have two kinds of student: those who already know how to program, and those who've never programmed. Those who already know how to program are mostly going to ignore the class, simply because it's known to them already; and this is a problem because the interactions between strong students and weaker ones is massively helpful, to both parties. Teaching things is, somewhat ironically, perhaps the very best way of focussing your knowledge of it. When you're explaining stuff to yourself (as it were), you can fudge the details you're a bit vague on (which is generally thue tricky bits), but if you're explaining it any vagueness is painfully obvious (I suspect this is also the reason simply explaining a problem to someone can be so helpful).
When you start measuring your experience with programming in decades rather than years, it's hard to remember learning how to program is actually kinda hard. Thus, adding things like version control and IDEs to the mix gives you less time on teaching what should be the core of an introductory programming class: how to solve problems in code. Anything else is fluff that can be ignored until the foundations have been laid.
An additional reason I think using something "weird" like Haskell or Scheme is that it's a very good equalizer (Haskell in particular). IME, this kind of class will have two kinds of student: those who already know how to program, and those who've never programmed. Those who already know how to program are mostly going to ignore the class, simply because it's known to them already; and this is a problem because the interactions between strong students and weaker ones is massively helpful, to both parties. Teaching things is, somewhat ironically, perhaps the very best way of focussing your knowledge of it. When you're explaining stuff to yourself (as it were), you can fudge the details you're a bit vague on (which is generally thue tricky bits), but if you're explaining it any vagueness is painfully obvious (I suspect this is also the reason simply explaining a problem to someone can be so helpful).
I think the move to safer languages for CS education is more to encourage people to think about the CS lessons at hand, rather than software engineering.
Learning about various list types is much easier if you don't have to worry about randomly crashing things. Learning about recursion is better in a language suited for it.
My CS education was founded around Scheme in part because it was a good language for showing how things worked. I thought the school went a little too far in that direction because outside of SQL, I had to teach myself every language I worked with thereafter. But... It did prepare me to learn those languages.
Learning about various list types is much easier if you don't have to worry about randomly crashing things. Learning about recursion is better in a language suited for it.
My CS education was founded around Scheme in part because it was a good language for showing how things worked. I thought the school went a little too far in that direction because outside of SQL, I had to teach myself every language I worked with thereafter. But... It did prepare me to learn those languages.
I learned programming with Pascal in high school, and it definitely didn't stink. It's way easier than C and lets you focus on the actual programming, not the idiosyncrasies of the language. It's very much like Python in this regard, but I think it's even better as a first languge. It's more explicit and to someone completely new to programming, that really pays off IMO.
I've taught beginning programming courses at the college level to adults for more than 20 years. In the early 1990s we used Pascal, specifically Turbo Pascal for Microsoft DOS and Windows. It worked very well for me as a language and environment for learning to program. After two courses in Pascal, students went on to C, C++, and Java.
My university has since changed the curriculum so that the first language of instruction is C++, leaving out objects and classes until after the first three courses. I experience and share the frustrations of beginning students wrestling with the minutiae of C++ coding, which leaves less time for seeing the "big picture" of programming. These struggles drain a lot of the energy which can be generated by making progress learning to program.
Some of the rationale for dropping Pascal, I think, was that "nobody" in the real world used it. This was untrue, of course, but the Pascal community didn't have the self-promotion and media buzz that Java did.
I find it curious that two languages deliberately designed for ease of instruction -- Pascal and Scheme -- should have such a bad reputation in some quarters.
My university has since changed the curriculum so that the first language of instruction is C++, leaving out objects and classes until after the first three courses. I experience and share the frustrations of beginning students wrestling with the minutiae of C++ coding, which leaves less time for seeing the "big picture" of programming. These struggles drain a lot of the energy which can be generated by making progress learning to program.
Some of the rationale for dropping Pascal, I think, was that "nobody" in the real world used it. This was untrue, of course, but the Pascal community didn't have the self-promotion and media buzz that Java did.
I find it curious that two languages deliberately designed for ease of instruction -- Pascal and Scheme -- should have such a bad reputation in some quarters.
Pascal was my 2nd language after Apple IIe BASIC. I also found it to be a great language to learn. I have some bad memories involving Delphi, though...
Without a compiler BASIC was absolutely terrible performance wise, so assembler was kind of a must (at least to me).
When I was trying to learn object orient programming with Turbo Pascal, it felt rally hard till I saw the exact compiled code. But I liked Pascal very much... and Delphi even more. Actually I liked everything about Delphi, compared to Visual Basic it was absolutely amazing and it came with the source code of its libraries! What was your bad experience with?
When I was trying to learn object orient programming with Turbo Pascal, it felt rally hard till I saw the exact compiled code. But I liked Pascal very much... and Delphi even more. Actually I liked everything about Delphi, compared to Visual Basic it was absolutely amazing and it came with the source code of its libraries! What was your bad experience with?
Does anyone use Lazarus and Free Pascal for anything? I only tinkered with Delphi when it used to come on PC Plus cover CDs back in the day, before using C++ Builder at work. I know that C++ Builder lost significant (!) market share after the name changes to Inprise and being bought by Embercarado, although those things weren't necessarily the real reasons for this market share loss.
I was pleasantly surprised to come across Lazarus and Free Pascal and thought it might be a way for my brother to do some programming, instead of C++ (which I use, but he doesn't know).
I was pleasantly surprised to come across Lazarus and Free Pascal and thought it might be a way for my brother to do some programming, instead of C++ (which I use, but he doesn't know).
I studied TP many years ago, and have fond memories of it. I looked into using Free Pascal for a system level project involving networking, threading, and concurrency (here I mean things like synchronized collections). In particular the threading and concurrency libraries seemed to be limited, and not as 'nice' as alternatives in other languages (boost, or java concurrent utils). Also the language is sufficiently complex that I decided I may as well use c or c++.
I thought that Lazarus looked easy enough to get my brother started with programming, due to the easy nature of "controls" that you drag + drop from the palette, but such a hope hasn't materialised yet. Good to know someone else looked into it though.
I note that on Mac it is still built using Carbon; not sure if Cocoa is in the works?
I note that on Mac it is still built using Carbon; not sure if Cocoa is in the works?
I really didn't like Pascal in high school, but this was ~1990 and we were using Apple IIe's, so no Turbo Pascal. I remember strings and printing being a nuisance. Later we got to use Logo and that was much more satisfying.
Please, would you read that new News ?
http://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pro...
http://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pro...
33 years later, none of this is true of FreePascal, Delphi, or any modern variant. Except maybe the cosmetics. If you think {!@#$} is easier on the eyes than begin end; well that's like your opinion, man.
I never understood all the Pascal-bashing. It's a pretty decent procedural language.
I was already familiar with this rant back in the day.
It complains about the first Pascal version, not the later Extend Pascal standard.
All the Pascal compilers target to professional developers had a common set of extensions mainly from USCD Pascal and Object Pascal (Apple), with Turbo Pascal being the one most compilers tried to be the most compatible with.
C was also a mess outside UNIX with compilers only partially supporting parts of it.
Worse, thanks to C lack of proper strings, arrays decaying into pointers and lack of reference parameters we have the current security situation that needs to fixed with tons of external tools.
It complains about the first Pascal version, not the later Extend Pascal standard.
All the Pascal compilers target to professional developers had a common set of extensions mainly from USCD Pascal and Object Pascal (Apple), with Turbo Pascal being the one most compilers tried to be the most compatible with.
C was also a mess outside UNIX with compilers only partially supporting parts of it.
Worse, thanks to C lack of proper strings, arrays decaying into pointers and lack of reference parameters we have the current security situation that needs to fixed with tons of external tools.
Some criticism about Pascal is kind of unfair, the one-pass compiler nature of the original language for example made Pascal compilers so much faster.
When I tried to learn how to program I had played around with C, C++ and Basic without understanding much, but when I finally found a Pascal book and got a copy of FreePascal I really learned and understood how it works.
Nowadays I am not using Pascal any more (I am not too sad about it), but the Borland / FreePascal Dialects offer some serious benefits. For one thing the unit system is still better than what C/C++ have to offer (text-include header files, nah) ;)
Also it is worth remembering that C back then was not what it became with ANSI C and then C99. I would not like to write in that dialect, seriously.
Thinking back I think Pascal was a nice intermediate level programming language between C and Basic that was implemented in its ways for proper reasons. The text provided has very valid points on Pascal, but the arguments that C is better are only partially convincing. C is different and I would argue that it has prevailed because it is more closer to the metal.
When I tried to learn how to program I had played around with C, C++ and Basic without understanding much, but when I finally found a Pascal book and got a copy of FreePascal I really learned and understood how it works.
Nowadays I am not using Pascal any more (I am not too sad about it), but the Borland / FreePascal Dialects offer some serious benefits. For one thing the unit system is still better than what C/C++ have to offer (text-include header files, nah) ;)
Also it is worth remembering that C back then was not what it became with ANSI C and then C99. I would not like to write in that dialect, seriously.
Thinking back I think Pascal was a nice intermediate level programming language between C and Basic that was implemented in its ways for proper reasons. The text provided has very valid points on Pascal, but the arguments that C is better are only partially convincing. C is different and I would argue that it has prevailed because it is more closer to the metal.
> C is different and I would argue that it has prevailed because it is more closer to the metal.
It prevailed because it was married with an OS (UNIX) that spread into the enterprise.
History proves that system programming languages only survive when they are married with an OS and are the only supported language(s) in the OS vendors SDK.
There wasn't nothing in C that couldn't be done in then existing Pascal dialects.
It prevailed because it was married with an OS (UNIX) that spread into the enterprise.
History proves that system programming languages only survive when they are married with an OS and are the only supported language(s) in the OS vendors SDK.
There wasn't nothing in C that couldn't be done in then existing Pascal dialects.
"Unix and C are the ultimate computer viruses."[1]
[1] http://web.stanford.edu/class/cs240/readings/worse-is-better...
[1] http://web.stanford.edu/class/cs240/readings/worse-is-better...
Unix is amazing, and C certainly rode along with Unix. But I do think C being closer to the metal is what made it popular. Unix has become widespread, but PC's spread faster sooner (giving Linux a place to land), and what made PC's spread was software. Writing C was easier and faster than writing assembler, while still being close enough to the metal to be a substitute.
> Unix is amazing
It has quite a good design decisions, but I consider that adjective for Xerox PARC systems, specially Mesa/Cedar.
> But I do think C being closer to the metal is what made it popular.
I keep hearing this from C proponents, yet I never found a use case where C dialects (this was before standards were widespread) offered more close to the metal features than Pascal dialects or other system programming languages for that matter.
Every time I ask a C code to tell me a closer to the metal feature other system programming language compilers lack, I come out empty handed.
It has quite a good design decisions, but I consider that adjective for Xerox PARC systems, specially Mesa/Cedar.
> But I do think C being closer to the metal is what made it popular.
I keep hearing this from C proponents, yet I never found a use case where C dialects (this was before standards were widespread) offered more close to the metal features than Pascal dialects or other system programming languages for that matter.
Every time I ask a C code to tell me a closer to the metal feature other system programming language compilers lack, I come out empty handed.
Just to confirm this: Turbo Pascal (at least the versions I had contact with) allowed for inline assembler and (as I read on Wikipedia page) machine code. You can't get much "closer to the metal" than this.
Allowing inline assembler is not the same thing as the language being close to the metal. Close to the metal means staying within the language but still having the power to do the same things as pure assembler.
If that is the definition, than C surely isn't close to the metal, specially since intrisics, function modifiers and inline assembler are not part of the standard.
I'd say it differently. "Close to the metal" means the language constructs correspond to ASM constructs. E.g. PL/M 86 (an early Intel language for the 8086) had something like pointers (based variables) that corresponded exactly to the addressing modes of the machine code. Their data types corresponded to register widths available. They had a string-move intrinsic that was exactly REPNZ MOVSB etc.
Yeah...Mesa/Cedar are excellent examples of how to extend Pascal to create a really first rate systems programming language. Similar with the PERQ extended Pascal used to write POS. And of course the Modula->Ada line are are pretty decent to outstanding systems programming languages.
> Pascal dialects
This is, of course, the important point. The 1974 Wirth defined version of Pascal was pretty crappy, or at least limited, as a systems language and even the 83 ISO standard didn't much change that. However, the variations and extensions that emerged fixed those shortcomings pretty fast, to the extent that Kernigans paper was almost out of date wrt "contemporary" Pascal when it was published.
> Pascal dialects
This is, of course, the important point. The 1974 Wirth defined version of Pascal was pretty crappy, or at least limited, as a systems language and even the 83 ISO standard didn't much change that. However, the variations and extensions that emerged fixed those shortcomings pretty fast, to the extent that Kernigans paper was almost out of date wrt "contemporary" Pascal when it was published.
the one-pass compiler nature of the original language for example made Pascal compilers so much faster.
When I first saw Turbo Pascal compile I couldn't believe my eyes. I was used to the c compilers (well, one in particular) that used 4-pass processes- and each pass seemed to take longer than TP.
When I first saw Turbo Pascal compile I couldn't believe my eyes. I was used to the c compilers (well, one in particular) that used 4-pass processes- and each pass seemed to take longer than TP.
Can you provide an example of how C is supposedly "closer to the metal" than pascal ? Both are native compiled language, and at least windows used to have its api coded in pascal rather than c before that language became dominant.
The Win16 API was written in C, not Pascal. But because it didn't have functions with a variable number of arguments, they could use the Pascal calling convention instead of the C one. It was slightly faster and saved a few bytes at each call point, which was a big deal back when memory was measured in kilobytes.
C does not semantically separate arrays from pointers, Pascal does this.
C uses indexes starting from 0, Pascal does not.
Pascal usually does not come with strong memory layout guarantees that one knows from C (packing of structs, unions, etc.)
Typecasting in Pascal is a matter of dialect.
There are probably more but I cannot remember them because I have not used Pascal in a very long while.
C uses indexes starting from 0, Pascal does not.
Pascal usually does not come with strong memory layout guarantees that one knows from C (packing of structs, unions, etc.)
Typecasting in Pascal is a matter of dialect.
There are probably more but I cannot remember them because I have not used Pascal in a very long while.
None of those points are "closer to the metal".
Only ANSI/ISO C11 does provide strong memory guarantees. Back then there wasn't even a C standard.
Only ANSI/ISO C11 does provide strong memory guarantees. Back then there wasn't even a C standard.
In C, a pointer can point to any old memory address, including core elements of the machine's BIOS and operating system. In Pascal, an array is an array, not necessarily tied to anything in the machine.
I think that's the great strength and great weakness of each language.
I think that's the great strength and great weakness of each language.
> In C, a pointer can point to any old memory address, including core elements of the machine's BIOS and operating system
You mean
An array, protected with bounds checking accessing any memory address, provided the OS protection allows it.
Don't want bounds checking? Make use of {$R-}
You mean
var
buffer : array [0..$3FFF] of byte absolute $B800:$0
An array, protected with bounds checking accessing any memory address, provided the OS protection allows it.
Don't want bounds checking? Make use of {$R-}
To be fair, the rant (and most of the misconceptions) about Pascal are about Wirth defined Pascal, not the much later extended Pascals that introduced things like "byte absolute" types. But you're right in that no one has probably tried to suffer through strict Wirthian Pascal since the last CDC Cyber got shut down except on a bet.
(Turbo Pascal on CP/M-80 was my goto for a number of years)
(Turbo Pascal on CP/M-80 was my goto for a number of years)
I remember first learning Pascal and hated it. It felt very restricted and difficult to get real work done. The type checks that are worshiped nowadays felt like a straitjacket in Pascal. C was a totally different experience. It was so open and free of restriction that I could hack anything with it. Pascal was a beginner learning language but C was hacker's language.
I never felt any restriction in Turbo Pascal and there wasn't a single C feature that I couldn't do with it.
The Hacker's language, back when I was coding in Turbo Pascal was called Assembly.
C was just for UNIX or when you wanted to do UNIX homework on your Atari ST/Amiga.
The Hacker's language, back when I was coding in Turbo Pascal was called Assembly.
C was just for UNIX or when you wanted to do UNIX homework on your Atari ST/Amiga.
Yup. Moving from Pascal to C gave me the same sort of freedom rush as moving from C to Ruby. That said, I don't use Ruby anymore, apart from the occasional command-line tool, but I still use C a lot.
I have done a lot of Javascript in the last few years though, and oddly it didn't give me that same feeling of freedom, but that might be because I'd already experienced Ruby.
I have done a lot of Javascript in the last few years though, and oddly it didn't give me that same feeling of freedom, but that might be because I'd already experienced Ruby.
TurboPascal had great inline asm, so you could hack in any way you please.
I wonder how many people learned graphics programming because of Pascal and inline asm. I wrote many a phong shader, raytracer, and other 3d graphic things back in the day using that. There was a cool Demo tutorial series by a guy called Denthor floating around on BBS's back then.
Funny how things change. Two of the deficiencies:
[For example, in Haskell, they consider it fancy that you can add dimensions to your type signature so the compiler can check if you're not doing something silly.]
Also, I programmed extensively in Pascal using the Borland IDE in the early 90s and it was one of the best IDEs I ever encountered.
As troll bait, let me just throw in this: the compiler had better inline assembly than what gcc provides 20 years down the road.
- the absence of global state
- array dimensions part of the type
[For example, in Haskell, they consider it fancy that you can add dimensions to your type signature so the compiler can check if you're not doing something silly.]
Also, I programmed extensively in Pascal using the Borland IDE in the early 90s and it was one of the best IDEs I ever encountered.
As troll bait, let me just throw in this: the compiler had better inline assembly than what gcc provides 20 years down the road.
> the compiler had better inline assembly than what gcc provides 20 years down the road.
Also...stupidly fast build-times. First time I compiled something on VS I thought the thing had frozen. Nope...just slow.
Also...stupidly fast build-times. First time I compiled something on VS I thought the thing had frozen. Nope...just slow.
Well, it's not just array dimensions as part of the type, it's array dimensions as part of the type and _no generic functions over them_.
C also has arrays with dimensions as part of the type. The trick is that the dimension must be determined statically. This is different than vectors in Haskell which allow the size of the vector to be determined (and even vary) dynamically, yet still guarantee memory safety statically (I.e. no runtime cost for bounds checking).
You can think of an array with a static size of 10 as being like shorthand notation for a struct with ten fields (sans padding). It really is no more complicated than that.
You can think of an array with a static size of 10 as being like shorthand notation for a struct with ten fields (sans padding). It really is no more complicated than that.
Try to use those arrays as function arguments.
I believe that works fine (at least in C). You have to statically put the array size into the function signature, so it will only work on arrays of that size. I was simply pointing out the difference between dependently typed vectors which have the type checker prove you use the vector correctly, and arrays in c and pascal whose sizes are known at compile time. I am agreeing with the author that this makes it hard to create generic array bounds if you don't have the ability to make unbounded arrays (as c does). I was disagreeing with the gp, who was conflating these two different sorts of types.
So I guess you aren't confortable with the C standard.
Functions don't take arrays size statically in arguments. Whatever you write is ignored.
Functions don't take arrays size statically in arguments. Whatever you write is ignored.
It's been a few years since I've written a lot of C. ufo's sibling comment reminded me of how it acts (the last dimension is ignored).
Anyway, this is completely beside the point of what I was talking about. The point is that a static size is a very different level of type system machinery from a dynamic size.
Anyway, this is completely beside the point of what I was talking about. The point is that a static size is a very different level of type system machinery from a dynamic size.
My point is that although they are static allocated, the moment you pass them as arguments, they are just another pointer.
Which leads to those beautifull security exploits.
Which leads to those beautifull security exploits.
IIRC, if you have multidimensional arrays only the last dimension is ignored so arr[3][4] is equivalent to arr[3][]. Of course, in the one dimensional case it means that the dimension is ignored.
C++ has also realized that array dimensions as part of the type are the right way forward. It's encouraged that you use std::array and avoid plain old arrays (which can't work in combination with smart pointers, for example).
Pascal and C are very much the same, and basically parents of C#. (both by Anders Hejlsberg, currently making TypeScript)
Also if you are a Pascal/Delphi guy/gal and need to build web applications, check out the smart fellows at http://smartmobilestudio.com/
Also if you are a Pascal/Delphi guy/gal and need to build web applications, check out the smart fellows at http://smartmobilestudio.com/
Anders Hejlsberg made TurboPascal. Pascal itself was created by Niklaus Wirth.
I was a huge fan of Pascal and still have fond memories - I'd still argue it is a good starting point for teaching programming principles. It's easy to pick faults in any language {Y} and compare it against {X} which is way better. I don't think that is really helpful as it ignores whatever practicalities for the time/place led to the choice of {Y}.
Anyway, I always got a chuckle from the fortune cookie :
Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value.
(http://www.j0zf.com/fortune_cookies.php?te_class=fortune_coo...)
Anyway, I always got a chuckle from the fortune cookie :
Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value.
(http://www.j0zf.com/fortune_cookies.php?te_class=fortune_coo...)
Wirth also created successors to Pascal and co-created an operating system and the hardware it ran/runs on.
I am a big fan of the Oberon family of languages.
It showed me workstation OS are pretty doable in GC enabled systems programming languages.
Sadly the industry hasn't yet decided to bet on it.
It showed me workstation OS are pretty doable in GC enabled systems programming languages.
Sadly the industry hasn't yet decided to bet on it.
http://programmers.stackexchange.com/questions/114846/why-ha... - some interested insights in a discussion initiated by yours truly
I meant "interesting" of course ;)
Very nostalgic :-). I learnt the concept of pointers in Pascal. I think it was taught for two semesters at Mysore and Bangalore university colleges. We however quickly moved on to C as that came during the final year of graduation. Fortran -> Pascal -> C was sort of general trajectory couple of decades ago in engineering colleges in India. And in all this there was Cobol; I wonder whether it's even taught now a days!
Learjet vs piper cub? There are plenty of jets designed for training and small prop planes designed to "get things done".
But in college I had to use unextended Pascal, and it sucked pretty hard. Maybe that's the point of a teaching language; make it stink to the point that students are encouraged to move to better languages. Maybe the current vocational approach of teaching a "Real Language" -- ahem, Java -- to beginning programmers is flawed because they're less likely to get experience with other, better languages. [I'm not sure how serious I am about this. I know that I hate Java, at least how it was circa 2001].