Why I use Object Pascal | Hacker News Reader

Why I use Object Pascal

dubst3pp4.github.io

268 pointssamuell233 comments

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.

Regarding those essays, I consider myself lucky to have learned and used Pascal and Basic compilers before learning C.

Then I just had fun showing to disbelivers how to do in TP stuff that apparently only C was capable of.

>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.]

> even though the strongest argument frequently was that its harder to type "begin/end" than "{/}". Which is a pretty lame thing

and it's not too different from Ruby, to boot.

Ruby supports braces, they just aren't used as often.

I prefer begin/end so this is a feature to me.

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).

I have long thought Perl can do anything Python can, and then some. I still use Perl one-liners to find/change strings in code bases:

perl -pi -e 's/somestring/newstring/g' $(ag -l --python Foo)

Does Python have an equivalent?

I think the fabulous Python libraries for data science have really propelled the language to the top of the list, in terms of users.

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).

> 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.

You could have just used sed for that?

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.

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.

> I don't think syntax is the main culprit here,

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".

The "killer app" for Python was NumPy. Ruby and Perl have nothing even close.

> 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.

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.

Most of that criticism was already wrong when compared against Turbo Pascal 6.0 on MS-DOS (the 7.0 major improvement was DOS extender support).

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.

It's 21 years newer than the critical article he mentioned..

But that article was not 21 years newer than the first version of TP that was released in 1983.

The first version of Turbo Pascal didn't have object system or modules.

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.

Essential quoting of the thread:

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.

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.

It's not like Pascal's memory management and pointer situation was that much better.

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.

Of course in C++ you can just use a vector. Object Pascal is certainly closer to C++ than C.

The main advantage of Pascal is super fast compilation, but C++ modules should close that gap once they make it into the standard.

Which is why C++ became my next favourite language after Pascal, and I joined the C++ side of the C++ vs C USENET "arguments".

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 :-)

>Pascal knows the size of its types

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.

https://www.tutorialspoint.com/pascal/pascal_pointers.htm

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.

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.

You must be 50... and you're still on HN! Are you still an engineer? If so, what stack are you using now?

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).

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 clearly misjudged the time of Pascal's popularity and have never heard of RHEL but thanks for the response!

What is Slashdot's strength from your POV?

Slashdot is kind of like Mel Gibson. It was cool when it first came out and now it's still around.

> have never heard of RHEL

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).

RHEL is RedHat Enterprise Linux. RHEL 5.5 came out in 2010, to give you an idea of the speed of the IT department in some places.

Slashdot picks up stories that Ars and HN miss sometimes. It just adds some breadth to my tech news sources.

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.

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.

Which one did you think would be best for a first year language?

I was taught Pascal first, then C++. Pascal really helped with learning the basics. I think jumping right into C++ or Java would have been confusing.

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.

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 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.

Coming from Microsoft's MSX-Basic, Turbo Pascal 3 was my first "grown up's language", also on 8-bit MSX computer. And I'm not 50 yet...

52 here. Did some Pascal at university on a VAX.

Currently working in python in fintech environment.

Above 40+, mostly Java and .NET languages, with some ocasional C++ thrown in when low level stuff is called for.

JavaScript when doing web development, TrasactSQL, PL/SQL and pgSQL for database manipulation.

Plus lots of other languages and tech, keeping an eye on what might be interesting to focus or advocate to customers.

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.

Over 40, sometimes engineer still. First job was Delphi 2, but moved quickly to Delphi 3.

My stack now is... diverse. Python, Spark, Java, React, Node, PyTorch, Scikit and occasionally R.

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.

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.

Oh, I see. I can understand why that would be irritating.

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).

This is strange and wonderful. Thanks for sharing. Somehow I wasn't aware of this, and I follow Raspberry Pi stuff.

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.

https://mdhughes.tech/2017/09/02/pascal/

and a couple of followup posts

