I feel kind of sheepish to admit that "Why Pascal is not my favorite programming language" had a huge impact on me and caused me to avoid Pascal until I was forced to deal with it because a coworker quit and dropped maintenance of an in-house application in my lap.
I was happy to realize that most of the criticism in that essay no longer applies to relatively recent versions of the language/IDE (Delphi 7 in my case).
One huge advantage if Pascal is that it is very easy to read; the code does not look or feel pretty, but it is so easy to read I could get an idea of what was going on without any prior knowledge of Pascal within a few hours.
Keywords not being case-sensitive felt weird at first, but one gets used to it very quickly.
My High School programming class was taught in Pascal (Turbo Pascal version 3 IIRC). I remember liking it just fine, but when I went to the university I switched to C because everything interesting was written in C. Also, there were no Pascal compilers in the FreeBSD (2.0) ports tree back then.
I had a notion that Pascal was a "toy teaching language" too, but for what I was doing that didn't really matter.
You've described my experience exactly. Once I got to learn C at university, I felt that I was now using a "grown up's programming language". It took a few years to realise that C's manual memory management and explicit pointer handling was making me much less productive as an application programmer.
They actually are, because Pascal knows the size of its types, while C requires using a mix of sizeof and malloc, which many people still get wrong, specially with arrays.
This really means it doesn’t permit variably-sized arrays without a hassle on pure language level, so you can’t fall from a bike because it’s wheels are buried in the basement. Manually-specialized Containers like TStringList still use GetMem() and align a pointer to an “infinite” array to that block, shy trick pretending to be safe until reinvented by mere mortal. Iirc, you had to destroy ^properties in destructor by hand too.
Pascal only seemed easier because of three things: a) explicit pointers are hard, b) strings have explicit length of 8 or 16 or 32 bit, and that was also a mess, especially in C interfacing, where PChar worked as intended only half of the time, c) no CS-hard tasks were solved in Pascal by RAD-programmers.
Don’t let your fond memories trick you too much. You can get the same/better behavior and speed by using glib, apr, objc, etc and not using pure C arrays at all.
There was no RAD in Turbo Pascal for MS-DOS, secondly I had the opportunity to live in a country where a CS degree or similar is pretty much a requirement to be hired on the field.
Quite a few parallel programming research papers were done in Concurrent Pascal during the 70s.
Besides UCSD Pascal, there were a few other OS CS research done in Pascal variants.
Variable legth arrays were available.
C string manipulation is a joke as well, given that in 2017 still doesn't have a way to handle unicode in spite of wchar_t.
The whole point of unsafe code being hard to reach for, is to force people to think instead of producing yet another artifact to hang on the CVE list.
Finally, if we are no longer discussing pure C then Pascal also has libraries and extensions, nothing special about C here.
In any case, there is no need for C when we have C++, other than keeping UNIX kernel devs happy, and legacy code.
Good points mostly, but I can’t agree on the last one. The new language you mentioned has few drawbacks that can seriously impact the development/architecting cycles (and I experienced these), so for me it must be time-proven first to meet a conclusion.
Yeah, I loved programming in Delphi back in the day, but I feel like the language isn't evolving much at this point, whereas C++ is a living language (even if it moves bureaucratically slowly) that will eventually have most of the features we want ... plus a bunch of warts we don't really want but have to keep for backwards compatibility :-)
That's exactly my evolution as an app dev as well. I understand some people write applications in which they have to wring every bit of inefficiency out of it, but the apps my employer wants don't require that kind of speed.
I had a similar experience: Pascal in high school, then switched to C by the time university rolled around (mostly because of it being a Unix environment). The big difference is that I did see Pascal as a serious language.
I almost laughed at a friend who decided to implement C in a compiler course. Having a preference for programming in a language is one thing. Trying to implement it is quite another. He should have realized that. We both had two page grammar that defined Pascal from our high school days.
You are off by about a decade. FreeBSD 2.0 was released in the mid 90s.
I still skim Slashdot too.
Most of the time I'm working on ancient versions of RHEL that are never connected to the internet so I don't exactly get to use "stacks" or anything that wants to pull code from Github. If it doesn't come on the RHEL 5.5 disk it's not available. You might be surprised how much you can do with a modest CGI script, a touch of JS, and some basic styling CSS.
I miss the days when you had to live off the manpages and vendor packages. As a former Solaris admin in a defence sector company, we were 100% airgapped. Mobile phones were handed in as you walked into the security office. None of that github internet stuff, no googling a problem.
The place had literally piles of OReilly books and that was it. Those were gold.
When I got home I ran NetBSD on salvaged sun4c and sun4m kit.
But surely you've heard of Red Hat itself? In the early 2000s, Red Hat Linux broke into a couple directions: "Fedora Linux" as the community version of the OS, and "Red Hat Enterprise Linux" as the supported, enterprise-level version of the OS (and CentOS as the community-supported version of RHEL).
Checking in as another 50 year old, still on HN, still an "engineer", experienced enough to use tools, not "stack"s.
Admittedly I didn't start with Pascal, but rather with BASIC and several assembly languages (1802, Z80, & 6809 were among the first I used). I learned Pascal after C, actually. I like things about both, but often wish that Wirthian languages would have won out.
FWIW, these days I primarily use Java, C, C++ (when I must), and a smattering of other languages, with libraries and such chosen to match the problem at hand and the environment in which it must be solved.
well I'm 27 and started with turbo pascal/delphi and I didn't hated it.
I still have the programming book, but never looked at it again in the last 10 years.
I can't speak for jandrese, but I'm over 50, was taught Pascal in college, and of course I read Hacker News! (And Reddit, Fark, and Slashdot beforehand). I'm surprised you're surprised. (I'm in a Python stack these days).
I'm 50, still on HN, and still an engineer (although I do a lot more ops and analysis nowadays).
As far as stacks go, I use whatever suits the application I want to write. I use:
- PL/SQL (mandated by my employer) for generating large batch files in an ETL process
- Python for validating the files mentioned above
- I'm evaluating the OCaml compiler set for a language I'd like to create
- I'm interested in Elixir for back end processes
- R for ML
- Prolog for prototyping a rules engine that may become the seed for a product
- I'd like to get familiar with a JS-based web framework like Angular 2 or React or one of the other ones I've been reading about
- I'm looking at Flash to develop a game with my daughter, who seems interested in coding.
I think it's important for older developers to assure younger ones that you remain interested in trying new tools and technologies as you get older. The curiosity and passion for creating don't abate. But, after you stay with an employer for a while and develop critical applications for it, then you get caught in maintaining it in that technology. Essentially, you get frozen in time in a technology stack due to the success of the app you wrote.
You also begin spending more time on ops and support.
But, you pick and choose times to introduce newer technologies, which you largely have to evaluate on your own time.
You don't have to leave the field or slink into irrelevance just because you're older.
Just crested 40 here. Was taught turbo pascal in high-school and college. Mostly use Node/JavaScript/C++ now but did a bunch of industrial controls stuff where that pascal really paid off for me.
i'm 25 and my first high school programming class was taught in borland turbo pascal as well. we did one year of pascal, one year of C, one year of Java, and then a seminar course in python.
i am happy that i learned pascal first. the focus on types, as the linked article states, was healthy for me. we didn't get into pointer manipulation in pascal, though. i'm a bit glad we waited until C for that because the "everything is an int" mentality of C helped me understand storage classes.
If you read my comment in the context of the thread, your comment makes no sense. The original article was written by one of the authors of C, that had no proper modules or object system either.
I take it you didn't read the article being discussed here, titled "Why I use Object Pascal". Delphi and UCSD Pascal (at the time of Kernighan's article) are related but not identical.
Anyway, my point was that 15 years old tool can't be dismissed as "ancient" when the critical write-up itself is 36 years old.
1. "I was happy to realize that most of the criticism in that essay no longer applies to relatively recent versions of the language/IDE (Delphi 7 in my case)."
2. "Delphi 7 was released in August 2002 (at least according to the Wikipedia page), over 15 years ago. It's hard to think of this as relatively recent."
3. "It's 21 years newer than the critical article he mentioned.."
4. "But that article was not 21 years newer than the first version of TP that was released in 1983."
5. "The first version of Turbo Pascal didn't have object system or modules."
Now, you can make your version of what we had in mind when we wrote each comment, but I'm very sure that others would agree that 2 was trying to say that criticism was invalid much earlier than 2002.
So when you say that the original article was much older in 3, it seems obvious that you're trying to say that criticism was valid because the article was about a much older version.
And then I point in 4 that criticism was no longer valid much earlier than 2002.
And then you point in 5 that TP didn't have object system or modules that's a complete non sequitur because the original criticism hardly could criticize lack of object system when its author had not made one for his own language. Actually there's a lot to say against the original article, but that's another story.
First version of Turbo Pascal isn't the language discussed in the topical write-up. Of course Kernighan couldn't be criticising Object Pascal; and the author points out that the language has picked up new features since which makes it far more bearable to him.
The point was raised that Delphi isn't "relatively recent", and if that's true, from points 1&2 it then follows that the original Kernighan criticism still applies to it. I pointed out that the criticism is much older than Delphi, giving enough grounds to think an improvement is possible in the timespan of two decades.
Then you come with Turbo Pascal 1.0 out of left field, which bears no relation to any of the points. Noone was stating Turbo Pascal 1.0 is a "relatively recent" language, nor that the K's criticism wasn't a good summary of TP1.0 era state of the art.
Despite that article being a venerated classic I felt kind of put off when I first read it because the part about arrays and strings having sizes seems... well, I guess it's aged poorly.
In the old versions of Pascal a function/porcedure only accepted an array of a fixed size (in fact you had to declare a type specifically for that size). for example if you had an array of 10 and an array of 100 you needed to write two functions to deal with it.
I was taught turbo Pascal in highschool and it was so bad that even C felt less annoying.
I was happy to realize that most of the criticism in that essay no longer applies to relatively recent versions of the language/IDE (Delphi 7 in my case).
One huge advantage if Pascal is that it is very easy to read; the code does not look or feel pretty, but it is so easy to read I could get an idea of what was going on without any prior knowledge of Pascal within a few hours.
Keywords not being case-sensitive felt weird at first, but one gets used to it very quickly.