
Modern Object Pascal Introduction for Programmers - eatonphil
http://newpascal.org/assets/modern_pascal_introduction.html
======
sysrpl
In my experience Free Pascal, that is what the article refers to as "modern
pascal", is a great language and compiler. It compiles to native code, to JVM
bytecode, and there is even a tool to transpile to Javascript.

Unfortunately it suffers from a stigma inherited from it's origins as an old
"teaching you how to code" language rather than a real language. Never mind
the fact that Delphi (the precursor to "modern pascal") was the brain child of
Anders Hejlsberg before he was snatched from Borland by Microsoft, when Anders
had remade Turbo Pascal (already great) into a fantastic product. Bill Gates
said "The only thing wrong with Delphi is that it's not made by Microsoft".

In short, Free Pascal a fantastic multi platform language and compiler, but
suffers from a lack of popularity due to being considered something old and
not very modern, even though it has all the modern features one might need.

~~~
unnouinceput
"..remade Turbo Pascal..." \- translation: C#. Yup, that's right, C# is a
clone of Delphi and then some.

Anyone knowing Pascal will have no problem jumping to C# because it will swim
in familiar waters, only difference is that being a Microsoft product has C
style syntax.

~~~
sysrpl
Well you have said what I always think. For those familiar C# feels like the
next iteration of Delphi, but with curly braces. Both Delphi and Free Pascal
haven't stopped though. They've added generics, extension methods, attributes,
and many of the other features that have also been added onto C#.

Free Pascal has gone further to add management operators, vector math
intrinsics, and improved array features.

~~~
Koshkin
> _with curly braces_

...and .NET in tow.

~~~
yjftsjthsd-h
Yeah, FPC can target an absurd collection of systems; can C# handle that level
of portability?

~~~
madhadron
Only in the same way as Java can (run the .NET VM) and the GUI story is far
less clear.

------
romaniitedomum
Seems Pascal is having a field day today. Makes this old Pascal fan happy! The
other piece is about Castle Game engine, written by the same author, Michalis
Kamburelis.

About the only issue I'd take with this piece, and it's minor, is that it's
slightly modified from the original and pushes the use of Delphi mode over the
default ObjFPC mode in the Free Pascal compiler. To see the original:

[https://castle-engine.io/modern_pascal_introduction.html](https://castle-
engine.io/modern_pascal_introduction.html)

While there's nothing wrong with preferring Delphi mode or ObjFPC mode, since
the differences between them aren't that great [1], a piece that aims to
describe the language should at least offer some rationale for a preference
that is urged so strongly on readers.

But otherwise this is an excellent piece for anyone wondering what Pascal
looks like in 2020.

[1] [https://www.freepascal.org/docs-
html/prog/progap4.html#progs...](https://www.freepascal.org/docs-
html/prog/progap4.html#progse62.html)

------
rubyn00bie
Alright, sooo... Pascal kind of seems like the holy land of "get shit done"
that isn't C or C/C++. At least as far as cross platform UI development goes
that isn't _electron_.

How is it maintaining a Object Pascal project in 2020? What are it's weak
points? Anyone have some examples of "modern" apps written in Object Pascal or
problem spaces it's still vastly better than the competition? Are there any
like magical libraries, frameworks, or patterns?

~~~
brnt
Main thing holding me back is very small online community, most is using
Delphi Pascal, not Freepascal, on very corporate and closed source projects,
usually old codebases thus no new nice features, and those nice new features
are often different between Freepascal and Delphi. So if you manage to get to
see someone's code, it may be using features not implemented in or coded in
modern Freepascal. And old Delphi Pascal suffers from similar things as 90ies
C or C++: it skips modern features and uses a style that is contrary to what
people now learn, expect or even enforce.

Also, there are a few incompatibilities/differences in stdlib between Delphi
and Freepascal, and it was very easy for me to run into them.

~~~
badsectoracula
> And old Delphi Pascal suffers from similar things as 90ies C or C++: it
> skips modern features and uses a style that is contrary to what people now
> learn, expect or even enforce.

Eh, even Delphi 1 has a lot more features than modern C and while there are
new features added in Free Pascal over the years, the old stuff never got
outdated or obsolete the same way that (theoretically) nobody writes C++98
(though in practice many do anyway, but they do it at night, hidden from all
eyes :-P). Pretty much all Delphi-like Object Pascal compilers (Delphi itself,
Free Pascal, Oxygen and i think a couple of others) use Delphi 7 as a common
denominator and the main thing missing from Delphi 7 as a language is support
for generics (but it still has a few collection classes).

If you read a book about even, say, Delphi 3, most of it (outside the Borland-
specific database stuff) will be valid in Lazarus. You'll just miss some
additional features modern Free Pascal and Lazarus provides, but the older
stuff aren't really obsolete or invalidated (this is also a neat thing about
Free Pascal and Lazarus - the time you invest in learning them won't be wasted
because the developers decided that now they'll try to do the same stuff but
in a different way).