https://mdhughes.tech/category/pascal/

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.

I was a lot younger and got it working on delphi7 but look at glscene[0]. It really changed how I view OOP and GL, amazing framework for its time...

[0]: http://wiki.lazarus.freepascal.org/GLScene

Also love GLScene, used it for building a 3D STL activex viewer control and that was not as hard as expected.

Any early feedback on mobile?

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.

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.

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.

Delphi does have some choices in that space. https://github.com/Fr0sT-Brutal/awesome-delphi/blob/master/R...

It is easy to create bindings to the C-libraries you need, see http://wiki.freepascal.org/Creating_bindings_for_C_libraries.

But FreePascal has many native libraries for all kinds of stuff...

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.).

https://en.wikipedia.org/wiki/X86_calling_conventions

e.g. see the cdecl vs pascal conventions.

Maybe this answers your question:

> But beside this historical excursion, what are the reasons that I use Free Pascal in my personal projects?

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.

That's cool, this thread has definitely piqued my interest in Pascal!

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?!

FYI Free Pascal (and by extension, Lazarus) comes with fcl-web which contains, among others, an HTTP client.

See:

http://wiki.lazarus.freepascal.org/fphttpclient

Thanks this is the kind of info I needed. Only had a day in laz land and time was running out for my product. So had to cut corners. #TODO

libcurl (with examples) is bundled in the FreePascal distribution, as well as simpler alternatives like fphttp, fphttpclient, fphttpwebclient, etc.

Thanks will look into it.

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... ;)

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.

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.

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.

In Delphi is quite easy if you make use of C++ Builder, since they share parts of the tooling.

With another C++ compiler on Windows, COM is a better approach.

Anywhere else than the usual plain C like APIs.

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.

This is visible in the surviving IBM and Unisys mainframes.

Turbo Pascal and Forth were my first languages past Assembly on C64. They were so much better then Basic and Assembly for a young teenagers.

Delphi is now $1,200 to $4,400 a user!!! WOW more then the $75 in 1983

https://www.embarcadero.com/app-development-tools-store/delp...

Currently I'm learning Forth and I really like that language! It's a brain twist and that's reason enough to have a look at :-)

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.

Give it a try in Racket. Racket's macros is a dream to create another language in.

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...

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).

Yep, that's why I always recommend Lazarus instead of cracking Delphi illegally.

"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.

Well, C is still top-5 in all the programming language rankings I've ever seen, so... :)

OK, but "it's not C" doesn't really make Pascal stand out ;)

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).

neither javascript nor C++ are modular in 2017

...for some value of "modular".

...for some value of "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.

... and one can argue that CLOS isn't what we normally describe as OOP.

Well, yes, though I consider it far superior to most other object systems out there.

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.

> I care about performance (ruling out any GC language)

[Citation needed]

> 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.

Namespaces by 2020? That'd be nice. The \ syntax still makes my eyes bleed a bit, when most others use . or :

You might want to go see a doctor and get that checked out then.

Just because "most others use . or :" doesn't mean it's the only correct syntax in the realm of possibility.

I think there's some reason they landed on that one, but seriously, if that's your biggest complaint about the language...

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.

The obvious languages to compare to are Java and C#, though.

