As I get older, I'm strongly swinging into the camp that thinks languages should have strongly restrictive syntax. Object pascal is one of those languages which is both low level enough to cleanly map to efficient code, as well as high level enough not to feel really restrictive. Its a language that is completely misunderstood because far to many people read a couple critical essays, and believed everything they read, even though the strongest argument frequently was that its harder to type "begin/end" than "{/}". Which is a pretty lame thing, given code completion in editors as old as emacs.
Put another way, the thought patterns programmers fall into when using it seem to result in code which is easier to understand than most other languages which seem to encourage "perlism" (creating a single unreadable line), "forthism" (creating a billion two line words that combine to solve all the problems in one word), or a few other things which become completely unmaintainable when the project grows beyond what can be written by a over-energetic student in a semester at school.
I don't think anyone really disagrees with you -- most people have problems with the syntax of Perl, C, and C++. Sure, they can get used to it, particularly with C because it's small, but the syntax isn't why they use the language.
Somewhat surprisingly, I think Perl's syntax is one of the reasons that Python became popular. Perl can do pretty much everything Python can, and it came significantly earlier. Yet people gravitated toward Python.
I wouldn't call Python "strongly restrictive", but I would call it "just right". It's terse without being unreadable.
JavaScript syntax is also pretty sane (but there are many horrible parts to the semantics.)
Ruby seems to be pretty nice in the common cases, but there are apparently gremlins lurking in corner cases. Python has only 1 or 2 syntactic gremlins I can think of (trailing comma, etc.)
> Perl can do pretty much everything Python can, and it came significantly earlier. Yet people gravitated toward Python.
I don't think syntax is the main culprit here, and Perl is only four years older than Python. For about 15 years Python tried, unsuccessfully, to compete with Perl as the premier language for shell scripting and sysadmin tasks. It wasn't until around 2005 that Python finally caught on, its rise coinciding with Ruby. While I do personally find Python more readable than Perl, I attribute its ascent more to the combination of the Web 2.0 gold rush demanding dynamically-typed languages for quick prototyping, Perl's apparent mid-2000s limbo due to Perl 5 vs Perl 6, the then-declining reputation of PHP and the shared hosting services which first popularized it, and the quality of Python's standard library (which made up for CPAN).
It's more culture than syntax; Python culture tends to favour adhering to a common style, while Perl culture tends to valorise clever or even poetic implementation.
I think the main culprit was Perl's mess of an OO system. While technically it was the same at its core as the Python one, the almost complete lack of syntax to support OO and lack of standards (especially in those earlier days) for objects to interoperate made it needlessly complicated for most people and people moved to languages where they could just write "class Foo".
> I have long thought Perl can do anything Python can
I mean, yes, they're both Turing-complete languages, so one can be used to do anything the other can. I guess the actual question is whether it makes those things easier to do, and I think the same properties that make Perl great for one-liners make it harder for long-lived, large projects.
Agreed that Python still isn't as good at Perl at command-line scripting (which isn't a denigration; Python is good at it, but Perl was born for it). Also agreed that Python's current trajectory is buoyed by data science (compare Ruby, whose ascent via the web went hand-in-hand with Python, but which never took off for other domains and faded as new languages entered the web space). But that's a separate phenomenon, and probably has even less to do with comparisons between Python's and Perl's syntax (for years the data science crowd has been demanding more syntax from Python, e.g. a dedicated operator for matrix multiplication).
CPython doesn't really have a "stream mode" like `perl -pi`, but you could easily make a pretty trivial wrapper to do it if you found yourself wanting to duplicate that functionality. I'd much rather use sed or awk in your specific case and similar, but to each his own.
So Perl was built because Sed/Awk had "whipupitude", but fell short of being a real application language like C which was great and fast to run, but slow to develop in. Perl was the middle ground which took the power of Sed/Awk/Bash and made it faster and more respectable and added a huge module repository. Of course take this with a grain of salt.
> Somewhat surprisingly, I think Perl's syntax is one of the reasons that Python became popular. Perl can do pretty much everything Python can, and it came significantly earlier. Yet people gravitated toward Python.
Surely the ugliness of OO Perl and having to deal with references/dereferences/data structure flattening by default is the biggest reason. Otherwise, why would Ruby have become popular around the same time despite not necessarily being very readable?
e: Also the Perl 6 debacle like the other guy said.
>given code completion in editors as old as emacs.
Good point. Even vi (before vim) had/has the abbr(eviation) command which can be used for things like expanding say bg into begin and so on. Plus, typing time is not the biggest part of programming time, not by a long chalk, though of course improving typing productivity can help some with overall programming productivity. Also, others have said in maybe this thread as well as other places, that Pascal's unambiguous syntax is one reason for the high compilation speed of Pascal compilers - which again aids overall productivity. [Used both Turbo Pascal and C a lot.]
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.
Ultibo - the barebone unikernel OS for Raspberry Pi - is written completelly in Object Pascal... it's source code is >>much<< easier to read than C counterparts (see https://ultibo.org).
Too wonderful. I was shocked when I see common filesystem drivers (including NTFS!), completely written in Pascal. The author must be a programming God.
I've lately been trying out FreePascal for building my indie games (which have in the past been in C, Python, Java, Objective-C, and finally JavaScript), and it's going well enough. There's certainly room for improvement, and the Lazarus IDE is not at all to my taste, but it's likely to be my next-ten-years language.
If you don't rely on the presence of a form designer then you might want to use Visual Studio Code with the OmniPascal plugin (http://www.omnipascal.com) as a replacement for the Lazarus code editor.
Lazarus and/or Free Pascal? Android is looking good, though maybe not really a pleasing experience for those with less experience. It even has multiple approaches. iOS is still dark, no one seems interested in making it work, even Arduino gets its place before iOS.
Delphi? Some big mobile apps are written in it already. WPS Office for Android and/iOS, if you ever heard, was written in Delphi. At least the last time I decompile their APK it confirms a Delphi runtime existence. Disadvantage would be the framework that's not native, thus you may end up in jumbo size APK even for a form + label containing hello world.
Haven't tried it yet, once I get desktop tech demo stable (hopefully this month, barring work & laziness) and can see it run on non-Macs, mobile's the next target.
No idea how I'll test Android, I'm a Mac and iOS guy, and years ago when I tried the Android IDE the emulator was appalling.
How do users of languages like Pascal get by without any/many libraries? Do they need to use the FFI to call out to C functions constantly?
I mean, I certainly buy that $VINTAGE_LANGUAGE could still be great to develop in, but I'm curious the practicalities of working on modern systems without re-inventing every single wheel.
In my experience (talking FreePascal/Lazarus here, as I'm on Linux most of the time), the library situation is not that bad, actually. The standard lib has most of the mundane stuff, and a little github-searching can often find a working version of more specific stuff (like SSH2 which I needed recently).
To the contrary, in some areas (like GUI tooling) it is far far beyond newer alternatives like Go.
Also, I think the higher level of the language than C/C++ etc can make it easier to develop your own solution, should you have to.
We needed a app for branding. That login to a website. So it needed to do a POST request. I struggled with fp and google for 30 min, and dropped to the `RunCommand('curl',['https://ifconfig.co'],s, opt)` clutch with curl.exe(with licence file) bundled into my innosetup file... magic?!
It is hard to get the boss to allow you to write a mvp in non mainstream language.
So I had a quick swing at the libs and wondered about so/dll dependancies compiled against my exe; and just went for a bundled exe, yum and apt curl install script... under a day native win and ubuntu support?!:D I'm sure there is a TODO tag above my command for the junior that is going to hate me because he now needs to code in lazarus... ;)
At work, I maintain an in-house application written in Delphi/ObjectPascal.
In my case I do not need anything beyond what is supplied by the environment. The UI library is part of the environment, so is the database interface, ... basically, that is all the application needs.
Generally speaking, applications that basically are a UI on top of a relational database probably don't need any external libraries. And those are, uh, abundant.
Also, calling libraries written in C/C++ is possible, too.
I don't know about Object Pascal to C++, but calling C libraries is a no-brainier.
There is a bit of a definition wrapping, and then the C library looks like a pascal one, and unlike most interpreted/JIT/GC/etc languages where the programmer or wrapper has to jump through hoops to transform the data structures to match an in memory C structure, pascal just goes ahead and uses the same datastructure. This yields a far more transparent/efficient interface. Even pascal strings degrade to C strings by skipping the size header, and assuring they are null terminated before calling the C libraries.
It depends on what you’re trying to do. In delphi you get a huge class library out of the box, and mostly you don’t need much else. There’s also still much third party stuff around the web from its glory years. The tricky part is interfacing with new external systems, and there it’s usually a matter of calling into a C library, which is easy to do.
I’ve found PHP to be trickier actually, because if there’s no extension to connect to the system you want, you don’t have a real fallback plan except writing your own extension in C.
Curiously enough, C still has native means to call Pascal functions.
At least in the past, the interoperability between languages was taken very seriously, because the industry used to abhor the idea of having to rewrite things just because of the need to use a different language (e.g. PL/I instead of Fortran); the object module format was designed to be language-independent.
As computers became faster much of software development switched to interpreted and VM-based languages, and language interoperability became a problem.
I haven't actually tried that, but my guess (even without checking that link) is that you are right, because:
1) C and Pascal are not too different as languages go (in some respects, both being sort of Algol-family languages), and:
2) I remember from earlier Windows API/SDK days that many Windows APIs had signatures/prototypes that went something like "long far pascal", and remember reading in computer magazines and source code listings about Pascal vs. C calling conventions (it may have been something like the order in which function parameters are pushed onto the stack before the call is executed, who cleans up the stack - caller or callee, etc.).
It's not a full answer to your question but I've sometimes found creative solutions to avoid FFI or ports. A good example I saw was someone who wanted to draw some 3D things generated in an obscure language without GL bindings, so they made a small external program in another language that took textual GL commands on stdin.
THere is a crippled version of Delphi that is free but limit is only targeting 32 Bit Windows. That may be enough for some but not if you wanted to do cross platform (which is what Emberacardo is providing now).
I've never done anything serious in Forth, but I was first exposed to it in the late 80s, and keep coming back to it.
Over the past couple of years I've written, and thrown away, several implementations of Forth in C, C++, and Perl. I've even had it running, embedded, on ESP8266 devices.
It continues to be something I enjoy toying with, but equally something I can't find a perfect use for.
Forth is one of the first things I install on a new machine, I love tinkering with it and it seems to me to be the "right" way to do computing... but I have yet to write a useful program in it...
"You can also define your own types", "classes can also inherit other classes", "Pascal is modular"...
Not to say these are not valid reasons, or expectations one may have from a language, but - what exactly is Pascal being compared to? I mean, it's 2017.
C has no classes, and everything's in one global namespace.
Scheme & LISP have no built-in classes, and one can argue that CLOS isn't what we normally describe as OOP. Both normally have a global namespace.
Inheritance in JavaScript is possible but very hard to implement correctly before ES6. Node has namespaces (sort of) but client-side JavaScript generally doesn't.
PHP in theory has namespaces, but the standard libraries are just dumped in global.
Nonsense. Lisp has a plethora of standard classes: T, NUMBER, PATHNAME, SYMBOL, SIMPLE-ARRAY, BASE-STRING &c. &c. &c. In fact, I just ran this on a pristine SBCL (no user or :
(let ((ch (make-hash-table :test 'eq)))
(labels ((pc (class)
(loop for subclass in (sb-mop:class-direct-subclasses class)
unless (gethash subclass ch)
do (progn
(setf (gethash subclass ch) t)
(pc subclass)))))
(pc (find-class t)))
(length (loop for class being each hash-key of ch collect class)))
→ 659
Yes, a basic running SBCL has six hundred and fifty-nine classes built into it. It all works remarkably well.
> one can argue that CLOS isn't what we normally describe as OOP
Probably not, but it's better.
> Both normally have a global namespace.
CLOS classes are themselves instances, identified by a symbol which lives in a package — i.e., within a namespace. E.g:
> PHP in theory has namespaces, but the standard libraries are just dumped in global.
Modern PHP development almost exclusively uses Composer libraries rather than the standard libraries, which overwhelmingly use namespaces in Vendor\Project format.
There's going to be a push to clean up the standard library in the coming years. The plan is to introduce a namespaced alternative to the standard library in the global namespace which also cleans up a lot of nits (e.g. phpsadness.com posts). Maybe in PHP 8? Then when the ecosystem catches up, we can discuss deprecating/removing the "just dumped in global" way of doing things in PHP 9.
Source: I'm very likely going to be the main person driving this push.
I've posted this before but I've really been pleasantly surprised by how good working in PHP7 is. It's not my favorite but I certainly like it more than Ruby.
> Scheme & LISP have no built-in classes, and one can argue that CLOS
CLOS is built-in.
> CLOS isn't what we normally describe as OOP
There is no 'normal' description of OOP. Smalltalk, C++, Java, Self, Javascript, ... are all object-oriented programming languages and are widely different. If you look at the OOP literature you will find dozens of definitions of OOP.
CLOS has classes, instances, inheritance, dispatch, and other features of OOP.
> Both normally have a global namespace.
Namespaces for symbols in Common Lisp are called 'packages'.
I'm not saying these are features provided by every modern programming language - obviously eg. there are FP languages that are not object-oriented, as you pointed out.
Still, the selection of languages that do is so vast that such reasons hardly answer the question "why Pascal, of all the options".
There are only a few "popular" languages that have both, many that don't; those are not mandatory features for everyone.
I care about performance (ruling out any GC language), multi-platform native binaries, language readability, dev community, and a bundle of other factors. Pascal turns out to hit most of my needs and not annoy me too much.
Of the thousands of more obscure languages, I'm sure there's one that'd be perfect, except I'd have a worse time with libraries.
> Not to say these are not valid reasons, or expectations one may have from a language, but - what exactly is Pascal being compared to? I mean, it's 2017.
I have been searching for it for 15 min now, but last month or so on hn there was a article comparing programming languages and compilers. fpc performance was comparable to c.
Also a mvp production exe will be 2.5 MB, no stdlib/.net/qt needed.
>Also a mvp production exe will be 2.5 MB, no stdlib/.net/qt needed.
And a hello world Free Pascal EXE can be as small as 57KB:
$ dir fpc_hello.exe
07/26/2016 09:43 PM 57,402 fpc_hello.exe
Source and output:
$ type fpc_hello.pas
program hello_1;
{ uses ; }
var i: integer;
BEGIN
for i := 1 to 10 do
begin
writeln(i:4, ' Hello from Free Pascal');
end;
END.
$ fpc_hello
1 Hello from Free Pascal
2 Hello from Free Pascal
3 Hello from Free Pascal
4 Hello from Free Pascal
5 Hello from Free Pascal
6 Hello from Free Pascal
7 Hello from Free Pascal
8 Hello from Free Pascal
9 Hello from Free Pascal
10 Hello from Free Pascal
I also checked the size of similar programs in C and D. C was about 22KB, IIRC. D was something more, don't exactly remember, but not a lot more, probably.
Lazarus on ubuntu and windows is usable, i'm still struggling with macOS and there is legends and lore of ios/android support. It even seems to support qt, but I have not went there yet.
Something else to mention about lazarus is you can hot compile the ide too add in components, fix issues; While using lazarus. It takes a couple of minutes to recompile and there a fail safe cli method to restore. But rather amazing if you wonder how long it takes to compile visual studio professional or qt.
C has its root buried deep in programming world. A lot of things were written in C, big things, that people don't want to touch but they have to use. It's no longer as popular as, say 5 years ago. Along with Java, the popularity is being decentralized as communities of other languages get stronger (including Pascal).
My dad still runs his business on a software I wrote in 1998 in Delphi. I haven't touched it since then but it is the only code I have that still works 19 years later.
I have a turbo pascal game from the 80s that still sort-of-works on the command box of windows 10. Unfortunately it starts, does a demo loop in which all the pacmen get eaten then exits, all within about a second. I thought it was broke for many years until I found a way of slowing dosbox right down to look for an error message and did not find one :-) Shame I havent got the source code. I also wrote an 8051 assembler and compiler again executable (com) file only but I havent looked at this for a while as its still on a 5.25" floppy... Ahhh memories!
I have a large codebase in Delphi 5 (1999), still being maintained and developed. The applications produced work on all current Windows versions w/o problems. Delphi itself works on Windows 10 albeit requires some tricks to install properly.
The Nim language [0] feels very inspired by Pascal while looking like Python. If you're interested in fast, compiled & typed languages, I suggest you also take a look at it. I personally love its readability.
I'm curious what's similar to pascal about it? It's garbage collected, it compiles to C or JavaScript, and its syntax is inspired by Python, so I just wonder what is left.
I used Delphi (1) to Delphi 5 in the 90's and used Delphi at a company for production software from 1998-2001. I loved it. It was (?) a great language and was always a pleasure to work in. I'm not a language fundamentalist (I use whatever it takes to get the job done and whatever my employer prefers), but I can say that at least 16 years ago it was a joy to work in.
Some fun I had with free pascal in college was that you can $DEFINE almost anything to almost anything else:
{$DEFINE (:=ab}
{$DEFINE ):=ba}
...etc...
Code becomes pretty ridiculous:
WriteLn ab ab a + b ba * c ba
If you define WriteLn, +, and * as other things too you can get horrific looking code. All keywords like program, if, then, and end can be redefined. I wrote a script that would take a regular source file and output a functionally identical file which looked like:
{$DEFINE program:=a}
... many more defines ...
{$DEFINE [:=zd}
{$DEFINE ]:=ze}
a b c d e f g h (* ... the entire program on one obfuscated line *)
Yeah I've written compilers for Swift, C#, Java, JavaScript and Pascal and agree Pascal is the cleanest and nicest language, both on the parsing side and writing in.
Pascal language has a LL(1) grammar, typical for Wirth and other 1980s work.
LL(1) grammars are of great practical interest, as parsers for these grammars are easy to construct, and many computer languages are designed to be LL(1) for this reason.
I believe the toolchain offers the best cross-platform GUI option right now. In the best case this can serve as a wake-up call to other languages: get your GUI house in order!
While the author mentions castle-engine at the end I also want to mention glscene[0]. Don't think it is actively maintained like castle. But boy was it amazing to read through the code to learn OOP principles and GL.
Apollo Computer used Pascal as the systems programming language for its operating systems beginning in 1980. Variants of Pascal have also frequently been used for everything from research projects to PC games and embedded systems.
1) The popularity of UNIX where C was the standard language
2) The fact that, much like BASIC, most implementations of the language didn't follow the standard. In practice, Turbo Pascal was more of a standard than the official one.
A while back, I ended up following a link on HN and reading a bunch of old computer magazines. I came across an article by Peter Norton (in PC Magazine) from around 1986 or 87. In it, he discussed why C was rapidly displacing Pascal among DOS programmers.
Not that Unix didn't have an effect, but as DOS and then windows exploded in popularity in the 80s, C displacing Pascal there played a big role in Pascal's overall decline vs C.
edit: I think this is the article I'm thinking of:
In those days without Internet and expensive dial-up access to BBS limited to 5 simultaneous users, it depended very much where in the globe we are talking about.
On my area in Portugal, using C was mostly for university projects.
For anything else we were using Turbo Pascal and Assembly, with Clipper for business applications.
Actually many MS-DOS systems programming books had code listings in C, Pascal and Assembly.
There certainly were/are differences across platforms in C (hence config scripts), but for the most part those aren't issues with the language itself but with the supplied libraries.
Even using GCC it could be a problem. Aix would want a different type for this function call, Solaris for that function call, Linux for this other function call. We had #ifdefs around a lot of variable declarations.
As others mentioned, UNIX was a big deal. But later the final nail to the coffin was that MS was backing C++, so that didn't leave any major platforms where Pascal was "native". Sadly Oberon never managed to escape academia.
Back in those days anything that wasn't the standard compilers sold by the OS vendor, meant spent a few extra thousands, so most people didn't.
On the PC world, Borland management trying to play with big boys, destroyed the indie culture around Turbo Pascal/Delphi and many moved into Java and .NET.
It was ugly and reminded us of BASIC. That's my main reason, most 80's/early 90's folks went from BASIC to C, or BASIC to pascal. If all you had was pascal, you fell in love and never understood why any sane person would use C. C was seducing, it was faster than basic, didn't look like basic and we could fool ourselves chasing pointers, doing stupid things with it's macro system. Mental gymnasium to distract us from real work. :D
- Internet rapidly became increasingly ubiquitous. And it was largely aligned with the Unix philosophy of plaintext formats.
- Computers became fast enough and powerful enough to make interpreted languages (and VM-based languages) usable.
- Open source took off.
- This produced explosion of new, free scripting languages that were really good at working with strings, dynamic data structures, and plaintext formats.
- Visual Studio and Delphi both still cost thousands of dollars. Not something you could download and evaluate or try out. Not something you'd decide to learn on a whim. And not something with a big community of open-source developers sharing things for free. Delphi made the business decision to price out the small shops and individuals that were its customers in hopes of going after an enterprise market.
- Except in some areas (games, embedded, etc.) the industry shifted toward making things with open-source scripting languages or java for the business stuff. Those who remained in desktop and didn't switch to java switched to visual studio.
- The creator of Delphi left and went to Microsoft and created C# to compete with java.
The static languages were also somewhat slow to adapt to plaintext data formats. They typically used proprietary binary formats and those were easy to work with (they could basically directly load and dump to/from RAM/disk). But serializing and unserializing and marshaling and unmarshaling to/from plaintext formats was a pain. Eventually they got generics and templates and macros and things to make it less painful, but it's still nowhere near as simple as in the typical interpreted dynamic language. (I recently modified an old 80s-90s era C program to output JSON and did some work on getting a Pascal program to read it.)
Things are different today I hope, but back in the 90's when I was teaching CS, Pascal was not very portable or standardized. Even some basic operations like opening a file were not standardized. Turbo Pascal and AIX's Pascal (the two variants I dealt with back then) did this operation differently.
Price of Delphi. You could have had Visual Studio for $1000, but Delphi for $10k. That single-handedly killed Pascal. Lazarus/FPC was a response to that pricing insanity.
Pascal was great when you were coloring within the lines, but C was more flexible. I don't think I was ever able to do image processing in Pascal, and I shudder to think what it would take to do a device driver.
Pascal was my primary language from about 1980 to 1990, then I transitioned to C and from there to C++. I missed the whole Delphi train.
I was not programming in Pascal in the 80s, I started with BASIC around 1990 (in grade school). But I did use Pascal some in college (early 00s). I'm curious why you say you couldn't do image processing in Pascal, because that was an exercise we had in college and it wasn't difficult at all (though at the moment I could not recreate what I did, it's been too long since I've looked at Pascal). Was this a difficulty with early Pascal?
If Java and .NET produced executables like C and C++, there would be less need for them.
Instead, one is forced to deliver the VM with the application or buy a third party AOT compiler like Excelsior JET, while depending on another language for implementation.
This made everyone that cared about writing native executables focus on C and C++, with the respective increase in unsafe code.
This is finally changing thanks to D, Go, Swift, Rust, but slowly.
So we have .NET Native on UWP, Xamarin on iOS and Android and IL2CPP on Unity.
Java now started a long road that will take several years until Project Metropolis will finally deliver some kind of results.
> This is finally changing thanks to D, Go, Swift, Rust, but slowly.
This whole thread has me imagining what it would be like if all the energy that went into Go/D/etc had gone into Free Pascal instead.
Imagine if Free Pascal had a swanky website, and an army of people blogging about this hip, powerful language, all the kids are getting on board, I heard Netflix are re-writing their routing layer in Object Pascal, have you seen the benchmarks for this awesome new non-blocking Pascal web server...
How are the available packages? Is there a package management system ala `bundler` or `npm`?
This to me is a critical piece of adopting a language, especially a non-mainstream one. Pascal has the benefit of being older but access to clean modern libraries is critical.
Pascal looks like an excellent option for building cross-platform desktop apps, given the excellent GUI libraries. But I doubt I'm sold enough on it for any web stuff, given the great other options. I'd likely use OCaml if I was going to gamble on a non-mainstream language.
All of the arguments given for Object Pascal in this article could apply to other languages.
A better question might be "why use Object Pascal over Language X"?
I could see a niche in cross-platform desktop development, assuming you didn't want to go the Electron route (and there's valid reasons for doing so). I've worked in Qt quite a bit in my desktop days and Qt/C++ is quite complex.
Object Pascal still has manual memory management though, IIRC, which is a large portion of that complexity.
Yeah, I don't have the sense from reading this that I have any idea why I'd prefer Pascal over, say, Java, or C#, unless I liked begin and end blocks more than braces and felt really strongly about it.
I loved Turbo Pascal back in the day, thought it was better than C when I was working with DOS. I switched to C when I started working on Unix workstations.
I just what to thank the author of the article. I am from the camp of those who had this misunderstanding of thinking that Pascal is only a "toy language" to be studied at school or university and the articles gave clear proofs it's not. I'm not going to switch to Pascal now or explore the question more deeply; it was just an important thing for me to learn.
I wrote the first version of Outlook Profiler in Delphi 6, then in Delphi 7. Wonderful introductory language for making products (although Perl was my first exposure). The VCL GUI library and IDE work so well together that things today are second rate. Strange that we've not improved this basic need.
Today, I write most things in C++ (or C# if I can).
I always felt it’s really strange that making a quick and dirty GUI application is still easier with Visual Basic 4.0 (circa 1995) than with most any modern tool.
I've tried picking up Free Pascal and, for me, the documentation is lacking. I come from C# where Microsoft has amazing documentation and small examples on how to use just about every single class in the .NET framework. I guess I'm just spoiled with the documentation I have had and need to get used to it.
Wow, not sure how I missed that. I was just looking at their Wiki and then there was a page where they had the language spec. This changes a lot. Thanks for bringing this to my attention.
Borland/Delphi set the standard for documentation that MS then copied to .NET (no wonder Delphi and C# creator is the same person). FPC likely assumes you have access to Delphi help files.
For absolute beginners, I still think Pascal, or Turbo Pascal is best to start. It has a syntax that doesn't scare people away, and very readable. Deploying is also 1 trillion times easier then what ever we have today, ( C , Python , Ruby , Node.js ... )
I would have picked Ruby if it could compiled into a single executable file, and if the Dev environment actually work on Windows.
P.S: It does work on Windows, but not as simple and easy as it should be. Compared to every other alternative on the market.
Press F9 and you get a self contained exe which was not dependent on any libraries in about a second.. I think that was what the poster was getting at.
I was enrolled at a university that had you progress like this:
1. Imperative programming with Pascal
2. Object-oriented programming with Java
3. Functional and logic programming with Prolog and Scheme
4. Advanced functional programming with ML
All the software engineering & project management courses basically assumed Java-brand OOP and related practices, though.
Before that I was enrolled at a different university that did three things at the same time in no obvious order:
A. HTML/CSS/JavaScript and PHP for web development (yes, like in the 2000 era)
B. Java for linguistics programming and software engineering (but the professor wouldn't shut up about how much he likes Oberon-2)
C. C++ for interactive graphics programming (and maybe other things to)
Basically all the advanced "computer sciencey" stuff was in C++, all the more "software engineeringy" stuff was in Java and everybody pretended web development wasn't really a thing.
Pascal is definitely a very good language for teaching the basic of procedural/imperative programming. It has several good properties : it teaches you structured data (which helps to understand formalization), is strongly typed (which helps to reduce the uncertainty about the behavior of a program which in turn helps student to understand what they do precisely); you don't have to face pointers (which in my own experience are tough to understand); etc.
Pascal and C are very close to each other as they implement the same programming paradigms. Haven't tried Object Pascal but I assume it extends Pascal with OOP and some other stuff... while still being the same imperative/structured/object oriented combination we all know.
If you are coming from C, it should be like moving from Python to Ruby, or Java to C# or viceversa... same paradigms for the most part.
Anyone here used PascalScript[0], specifically with compiled Pascal itself? I am planning an application that is compiled and delivered with PascalScript to allow the end user to extend and customise the application without access to the source code. Preferrably using FreePascal.
Anyone who likes Pascal should check out Nim. Inspired by Pascal, with some Python-like syntax (and significant whitespace), as well as some really cool features from other languages. Also compiles to blazing fast binaries via C or C++ (JavaScript too but not sure about the performance there).
Most of the points are all well and good (albeit underwhelming)
but
>This is maybe the fact, that most developers are annoyed about: the absence of braces and the very verbose syntax of the language. As an example, instead of opening and closing braces, Pascal uses the begin and end keywords for blocks. The if keyword is complemented by the word then. As you can see, the whole syntax is readable like plain English. If you start to cry now, you should consider one important question by yourself: What is more important? The ability to have a short syntax to write code fast or the possibility to read and understand code that was written by other developers or even by you a year ago? I’m in favour of the second fact and I really enjoy that verboseness.
You don't make code more readable by adding more noise.
BEGIN and END is just plain noise
BEGIN And how exactly does this make code "readable like plain English?" END
English is great but for all the "noise". Why is "the" a three letter word and not something more concise like "le" or "a"? Why is it "and" and not a single-letter "y" like any sensible language?
You get used to the syntax, and after a while it becomes invisible.
Makes sense since Anders H. architected c#, turbo pascal, and Delphi. As soon as he left Borland, Delphi began to atrophy. Too bad because it was a ground breaking product when it came out.
C# borrowed heavily from Delphi - i.e. the Object Pascal bits. Explicit virtual/override, properties, that sort of stuff. The class library, especially WinForms, also borrowed heavily from VCL.
But I don't think there are any notable borrowings from core Pascal.
Something I wonder how will one get object pascal work? The worst part is I would like to be picky and only to fpc/lazarus dev, no delphi. Otherwise I need to stick to selling my python/flask, html5 fizz buzz.
No need to speculate[0]. The name "object pascal" was firstly used by apple for their dialect of pascal. Then Borland came and evolved Turbo Pascal into Object Pascal(and brand it Delphi) and then fpc came and branded them a open source object pascal implementation.
As for Pascal vs Object Pascal, Procedural vs OOP, Think C vs C++(not that I'm saying c++ is better).
"Borland used the name Object Pascal for the programming language in the first versions of Delphi, but later renamed it to the Delphi programming language. However, compilers that claim to be compatible with Object Pascal are often trying to be compatible with Delphi source code.[citation needed] Because Delphi is trademarked, compatible compilers continued using the name Object Pascal"
You're still right that Object Pascal can encompass more than just Delphi.
My first language in high school was actually Pascal (as in - Delphi) but now I love C, C++, Lua and Python and barely can write Pascal at all, especially since it's so separate from the C inspired syntaxes and semantics. For job reasons I'll also probably learn something 'proper', mainstream, industrial, etc., but not relearn Pascal. But for trolling, having fun or some private GUI work (especially that, thanks to Lazarus) it's just great.
When I got to university they (the university, not the high school, no idea about them) dropped it from the curriculum so my Pascal skill makes me quite unique in that sense.
I only used it once or so during university to troll one doctor leading a class, an old homework grading system still had Pascal available in it in addition to C and C++ so I submitted a Pascal program. In a twist of irony the next class after that assignment was led by another person, a really smart professor who usually teaches in Warsaw who also happened to be quite a good sport about jokes and such, who quickly sarcastically remarked to my Pascal program: we've got a connaisseur in here.
And this whole joke was actually in response to story the person usually leading that class told, about how once during a competitive coding competition (allowing C, C++ and Pascal) where everyone was using C or C++ he was first to submit a correct program and it was in Pascal to which the live judges commented that Pascal is making a grand return, since even back then it was on its way out.
Recently I picked it up again when I needed to do something quite graphical for statistics class on a short notice that would be dealing with graphs and I didn't want to fight Qt, GTK+, HTML5 or whatever into submission and having recently discovered Lazarus I knew it can do it. I quickly whipped up the program, the graphing components were great with API and all but were poorly documented (or not at all). Sadly there were no funny comments from the doctor on that one.
Part of using Pascal for anything at all or even knowing it is actually the funny comments and reactions of others. Some people seem to think Pascal is properly dead, as in - no longer usable, no longer worked on, no longer coded in, at all. Like COBOL or something but with no 'old bank software' and such to save it. When looking for a job I actually even forgot to put Pascal on my CV as being one of my 'very weak' skills but I imagine it didn't hurt my chances... I even share the first name with Blaise Pascal (the French mathematician the language was named for) so that makes my use of Pascal even more appropriate and allows for even more jokes.
After that I also did few UVA[0] tasks but sadly Pascal seems to be broken for many tasks so I gave up (I get an error saying 'mv failed: program.pas and program.pas are the same file').
Later, to not waste and forget what I relearned for the graph program homework and since GUI in Lazarus is so easy to do, I also (shameless plug) wrote a notes program[1] for myself and it was a breeze thanks to Lazarus and the LCL components. Now I use that program daily for my various notes, todos, etc.
Hopefully, it has changed but, when I was learning Pascal many years ago, an entire program had to be contained within a single file. No separate compilation files and no linker. For all but toy programs, this made for some very long files which, given the state of editors then, made maintenance a real problem.
UCSD Pascal had separate compilation units (late 1970s). A lot of people from my generation got started with Turbo Pascal and it had units based on UCSD Pascal starting in TP 4.
Put another way, the thought patterns programmers fall into when using it seem to result in code which is easier to understand than most other languages which seem to encourage "perlism" (creating a single unreadable line), "forthism" (creating a billion two line words that combine to solve all the problems in one word), or a few other things which become completely unmaintainable when the project grows beyond what can be written by a over-energetic student in a semester at school.