~~~
brnt
I meant, from a modern day perspective of the respective languages.

Oh and people write old dialects, the old Delphi geezers at the previous
workplace also wrote pre C++98 C++, today. Impressive isn't it ;) Bigco's are
all about decades old code bases.

~~~
badsectoracula
Right, that is what i meant too. You are more likely to find today people
_not_ using C++98 in their new C++ codebases than you are to find people _not_
using Free Pascal 0.99-era code in their new Free Pascal codebases - largely
because there haven't been any dramatic changes in the language over the years
that require changing how you work with it. When you get new stuff they enable
new features, but rarely things change in how they work - at most you get more
conveniences (e.g. you can use a for-each loop in iterators instead of a
manual for I:=0 to iterator.count - 1 do..., but that is just a convenience,
it doesn't change anything).

------
unnouinceput
As a 20+ years Pascal/Delphi lover, this read is too much for beginners. I had
no problem going through it in one go, but it did felt a lot of energy was
spent even by me. Maybe it's better to be split in chapters, giving a
potential inquiry mind time to breath.

And yes, I do realize it has a left ToC. So maybe instead of one big document
with a lot of inline anchors, should be made separate files. Or perhaps both,
giving readers the opportunity to choose whichever they like.

~~~
oefrha
> Or perhaps both, giving readers the opportunity to choose whichever they
> like.

Yeah, good old texinfo-style entirely-on-one-page and one-page-per-node model
(as seen on the documentation page of any GNU project, e.g.
[https://www.gnu.org/software/texinfo/manual/texinfo/](https://www.gnu.org/software/texinfo/manual/texinfo/))
is heavily underrated and underutilized in “modern” documentation systems.

Want to quickly search for something in the entire manual? Use the one page
version. Want to read cover to cover or link to a specific topic? Use the
split up version.

Btw, this book is apparently written in AsciiDoc and generated by Asciidoctor.
There seems to be a multi-page plugin available, although I haven’t tried it
myself.

[https://github.com/owenh000/asciidoctor-
multipage](https://github.com/owenh000/asciidoctor-multipage)

[https://github.com/asciidoctor/asciidoctor/issues/626](https://github.com/asciidoctor/asciidoctor/issues/626)

------
zenlot
The first time I've played around with Borland Delphi was I think 99-00 and it
was good experience. Then moved on and kind of forgot it. Last weekend I
thought to look if Delphi still alive, found out that it's now owned by
Embarcadero, downloaded their latest architect edition trial (they have
community edition now too) and was surprised how easy it is to write cross
platform apps. Stuff which I've remembered from ~1999 - still works the same
way, and you can have Android, Windows, iOS, Linux GUI apps on the same
codebase in one go.

It's just pleasure to work with. If only Embarcadero modified their licencing
terms, e.g not charging ~5k for Architect edition and did some marketing they
could win over some space in software development world. Something like
Microsoft did with Linux and Open Source world when they changed their view on
it.

Even if you don't plan to use it, it's worth a try, just to see how joyful and
easy it can be to write cross platform apps. It also somehow reminds me
Smalltalk/Pharo experience in some ways.

------
lordgroff
Pascal was the first language I played around with after Amiga era BASIC. I
still don't really understand why it faded into relative obscurity. To this
day, I feel like it's close to a perfect language. It's fast, it's productive.
It's not a "safe" language, but its design from very beginning steered you
away from danger.

With Lazarus, it is probably the most pain free way to write GUI apps.

But more than anything else, it is so, so readable. This is often expressed as
criticism: it's verbose. But that verbosity is absolutely a small price to pay
for code that is often shockingly easy to understand.

------
atombender
I "grew up on" Object Pascal as a developer — first Turbo Pascal, then Borland
Pascal (for DOS and Windows), then Delphi, up until the early 2000s.

Back then, I wrote GUI apps and commercial games, but I also did a lot of non-
GUI development in Delphi, using technologies like COM, MAPI, etc. While
Delphi itself wasn't "meant" for non-GUI development, it was still a very nice
experience. The interactive debugger was fantastic, as it always was in
Borland's tools.

Nowadays, I don't see room for Object Pascal. While later versions of Delphi
have improved on the syntax (e.g. generics), it's still a fairly old-fashioned
language. It doesn't really have anything special to offer someone who already
knows C#, Go, Rust, Java, Nim, etc. There's a strong Object Pascal influence
on both Go and Nim, and those languages improve on it in every way, including
the size of the communities, the available libraries, and so on.

Delphi's killer app used to be GUI development on Windows, but these days you
need to target multiple platforms, and I'm not a believer in cross-platform
GUI toolkits; you end up with something that doesn't look great on any
platform.

I look at Object Pascal with a lot of fondness, but it's mostly nostalgia.

------
mckinney
Nice. While I suppose Pascal did suffer a bit from its "learning language"
beginnings, it was wildly popular as Delphi.

If only Anders/Borland had designed Delphi as a VM, similar to the JVM. Of
course he did that for MS with J++ (and then C#), but had Borland done it
first with Delphi, would MS still have squashed them? Probably.

As for the Introduction posted here, Nice! Well written and densely
informative. Refreshing to see some focus on Pascal.

One feature I'd like to see borrowed in other languages: Class references. In
my experience this feature would be extremely useful for code generators, say
in Java. For instance, you get virtual static methods and constructors. Man,
that would be nice.

~~~
FpUser
>*"If only Anders/Borland had designed Delphi as a VM."

That would've been enough reason for me not to use it. Targeting whatever VM
as yet another platform to compile to would be fine I think. It was actually
done for Java and .NET but hardly used. I guess it has no benefits compared to
native.

------
acqq
"By default FPC programs and libraries do not use the C library on most
platforms" (1) is what makes Free Pascal potentially interesting on Linuxes:
sometimes the dependencies that exist when producing the binary using C or C++
simply disappear if one could write a Free Pascal program.

I haven't been able to use it in the environment I worked recently, but I had
to waste so much time on the C and C++ library dependencies, different on
different systems. Free Pascal seems to be a possible solution to that.

\--------------

1)
[https://wiki.freepascal.org/libc_library](https://wiki.freepascal.org/libc_library)

~~~
badsectoracula
Using libc on Linux shouldn't introduce any incompatibilities (also you can
use libc with Free Pascal, e.g. when using threads you link against the
pthreads library which in turn needs libc and you can use libc's memory
management functions instead of Free Pascal's own functions which can be
faster), at least as far as glibc is concerned, since they are supposed to be
backwards compatible. For example I have binaries compiled on 1998 Red Hat and
linked against libc and libX11 working on two decades later distros just fine.

It is usually the libraries you use on top of libc and libX11 that tend to
break and introduce incompatibilities.

C++ is another topic though, but i think there is an effort nowadays to avoid
breaking that too.

~~~
acqq
> I have binaries compiled on 1998 Red Hat and linked against libc and libX11
> working on two decades later distros just fine.

The goal was avoiding to use "1998 Red Hat" to compile today something that
should work on a few years old system. That is the direction that is typically
broken with C and C++, to the point that only safe approach is, indeed, to use
1998 Red Hat. But using 1998 Red Hat forces you to use the very old compilers
and old anything else on that same Red Hat, which is what could be very
inconvenient in 2020, when one has to use other tools with newer features in
the process. If I understand, I can use 2020 OS and using Free Pascal
trivially produce binaries that would work on the older systems on which the C
and C++ binaries produced on the 2020 OS just wouldn't.

Edit, answer to the post below:

> i'm not sure if you link against libc if it'll generate versioned symbols

If I understand correctly, one can produce Linux binaries with Free Pascal
while depending only on Free Pascal's libraries which don't have libc
dependencies at all. And that is what I see as a huge potential to produce the
binaries that don't break on older Linux version, the way libc-linked
typically do not because Linux kernel is incompatible, since it isn't, but
just because GNU libc infrastructure allowing only "build on older Os for
newer" but not at all the opposite scenario.

~~~
badsectoracula
Yeah i was mainly referring to backwards compatibility.

And yes, AFAIK you can do that with Free Pascal, but i'm not sure if you link
against libc if it'll generate versioned symbols (which cause the issue you
mention) or not. I think it doesn't because you can crosscompile from Windows
(or other OSes) to Linux so it shouldn't need any OS-specific dependencies.
However it shouldn't be much of an issue even if it does since you can run the
latest version of Free Pascal even on very old Linux distributions.

------
musicale
There is very little that can be done with C-style syntax that can't be done
with Pascal-style (or Oberon-style) syntax.

I find the Pascal-style syntax to be easier to read. I also like that Pascal
has always had enumerated types and ranges. I'm neutral on nested scope, but I
think it could be occasionally useful.

After using C-like languages for so many years it is a little jarring to see
function calls without parentheses, but I think I like those as well.

------
vram22
Related HN thread of interest (IMO):

Delphi – why won't it die? (2013)

[https://news.ycombinator.com/item?id=7613543](https://news.ycombinator.com/item?id=7613543)

It is about:

[http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-
it...](http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-it-just-
die.html)

------
theamk
> 5.1. Remember to free the class instances

> The class instances have to be manually freed, otherwise you get memory
> leaks.

This was the most annoying part back in the Turbo Pascal days, I am surprised
it is still there. I'd think with all the changes (generics, etc..) they could
have added a smart pointer class?

------
srean
I am not very familiar with Free Pascal. Does it have coroutines ? Modula2
does but there aren't that many free and maintained implementations around.
There is of course GNU's Modula, but it wasn't very easy to install.

~~~
nurettin
fpc has no coroutines. Delphi has them. In fpc, You can declare a procedure or
function within another, but that's about it. Authors are skeptical of its
utility.

[https://forum.lazarus.freepascal.org/index.php?topic=45818.4...](https://forum.lazarus.freepascal.org/index.php?topic=45818.45)

~~~
FpUser
You are confusing coroutines with anonymous functions / lambdas.

~~~
nurettin
Wow, silly me I misread that thanks for the correction sorry gp. Yes, it has
coroutines in the sense that you can queue functions to be run as soon as the
event queue is drained, so that it looks like your UI is responsive, but they
probably won't be able to run concurrently unless said event loop runs on a
separate thread which I don't think it does correct me if I'm wrong.

~~~
FpUser
Coroutines do not really run concurrently unless you yield explicitly or call
functions that do async io (those yield automatically).

The main reason it is directly available in languages like Go is that they are
meant for building servers that do lots of network/file interactions and very
little actual calculations. In this pattern coroutine looks rather natural and
your code is not riddled with endless explicit yields. As soon as you step out
of that pattern coroutines became headache where once must constantly watch
and make sure that the interval between yields is not too big and they do not
block each other.

In my opinion coroutines are an artificial construct that is very specific to
the OS (Windows has fibers for example) and one can argue that it belongs to
some standard library rather than first order language construct.

Well Delphi is guilty in this department as well. It has direct language
support for automation services on Windows for example.

~~~
srean
> In my opinion coroutines are an artificial construct that is very specific
> to the OS

Coroutines are very convenient outside of OS too. Pipeline of operations,
alternative to event loops, agents in a game, ETL all seem (to me) a lot more
natural with coroutines than say with OOP. In some languages one has to resort
to (preemptive) OS threads for these. Those end up being very heavy weight.

------
himanshu810e
100+ points for this waste of time and piece of crap and dont even get me
started on their game engine

~~~
FpUser
I would agree that state of game engines/libraries in Delphi/FreePascal is far
from ideal. Pasvulkan on github might be possible exception as it is done very
professionally but is also very opinionated.

As for the subject itself you seem to be overreacting. Delphi and
FreePascal/Lazarus are very decent tools.

~~~
himanshu810e
I literally went over the entire thing and tried to find anything which is
adding value and did not find any. As of now I see this project as novelty or
a hobby project. You are free to think that I am overreacting but a piece of
crap will be called a piece of crap specially if it's getting hyped for no
good reason.