> Scheme & LISP have no built-in classes

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:

    (defclass foo () ())
    → #<STANDARD-CLASS COMMON-LISP-USER::FOO>
    (defclass swank::foo () ())
    → #<STANDARD-CLASS SWANK::FOO>
    (make-instance 'foo)
    → #<FOO {1003ED8AA3}>
    (make-instance 'swank::foo)
    → #<SWANK::FOO {1003EDEC03}>

Those are two different classes, both name FOO, but their names live in different packages.

C++ has namespaces. Yikes, I looked C namespaces. People are suggesting that you can put things in a struct. https://stackoverflow.com/questions/4396140/why-doesnt-ansi-...

> 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'.

> what we normally describe as OOP

OOP just means "functions are associated with data in a syntaxic construct of the language". Namespaces are irrelevant.

> 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.

> 2.5 MB, no stdlib/.net/qt needed.

This is a pro of Pascal then :)

I was also looking for the pros of Pascal in contrast to what we've come to expect of languages while skimming the article.

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.

http://wiki.freepascal.org/IDE_Window:_Configure_Build_Lazar...

That's some interesting pros! Thanks man.

>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.

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.

Does it runs on modern Windows or is it running on a VM?

It could very well work without VM. Current Windows is binary compatible with old programs.

There are a few reasons that programs stop working and most of them are related to hardcoded directories that got perm. restrictions over the years.

Window 7/8 at the moment I think.

I sometimes use ecco pro on windows 10, which was discontinued in 1997. The 32-bit version still works well enough to remain usable.

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.

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!

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.

[0]: https://nim-lang.org/

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.

From https://nim-lang.org/features.html:

> Oberon-inspired visibility markers

> Pascal-inspired type sections for leaner definitions

While Oberon isn't Pascal, they're both Wirth languages that share many commonalities.

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 *)

TCL is arguably more extreme in this matter.

Wow, using pascal for 30 years and diddnt know this..

I am actually thankful its not that well known. Pascal is still readable where as #defines in C libraries give me terrible headaches decoding.

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 always hand write them but yeah. LL(1) is always nice

Is this why Ada's syntax was extended from Pascal?

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!

Everyone is (sadly) switching to Electron for this purpose.

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.

[0]: http://wiki.lazarus.freepascal.org/GLScene

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.

https://en.wikipedia.org/wiki/Pascal_(programming_language)

Folks interested in Object Pascal might also be interested in http://www.elementscompiler.com/elements/oxygene/ (no affiliation, but as an observer it seems relevant and interesting).

I am obviously biased, thanks for mentioning it :)

What caused pascal to lose out to C? Seems like it was a good language that had developer uptake.

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.

Wasn't the latter part just as true for early C?

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.

Oh the joys of writing portable code across Aix, HP-UX, Solaris using their own compilers, using a mix of K&R and ANSI C.

Many computers just had something like Small-C available.

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.

Fortunately, we were at least all ANSI.

It was more than just the popularity of Unix.

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:

https://books.google.ca/books?id=NZrPkWywRXgC&pg=PA75&lpg=PA...

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.

A BBS with 5 simultaneous users? Sounds amazing. Most of the BBSes here in the Toronto area only had a single phone line. :)

Yep, at least they had 5 different numbers, but given the price of regional phone calls, I only used it a couple of times during a Summer job.

UNIX and C.

Think of JavaScript and the browser.

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

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.

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?

Given that I did graphics programming with Turbo Pascal on MS-DOS, I wonder what was missing.

Anything more heavy required anyway Assembly, regardless of the high level language being used, C was no different here.

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.

Ironically gcc only got a major development bump when Sun became the first UNIX vendor to sell the compilers, with others following up.

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.

A few big changes happened in the 90s.

- 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.)

I loved Turbo Pascal and Delphi, which is why I having Java and .NET compile into bytecode always felt a bit of deception.

What makes bytecode a deception though?

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...

I did enjoy Pascal a lot, but right now it lost the PR battle.

Its spirit leaves on in languages like Rust, Swift, Kotlin and similar.

It is easier to drive adoption to those languages, than try to convince younger devs to use Pascal, even with a swanky site.

I like your idea, though.

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.

This is a pretty critical piece for me as well. I've done some googling and I can't find anything definitive.

Lazarus has a concept of packages for years. There is a newly created package manager to handle updates and dependencies as well: http://wiki.freepascal.org/Online_Package_Manager

But I don’t think that it is comparable to gem/npm or whatever yet...

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.

Thank you, this really encourages me after all that discussion! :-)

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'd like to see what you think of https://anvil.works

