A good IDE / code structure will make the structure and code easy to differentiate anyway.
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;
if input == 'y' || input = 'Y'
{
writeln ('blah blah');
} else if input = 'n' || input = 'N'
{
writeln ('blah');
} else
{
writeln ('Input invalid!');
}
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!');
case uppercase(input) of
'Y': writeln('blah blah');
'N': writeln('blah');
else
writeln('Input invalid!'); case input of
'A'..'C': writeln('blah blah blah');
'N','n': writeln('blah blah');
'Y','y': writeln('blah');
else
writeln('Input invalid!');
end; 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;
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!'); if (input in ['Y', 'y']) then
WriteLn('blah blah')
else if (input in ['N', 'n']) then
WriteLn('blah')
else
WriteLn('Input invalid');
if (LowerCase(input) = 'y') then
WriteLn('blah blah')
else if (LowerCase(input) = 'n') then
WriteLn('blah')
else
WriteLn('Input invalid');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.
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.
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.
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.
*: 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?
3. Long chains of `filter` and `map`.
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).
x = 0; !x → true
y = ""; !y → true
z = null; !z → true
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.)
Most languages : myArray.any((e) => true);
Delphi : AClass.any<Type>(myArray, function (e) : Boolean begin Exit(True); end);
The readability is through the roof, lol.
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.
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?
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.
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.
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.
Both iOS and Android are supported by FreePascal as well as Delphi.
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.
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.
{$R+} // range checking on - nice for debugging
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.