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?
begin
Pascal should die!
end
In 2015 we choose languages on rich sets of apis. Java for example is almost universally hated for it's syntax yet is insanely popular. Why? 150,000 methods to choose from and frameworks galore.
No one cares about features as its not 1982 anymore where you write your own libraries. Today you have a task and a tight deadline and there is no time to program. Only time to grab a framework can tinker with it.
http://saveie6.com/
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....
However...
When the only jobs for Pascal programmers are teaching other people how to program in Pascal, you know there's a problem.
Please read my Canon EOS tech blog at http://www.everyothershot.com
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.
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. . . .
It doesn't matter what programming language you use. Go ahead and use Pascal if it's the best choice for the job.
To be a great programmer, you need to write code that reads like English. We have a framework inside of brains called English speech, reading, and writing. If you're a French speaker, or speak another European language, your framework isn't much different. A great French programmer or a great German programmer will program similarly to a great English programmer. Everybody's seen expressive code. You can look at the code and understand what it does almost instantly. Comments, variable names, abstraction, everything that makes a great programmer, all of these things come into play. Conversely, everybody's seen shitty code that takes several days to understand. I don't care what language it is. You're a horrible programmer if you write code like this. Nobody cares how clever you are, or how you've mastered the specific grammar of a certain language. You will eventually move on and someone else will have to modify your code. The best place for clever code is in the trash bin.
To be a great programmer, you need to be able to plan out what you're going to do in advance. Everybody's worked with hacked together shit, and has had to maintain it. Hacked together shit wastes programmers' time. Spend a few days doing absolutely no "programming" whatsoever. Instead draw some flowcharts, try out a rough prototype, brush up on some theory, write up an estimate, and have someone else review everything.
Learn to be realistic about how long your work will take. I know, genius programmer, you can get everything done in about a day. Be true to yourself and don't try to impress anybody with your speed coding abilities. Take your time, and get it done right. Spend an entire day or several days testing. There's nothing better than a launch that is bug free.
Be prepared to explain your code on a whiteboard to your own mother. If you can't explain what you're doing to your own mother, you don't understand the problem well enough, and chances are you're overlooking something. Your boss will have somewhat more expertise than your mother, but if you can justify what you're doing to her then you're probably on the right track.
Don't be that guy who jumps on every programming fad. If something been around for 20 years, it's probably worth considering. If something's been around for 3 years, perhaps the fad will die out and your company will get stuck maintaining an obsolete framework. Been there, done that.
I don't care if you went to MIT or only high school, we're all equal. You can't go away and work in your little PhD way, emerging a month later with a piece of code that everyone despises. Programming is a team effort. If you think that nobody else can write a piece of code except a PhD, then guess what? Your software is likely to fail, because nobody will be able to maintain it, especially when that PhD leaves to go be a professor at Stanford.
I've seen these mistakes repeated over and over for all 25+ years I've been a programmer.
I often feel like everyone on Slashdot is a mix of two people
- Old 50+ year olds used to the good 'ol days when you would write your own stack from scratch whenever writing an application
- 20 year olds fresh out of (or still in) college who yell "squirrel!" at everything new and shiny
The truth is, that 75% - 90% of the business applications that make the world go 'round, and make nearly every startup today go 'round, are based on Java or some complimentary technology like Node.js with Java bindings. The reason for this is simple: The Apache foundation. There are SO MANY amazing enterprise-class Java libraries available via the Apache project that there is little to no reason to ever write your own. The mantra where I work, and it should be where EVERYONE works, is before you write any plumbing code at all, check Apache first. People who roll their own plumbing code INVARIABLY end up with subtle errors they did not think of or subtle problems that will manifest themselves in 2 or 3 year when they try to scale.. and all these problems were likely already figure out long ago.
When building a woodsheed, do you cut down the trees, mill the lumber, and forge the nails? Of course not, you take advantage of modern economies of scale so you can focus on the REAL building project, not the building blocks. The same is true for any halfway competent software developer.. The days of people writing their own libraries for DB MVC, for configuration management, for network access, for parsing libraries, for thread pools.. these days are gone, and thank god. The less you have to worry about the low-level plumbing, the more you can focus on the real business problem. And furthermore, the more people that make use of a low level plumbing libary, the better and more secure and stable it becomes, for everyone.
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.)
I am amazed that almost no one seems to be aware that Dr Wirth is 3 generations of software beyond his original Pascal.
He also created Modula, then Oberon and is now working on Project Oberon using Oberon-7.
The spin off company Oberon Microsystems created the framework BlackBox and a superset of Oberon called Component Pascal.
Component Pascal is now maintained by the user community and is open source.
http://blackboxframework.org/i...
I don't especially like Pascal but I love Component Pascal!