It's deliberately built in the Delphi/Visual Basic tradition, and trying to carry those virtues onto the modern web.

interesting, thanks for the tip!

VB4 was also able to produce both 16 bit and 32 bit binaries. That was a big help for the Windows 3.11 -> Windows 95 transition.

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.

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.

Did you have a look at https://www.freepascal.org/docs.var and especially at the RTL https://www.freepascal.org/docs-html/current/rtl/index.html and FCL https://www.freepascal.org/docs-html/current/fcl/index.html documentation? I think the Free Pascal team has done a good job documenting nearly everything!

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.

The old Borland manuals are on bitkeepers.

They are quite good.

The default setup for the industrial control systems I've had to work on is Windows2000 with Delphi applications.

There are a shocking number of these systems still in use today.

I've come to have a grudging admiration for these clunky old things and a special respect for pascal in its many forms.

In my university (in Paris) we used to learn programming that way for the licence degree

1st year -> pascal only

2nd year -> c only

3d year -> java only

That was a very nice learning curve for the core course of programming.

This really funny or strange.

This is exactly how IT classes went in my high school.

Uni was really scattered though: Java, C++, C, Prolog, Python.

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.

But when you need them, pointers are there

Ah maybe I'm a bit orthodox here :-) But you're right. At least in Turbo Pascal, there were pointers and super nice in line assembly language.

I learned pointers in my first semester of CS with ^Pascal, and glad I did because the syntax was more readable.

yeah in Spain it was pretty much the same (almost 20 years ago), touching others just a bit (haskel, prolog, etc.)

A friend taught me QBasic and then another friend taught me Turbo Pascal.

Later, in high school, I learned Delphi and we did Java at Monash University.

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.

At my university, we skipped Pascal and went straight to Modula 2. This was in the late 80's - early 90's.

> Deploying is also 1 trillion times easier then what ever we have today, ( C , Python , Ruby , Node.js ... )

What makes it easier?

Distributing an executable from C seems easy. And using package managers from others also seems easy.

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.

Absolute beginners don’t deploy though, they write lessons down and then hit run. “Scripting” langs work great for this.

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 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.

[0]http://www.remobjects.com/ps.aspx

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.

I know C# borrowed heavily from Pascal. (So much that a lot of its improvements over Java were overlooked.)

What's the advantage of using Pascal over C# or Java? Is it that Pascal outputs true compiled programs instead of requiring a VM?

Yes, it compiles native code, typically in a standalone .exe file, avoiding the framework dependency hell.

Another advantadge is that it compiles very fast (several orders of magnitude faster than C# (or C++)), so it's convenient.

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.

Weird anyone still uses this, I first saw Object Pascal on a Apple Lisa in 1983.

FWIW Apple's Object Pascal and modern Object Pascal have little common.

Although i think Free Pascal does have a Mac Pascal mode so that it can understand Apple's Object Pascal dialect.

From what I've read Object Pascal is just another name for Delphi but without the trademark hassle.

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).

[0]: https://en.wikipedia.org/wiki/Object_Pascal

From the wikipedia article:

"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.

[0] http://uva.onlinejudge.org/

[1] https://news.ycombinator.com/item?id=15436840

A huge chunk of my career has been programming in Turbo Pascal and Borland Pascal for Windows. I miss those days!

THINK Pascal

Re: Because I can't learn any other language

To my limited experience, everything Pascal had of its own is unusable. Everything usable in the language comes imported from C.

However I can see how one would prefer Object Pascal over C++.

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.

That was only true in toy Pascal compilers.

Any Pascal compiler for production code supported some kind of modules/units.

yes, this changed around 30 years ago.

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.

OMFG this brings back memories, like the promise of a processor that executed p-code. Good times.

Programs can be separated into thousands of source files (aka "units") for ages. Maybe your teacher didn't tell you about this to avoid confusion ;-)

Reply on news.ycombinator.com