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.
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.
*: 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.
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?
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.
A good IDE / code structure will make the structure and code easy to differentiate anyway.
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.
{$R+} // range checking on - nice for debugging
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.
Why use Pascal? - https://news.ycombinator.com/item?id=36646890 - July 2023 (307 comments)
Modern Object Pascal Introduction for Programmers - https://news.ycombinator.com/item?id=36371434 - June 2023 (3 comments)
Castle Game Engine Roadmap - https://news.ycombinator.com/item?id=36365420 - June 2023 (10 comments)
Modern Object Pascal Introduction for Programmers - https://news.ycombinator.com/item?id=28079093 - Aug 2021 (3 comments)
Castle Game Engine: Cross-platform 3D and 2D game engine - https://news.ycombinator.com/item?id=23741883 - July 2020 (20 comments)
Castle Game Engine 6.4 released – physics, iOS services, shader pipeline upgrade - https://news.ycombinator.com/item?id=16207075 - Jan 2018 (2 comments)
In College we had to create a Stock Control program. It was an IT course so most people struggled as programming was not their direction. For me being a "prodigy programmer" had no issues jumping into Delphi.
If anything, knew little about Delphi. Once I started coding and realised I was typing var, begin, end, or := (etc) -- I knew it was some kind of Pascal. Going back to my earlier days in high school, I had a copy of Turbo C and Turbo Pascal so thats why I had a little head start.
I remember the difficult part was storing the stock data in a binary file, using binary search to find data, etc. My tutor was old-school so I wouldn't be suprised if Delphi had more 'out of the box' solutions which we take for granted in modern Go, C#, etc.
Everyone struggled to get their code to build. Brings back fond memories.
Today I place Pascal in the same Category as Basic. Seems like an interesting project but I just dont have interet using Pascal so would be a deal breaker for me.
I would not be surprised, however, if there is still a pretty large base of Pascal defenders out there. More power to them if the case.
But since I discovered C a year or two later, I never looked back to Pascal. C felt more "pro", more flexible and seemed closer to metal. Pascal seemed more appropriate for developing GUI apps, while C seemed able to tackle anything, from the most intricate guts of the operating system, to drivers, games and GUI apps. Of course, that was silly, because Pascal was able to do everything that C did, but to my younger self it seemed less "serious" and "pro".
Around '96-97 I was playing with writing fire effects in Turbo Pascal, most of the tutorials used the asm with mode 13h, and all I had was Turbo Pascal 5.5, which didn't support the asm keyword. So, I dabbled a bit with it, and then in late 97, I found about C, and when I saw the for loop in C - I never touched Pascal again.
I enjoy using it, even though I didn't decide to use it as my main stack for various reasons.
I mean it doesn't even have generics or exceptions, get with the times.
One thing I noticed was the file names, I can’t say I’m a fan of prefixing every single source file with “castle”, it makes it much harder to see what the file is about and makes them all look the same. I can’t comment on the actual code, since I’ve never written any Pascal. The engine looks cool though!
Meaningless nitpick.
I already know which files are castle files because they’re in the castle directory. It’s redundant information and it makes it hard to browse the files, eg I now need to scroll my file browser in my IDE to the right (so can no longer see directory names), Dane for tab labels snd file path breadcrumbs (on GitHub and in IDE), and on GitHub at least on mobile which is how I viewed it, it cuts the filename off after a certain length.
So I disagree that it’s a meaningless nitpick, it directly affects how easily I can navigate and read the file names. Just because yacc does it too doesn’t make it good (but at least in yacc’s case it’s not redundant information to know they are generated files, unless you put them in a yacc directory)
There may be a handful of yacc files in a large project, so prefixing them with "yy" is convenient to locate them quickly - though I'd still prefer a dedicated subdirectory.
Every file in this project is a "castle file", so preceding every name with "castle" is pretty useless and hinders readability and navigation. If it's not part of castle, it shouldn't be checked into the repo.
If you go through the available Delphi/FPC libraries, you will find basically anything. From CAD drawing widgets to frameworks for building SCADA systems. Most are not present on GitHub, and if they are, don't have hundreds of stars.
On the other hand I have an impression that in more popular languages like Rust - which I use for my projects, I admit - most projects fall into "grep for the 1000th time, but this time made right".
Object Pascal is a modern programming language. It supports classes, units, properties, generics, interfaces, reflection, closures… Everything you expect from a modern OOP language.
Object Pascal is a great language. These days it produces native code for pretty much all platforms out there. The binaries created are tiny, and the speed is high - close to what C will give you - meaning that typically the code will run between 100 to 10000 times faster than comparable Python code.
When it comes to Castle Engine, it's a gigantic project, making it extremely easy to create games and 3D applications in a RAD kind of way. And unlike other huge Pascal frameworks, it's not a legacy product, but very actively developed. I have HUGE respect for the developers.
A comparable gigantic impressive project is Mormot, and ORM/SOA/MVC framework which is based on extremely optimized code.
Building a Server application with Object Pascal and Mormot is easy to do, and where using NodeJS might be able to handle 500 requests per second, with pascal code you will be in the areas of 10000+.
And this means that while with other languages you might need to run dozens of servers to handle the load, your Object Pascal based server code instead would easily run on a single server. So, using that language can give you massive cost savings.
A lot of people only remember Object Pascal as a teaching language. But the language has evolved, and still has features other languages are lacking, most importantly RTTI (aka reflection). There is only one area where the language isn't up to date, and that is having Multithreading/coroutines integrated into the language itself like it's done in Go.
And finally: I can still compile and run code I have written 40 (!) years ago. Within those 40 years tons of languages have come and gone out of fashion. Pascal is still here.
Back to Castle Engine: Even if you are not familiar with the Object Pascal language, I can highly recommend to try out their visual editor. It's just amazing.
A pascal walked into a bar.
Then something got lost with Delphi, it's not that it was a bad product, but people started looking elsewhere...
I still cherish the day, as Pascal gave me the headstart to C/C++ from Apple Basic, but also allowed me to start using bit of inline assembly and learn it along the way...
[1] https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
Without doing much progress skill wise :-D
It's still around. The FLOSS version is called OpenSoldat now (I plan to get it back on track eventually as it became unstable with Version 1.8).
Really enjoyed the quick compile times :)
I don’t know a thing about Pascal, though, why would anyone still be using it? Is it good?
And mostly to see if those fond memories of learning to code with Turbo Pascal survived the test of time...
EDIT: after a quick search the answer is a resounding “you can do it, but yikes.” Multiple people reference custom compilers, which I’m guessing are beyond my reach…
https://news.ycombinator.com/item?id=12029566
EDIT 2: wow nvm it’s on their roadmap! Their “why pascal” page says it’s already supported, but i think thats more hopeful than contractual.
Coming soon (roadmap):
Oculus (VR) (we have the hardware to test)
WebGL (FPC can compile to WebAssembly)
XBox (we have the hardware to test).
https://castle-engine.io/features#_cross_platform
Highly recommend the “Why pascal” page in general, the most interesting part of the project to a passerby like me:
I used to translate my Pascal code to C by replacing begin/end with curly braces, moving interface declarations to header files, replacing well named functions to cryptic-sounding strtok calls, etc. It was all so unnecessarily ugly in comparison.
C is my favorite language now, but the cleanliness of Pascal and the user friendliness of Delphi have stuck with me as reminders of how great a developer experience can be.
I've been using Android Studio for 10 years now and the experience doesn't hold a candle to Borland Delphi Architect from 20 years ago. We might have more advanced features these days, but it's a disconnected mess in comparison.
I will always have a soft spot for C but try to find the right replacemenet.
Looking at Odin at the moment which I do like. It is taking inspiration from a number of languages, include C and Pascal.
What are the languages you would prefer to use now?
As mentioned, I have not touched Pascal/Delphi for around 20 years now. I dont have interest (re)learning this to use a 3D engine.
My reasoning is mostly due to popularity or, more specifically, job security.
Newer languages preferably, or keeping it C (atleast)
As mentioned in another reply above - I am learning Odin at the moment.
These are just my views. Like any view, can be scrutinised by anyone. We all have our preferences. I mean no ill towards Pascal in general.
Maybe it's not a humblebrag, but showing they're taking cross-platform seriously. I don't own an Xbox for example, and if I worked on something like this, buying one would be for the specific reason of making sure the project worked. I'd communicate that.
""" XBox (we have the hardware — even devkit, though "developer mode" can also be activated on a retail version of Xbox). """
As for web:
- This is mentioned on https://castle-engine.io/why_pascal as supported nicely by FPC compiler. FPC can compile regular Pascal code to WebAssembly, there's also Pas2Js that can compile regular Pascal code to JS. See samples e.g. here: https://github.com/genericptr/Pas2JS-WebGL?tab=readme-ov-fil...
- In the context of Castle Game Engine, web is part of "Coming Soon" of https://castle-engine.io/features . We want to utilize above to enable to recompile any Castle Game Engine application (as long as it uses cross-platform API) to the web. Details are on https://castle-engine.io/wp/2023/04/08/web-target-progress-a... .
And gotcha on the Xboxes, sorry if that was rude - clearly HN thought it was! I had no idea that there were special developer Xboxes. And in general was expecting a much less organized operation lol, you seem very on top of your game
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.
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.
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.
This goes a long way into avoid namespace conflicts.
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).
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.
Later someone unknown hijacked the original url and copied an outdated version of the repository (you can see the mention of OpenSoldat.)
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!'); 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'); case input of
'A'..'C': writeln('blah blah blah');
'N','n': writeln('blah blah');
'Y','y': writeln('blah');
else
writeln('Input invalid!');
end;