I'm gonna have to put a damper on things, here. Most of the reasons listed are things available in any other modern language (safety, cross-platformness, libraries...) but one of the things cited is readability.
I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less. The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo.
I feel like this page was written 20 years ago. The reasons would have made quite a lot more sense back then, notably about the type safety.
> The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo.
While I agree that it gets slightly tedious to read daily, I have to say that there is no language other than pascal that lets me come back to the language after 3 years and instantly be able to read it with no problems.
I don't know if any other language where this is possible.
While I'm not the world's #1 Golang fan, this is something that they have. They took a lot of complexity out of the language, so any code you look at will seem very simple & readable. There's not a lot of magic syntactic sugar, you just write things down the simple verbose way.
The flip side of that coin is you have to reimplement a lot of things yourself, so any essential complexity that the language doesn't handle for you is pushed on you to re-implement in your codebase.
Python's decent at this too. At least the simple Python people use in small scripts. It's almost pseudocode, as long as no one tries and overengineers it.
> Python's decent at this too. It's almost pseudocode.
Nim has Python-like syntax. But, I find it even easier to read/parse at a glance than Python.
Also, I hate that in languages with dynamic typing you have to read whole function to understand what type of arguments it takes and what is the return type. Nim is statically-typed, so all the types are properly declared.
In my experience, Python, C and JavaScript* all have this property; whereas I have to relearn Pascal, Haskell, sh and (to an extent) Rust every time I go away from them for a bit. I think this is more a property of you or I than of particular languages.
*: excluding `for (… of …)` and `for (… in …)` – I can never remember which is which. `for (… of …)` is the one you can use with Arrays and other iterables.
There's more that will trip you up in JS if you leave it for too long. Off the top of my head:
1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter?
2. I see code with both `!==` and `!=` - what is the significance of using both?
Long chains of filter and map are common in any language - they may have better chaining syntaxes, but since mapreduce can basically implement any collection operation you can imagine, filter and map chains are going to crop up.
With its tuple, object, and destructuring syntaxes JS actually ends up with some of the most readable mapreduce code of mainstream C-derived languages (it’s soooo much worse in Java).
1. `function` gives you a new `this`, whereas `=>` closes over the `this` from the parent scope. Which to use depends on what you want. (Full disclosure: I would've had to think for a bit whether the syntax was `->` or `=>` – though I'd probably guess `=>` because `->` means something in C.)
2. `!==` is strict comparison, and `!=` tries to do incomprehensible magick to munge incomparable types together. I still know some of the rules (array to string sticks in my mind), but I doubt many people know all of them. There's almost never a good reason to use `!=`, outside `elem.value != my_integer`. (Though `NaN !== NaN`, so you need to watch out for that: since equality is defined recursively on objects I'm pretty sure this is infectious.)
3. The length of the chain is easy (though, iirc there are performance implications since it's not lazy). The hard part is the fact that map callbacks can take one, two or three arguments, so stuff like `["123", "456", "10", "1234"].map(parseInt)` will behave unexpectedly. (Something like `[123, undefined, 2, 5]`, though I might be thinking of PHP.) Not sure whether `Array.prototype.filter` has similar gotchas.
That's off the top of my head. I haven't seriously used JavaScript since the ES5 times, but JavaScript's a very… memorable… language. (I can't even remember hello world in Pascal.)
> I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less.
I'd disagree with that. I've worked on several Free Pascal projects, C projects, C++ projects and some other stuff and i find it easier to follow Free Pascal code in big projects written by other people than C/C++/Java/etc. At least, i'd say that outside extreme cases (like esoteric languages - or trying to write OOP code in an XML-based language with only imperative functionality :-P), readability is up to the reader.
Go is the only other language i found easy to follow, despite not really knowing much about the language itself, but Go is also a much simpler language, more limited in its feature set - Free Pascal on the other hand is a "kitchen sink" language where everything and anything goes and yet it still remains easy to read.
That said, IMO the #1 reason to use Free Pascal isn't so much the language itself (most of the stuff mentioned are also available in, e.g., D - and i'd say that D does a much better job at doing compile-time stuff to the point where you can probably implement yourself any missing features from Free Pascal) but the Lazarus IDE and the FCL and LCL frameworks. Well, that and that it has a very fast compiler with a decent optimizer (and there is the new LLVM backend if you need more oomph, though with a big hit to compile time) and a large number of supported platforms.
Also great backwards compatibility. That is very important, if my X years old code that used to work stops working without externally imposed reasons (e.g. uses OS-specific code and i switched to another OS or the universe replaced x86 with RISC-V) i don't care how clean, consistent, elegant or whatever else a language might be that give theoretical language designers warm feelings, i care that my code that worked doesn't work anymore.
Can you expand on Pascal vs Go? What is Go missing?
I do not know much about either language, but the first thing I thought when people compared Pascal to Go (another comment, not yours) was what about concurrency? Go does have strong concurrency story.
AFAIK there is a lack of mobile support, so the use case for Free Pascal is strongest for cross platform desktop apps?
Is it something you think is still worth learning? Using for a new project rather than legacy code?
> Can you expand on Pascal vs Go? What is Go missing?
Proper type creation (create a new type for integers less than or equal to 12, and greater than or equal to 1, for example)
Proper enum/ordinal types (Even C is more strongly typed than Go in this instance, because C enums are not just ints, and you can't supply an invalid value to a function expecting a specific enum).
Both these together demonstrate the much stronger typing in Pascal.
> Can you expand on Pascal vs Go? What is Go missing?
On the context of classical 1970's Pascal, enumerations instead of the const/iota dance.
On the context of Pascal dialects derived from UCSD Pascal and Object Pascal, by non specific order, exceptions, package naming that isn't tied to source control repos, binary distribution of packages, powerfull generics, metaclasses, GUI RAD tooling, more investments into optimizing compilers (gccgo seems stuck in pre-generics Go).
Personally, I came to peace with Go, still hoping to const/iota dance to come to an end, some day.
> Can you expand on Pascal vs Go? What is Go missing?
Pjmlp mentioned a few, though i wouldn't say so much they are things "Go is missing" but more "Go does not provide them" - at least in my mind it is more of a FPC has "more stuff you could use" than Go lacking stuff.
> what about concurrency?
It is pretty much the same as you'd find in most other languages: done via threads with some language support for thread level storage. There are some helpers in the library and Lazarus also comes with a package that allows you to run stuff in parallel like a "parallel for", but nothing higher level than that.
> Is it something you think is still worth learning? Using for a new project rather than legacy code?
I think if you want to make a desktop application that runs in multiple desktop OSes, it is worth to learn it so you can use Lazarus. For other stuff, i dont think it provides that much of a benefit compared to other languages. I think the weakest aspect might be server-side apps - there is some support (even out of the box and Lazarus even has some RAD support for it so you can do things like routing URLs to different parts visually) and a framework or two, but i get the impression that most effort is in desktop stuff.
> Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction.
First of all, there is syntax highlighting.
Furthermore, after the first few times you see a word you don't actually "read" it in the sense you mean here, you are just matching it, as an image, with other words in your vocabulary. So it's not any harder to "read" a word than to read a curly brace, assuming no other very similar words are used in the vocabulary of the language.
Words can be helpful for people who don't like symbols? C is very terse, Pascal verbose. It's like C vs Python. Single-character symbols can be hard to parse for some people in the same way words are for you.
A good IDE / code structure will make the structure and code easy to differentiate anyway.
Most probably you already learnt the alphabet in the past, and there is 0 cognitive load for your brain to parse it. Unless you come from a language using another alphabet, but then unfortunately you need to bow to Latin alphabet rule over programming languages in any case.
Your example isn't idiomatic. You would not write begin/end for single-line cases.
Instead it would be:
if ((input = 'y') or (input = 'Y')) then
writeln ('blah blah')
else if ((input = 'n') or (input = 'N')) then
writeln ('blah')
else
writeln ('Input invalid!');
OR even better
case uppercase(input) of
'Y': writeln('blah blah');
'N': writeln('blah');
else
writeln('Input invalid!');
Well if we're doing that, then you wouldn't use the curly brackets in the C style syntax example either. If you just make one ideomatic without making the other ideomatic, the comparison ceases to be fair. Anyway, doing that to both of them would make the comparison pointless, because the point wasn't to compare ideomatic code examples, but to compare the syntax in a general case, so writing them slightly unideomatically to show off the general-case syntax is fine, as long as both are written the same way to control for unrelated variables (like special-case syntactic sugar), which is precisely what the original comparison did: write both code samples in the most general way, and crucially in the same way, so we could directly compare the scanability of syntax. And imo C won by a mile.
TBH? I see them basically the same. My brain probably scans equally faster "b...n" and "e..d" then the direction of the curly brace. And I haven't read or written Pascal since early high-school, ~30 years ago.
Great example. Your C-Code translated to Pascal would be
if (input = 'y') or (input = 'Y') then
begin
writeln ('blah blah');
end
else if (input = 'n') or (input = 'N') then
begin
writeln ('blah');
end
else
begin
writeln ('Input invalid!');
end;
Now this does not look any different then your code.
Except your code does compile but has several errors.
And why should be the double pipe be any better to read than
an "or" statement?
Btw: as you won't need the begin and ends it would look like
if (input = 'y') or (input = 'Y') then
writeln ('blah blah')
else
if (input = 'n') or (input = 'N') then
writeln ('blah')
else
writeln ('Input invalid!');
This is like comparing Latin alphabet with Egyptian pictograms or Chinese hieroglyphs. The time has proven multiple times that using words is easier for humans than using symbols.
I don't have a preference over whether C or pascal is more readable. One might seem more readable depending on my mood or time of day just like editor colors. But my main reason to use a pascal game engine for games would be to avoid garbage collection.
Possibly most of these arguments are arguments in opposition to Lua, the dominant scripting solution in video games, as opposed to pure positives for Pascal?
In the 90s a spent many years programing in pascal in Think Pascal... not glamorous but it got the job done. It's not too bad but I program on C++ now so... yeah, maybe my brain has melted.
Is it though. The whole cross Plattform is a leaky abstraction almost anywhere. Just accept it's gonna be limited to windows and reduce the workload for main revenues market.
As someone who has been coding in Delphi for a living for the past 5 years I'd argue the syntax being verbose is only a small part of a larger problem, which is that (object) pascal is a very bad language for pattern recognition.
The syntax highlighting in current IDEs like RAD Studio or Lazarus is very poor (though I'm not as familiar with the later).
I mean I think aside from keywords, strings, numbers and comments everything has the same color. Even if the syntax was less verbose, we'd still be reading each word. It is basically the same as having no syntax highlighting at all.
And even assuming the syntax highlighting would get better and/or the syntax would be less verbose, we'd still be reading each word because of the case-insensitive nature of the language.
The compiler might not care about the case, but at least my eyes do. So unless I'm reading the word I could not really say whether MyMaGiCaLnAmE and mYmAgIcAlNaMe is the same name or not.
I'm gonna have to put a damper on things, here. Most of the reasons listed are things available in any other modern language (safety, cross-platformness, libraries...) but one of the things cited is readability.
I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less. The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo.
I feel like this page was written 20 years ago. The reasons would have made quite a lot more sense back then, notably about the type safety.