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?
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/
Or, more specifically, Object Pascal. The work that Anders Hejlsberg did on Turbo Pascal and Delphi are very underrated, and conceptualized a lot of ideas that would bear fruit in C#.
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
The problem with Pascal is not that it is bad, but that it provides nothing of value to offset the cost of maintaining a separate toolchain, training programmers, building libraries, etc. What can you do in Pascal that you can't do in C++, or Python, or Java? Why do we need yet another language, that has no particularly useful features?
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
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.
With enough experience C is more readable. It's a bit like writing "sodium chloride" vs "NaCl". The general population will find the first one more readable because they don't have to know chemical symbols, but if you know chemical symbols, then you find "NaCl" more readable.
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.
The problem with Pascal is not that it is bad, but that it provides nothing of value to offset the cost of maintaining a separate toolchain, training programmers, building libraries, etc. What can you do in Pascal that you can't do in C++, or Python, or Java? Why do we need yet another language, that has no particularly useful features?
This could be said about any programming language. Back in my university days (we still had keypunch machines, then), I had a professor state that you could write just about anything in any language. For instance, you could write a banking app in FORTRAN or a program to calculate the trajectory to the moon in COBOL, but in the end, you should use the best tool suited for the job.
So, yes, Pascal can't do anything that C++, Python or Java can't do; that's not the point. Is Pascal better suited to some tasks than those languages? That is what the OP is really asking.
People gave up on Pascal and moved to C++ back then for a reason. Now you're asking people to go back to something which was abandoned in the past, for presumably good reasons. You need to have a **really** good reason for this, instead of just moving to a more modern language.
Is Pascal better suited to some tasks than those languages? That is what the OP is really asking.
That is also the question I was asking. I believe the answer is "no". Or at least close enough to "no" that it doesn't matter.
Where I work, we have code in C, C++, Java, Python, Perl, PHP, and JavaScript. All of those language incur a cost, and we would love to eventually pare down the list (Perl is the most likely to go). If you want to write code in yet another language you would need a VERY good justification. I just don't see any place for Pascal in a modern professional programming environment. The theoretical advantages are minimal to nonexistent, and the practical disadvantages, in tools, libraries, maintenance, integration, talent pool, etc. are substantial.
Mmmm. PASCAL was designed by Wirth as an introduction-to-programming instructional language. It was supposed to teach the logic, methodology and 'best practices' of programming as they were defined then.
Then it got adopted as a production language ... and God knows why ... and went through a few iterations to iron out the bugs and add some features and utilities that a serious production/development language would require (including, most importantly, killing that one shot compiler).
As a result it has very few strengths compared to purpose designed languages/environments
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! Both sets look synonymous but if someone told you/me that the first and second of each were different I think the second set is MUCH more clear. **HINT: there's a decimal point in the second set, so it would be natural to assume the return value would have one as well -- no such luck on the first set**
This post was generated by a Cadre of Uber Monkeys for Monkey-Man2000 (603495).
From a maintainability standpoint when you need to have code written by an experienced software developer familiar with Pascal and its various (current) compilers as opposed to an experienced software developer familiar with C++... when you hand those software packages over to another developer to continue development by somebody having to start cold on that software and fix bugs, make extension, or overhaul that code... I dare say that the software written in Object Pascal can be developed sooner than a comparable application in C++. My direct experience has been in about half of the time or less than a comparable C++ program.
That is my standard for readability. The only reason you might notice some developers who have a hard time with Pascal readability is mainly due to the fact that the developer is simply unfamiliar with Pascal syntax due to a lack of development in that language for a prolonged period of time. Handing Object Pascal code to somebody else already familiar with the language clearly has a huge advantage.
Just because it is different doesn't mean it is worse. It might mean that you would need to personally take some extra time to learn another programming language. Besides, for a Pascal programmer, curly braces are for comments and stand out very well for that purpose.
Why do you need native binaries? You can package the Java JRE with your app so it can be run if no Java is installed.
Having to wrap small utilities with an installer and a big JRE stinks. Plus there are licensing considerations when redistributing the JRE. No?
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! Both sets look synonymous but if someone told you/me that the first and second of each were different I think the second set is MUCH more clear. **HINT: there's a decimal point in the second set, so it would be natural to assume the return value would have one as well -- no such luck on the first set**
You take a single case (Div vs /) to explain the whole idea. Thats not right.
There are even contests to make porpusefully obfuscated C code !
C is one of the most unreadable languages in wide scale use, period.