Modern Object Pascal Introduction for Programmers
newpascal.org
newpascal.org
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.
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.
Free Pascal has gone further to add management operators, vector math intrinsics, and improved array features.
...and .NET in tow.
In any case, i think Free Pascal does have variable lifetime analysis so its optimizations shouldn't need that either.
His work on C# is widely thought to be a continuation of his work on Delphi.
Still, I can understand the issues. Let's not forget that despite his work in the field, Hejlsberg isn't Mr. Pascal, that would be Niklaus Wirth. Who always had a way more minimalistic design perspective than others, starting with Algol-W and ending with Oberon-7. Comparing that to the kitchen sink approach of C# (and arguably even Object Pascal) shows two philosophies that can hardly be more different.
Specifically the infamous yet influential essay "Why Pascal is Not My Favorite Programming Language" has a laundry list of reasons why academic Pascal is hard to use "for serious programming", and many of them have been corrected in Delphi.
When Free Pascal is concerned there is no argument here... consider that the compiler has a special language "submode" that enables syntax just for interfacing with Cocoa/Objective-C objects (...or even the whole idea behind having different language modes and submodes in the first place - that is totally antithetical to Wirth's ideas, but in practice it is very useful).
Then don't look at c# version 9. There's an expressive and modern (immutable and null safe by default) language somewhere in there struggling under the weight of previous syntax and semantics.
The language itself feels also frozen in the early 00's, have a look at string handling for instance. Very verbose methods, and a problem that's true for the Freepascal dialect in general: small incompatibilities with Delphi Pascal, the dialect any old veteran will be used to and as such also much documentation/discussion online. Add to that a near invisibily in places like Github, and it does not make for a very attractive platform, compared to some others. Freepascal/Lazarus has a nice forum, and if you happen to be working in the same niches as other guests, that may be enough, but otherwise... I also couldn't help but notice that the practices passing around zipped code bases/fragments is alive and well on there, mirroring the culture of small but closed source tools the Delphi ecosystem was famous for around 2000. While friendly, very dated and 'source hidden' in its ways.
Verbose methods are a convention that you'll find in other languages too (e.g. Java and C# and also some C++ projects).
What is the issue with string handling?
Free Pascal has several language modes, one of them being Delphi which should be compatible enough to share and port code between the the two compilers (though the default mode in Lazarus is ObjFPC which is different and IMO the better mode). In practice the differences are small enough that unless they refer to very internal stuff (e.g. memory layout of RTTI data), anything you find online about Delphi also applies to Free Pascal (assuming of course that FPC has implemented the functionality, but since you refer to old veterans, i think everything those veterans and old discussions will be there).
I'm not sure what you mean with passing around zipped codebases, there are a ton of projects on GitHub. And how can a codebase be 'source hidden' when it is available as a zip?
The issue with string handling is (or was) that there seem to be different string types but that 'string' is used to describe all of them. Some of those methods require or produce ASCII, and it may be difficult to know what your problem is when you have one
The language modes suffer from incomplete support. The differences aren't large,but that does mean they re easy to fix. My previous employer, a Delphi shop for more than 2 decades, was unable to be compatible with Freepascal over some of these issues.
With limited source I mean that things like history will not be there, or its just a single file of part of a single file bundled up, so you're missing out on context. All makes it hard for a newbie, even for someone with some experience.
Step 1. A one window IDE please! (Even Gimp finally moved in that direction after years and years of pleading from the community).
Done. Here you go: https://www.getlazarus.org/
These aren't very obvious (in another comment i wrote that Lazarus can feel a bit messy and unpolished... this is one of the reasons i think that :-P) though and IMO it should be something that you get asked when you run Lazarus for the first time.
Are you sure you didn't configure it like that or something was broken? Lazarus' text editor behaves pretty much like every other text editor i've used on Windows, be it native (Notepad) or custom (Scintilla via Notepad++). Block selection only happens when you alt+click+drag (like in Notepad++ and several other editors), by default it should work the same way as any other modern editor (ie. shift+arrows should expand the selection which happens character-wise and select lines by expanding up/down - or just using the mouse to select...).
> The issue with string handling is (or was) that there seem to be different string types but that 'string' is used to describe all of them. Some of those methods require or produce ASCII, and it may be difficult to know what your problem is when you have one
As of version 3.0, plain 'String' is an alias for a mode-specific string type. For the default mode (FPC) it is 'ShortString' (the classic Turbo Pascal string), though the default mode is rarely used and only exists for backwards compatibility. When creating new projects and units, Lazarus uses the 'ObjFPC' mode, where 'String' maps to 'AnsiString' with a system-specific default codepage that you can optionally change. Note that LCL (via the LazUtils unit) does that to ensure UTF-8 on all platforms, so if you use Lazarus and LCL you can assume that 'String' means UTF-8 string. In 'Delphi' mode 'String' behaves like in 'ObjFPC' mode whereas in 'DelphiUnicode' it maps to 'UnicodeString' (which is really UTF-16 string, the name is for historical reasons).
For all practical purposes, with Lazarus and LCL you can simply use 'string' which will give you UTF-8 strings. If needed, the compiler will do any conversions for you, though most of the library has been extended to avoid any conversions. Older string stuff still exist for backwards compatibility, but you'll get warnings if you use them (the warnings will also usually tell you what to replace them with).
Note that this is new functionality introduced in Free Pascal 3.0 ~5 years ago. It is a bit more complicated than ideal, but AFAIK it was necessary to avoid breaking existing code - keep in mind that Free Pascal exists since the 90s and some people use code in it they wrote in Turbo Pascal / Delphi before FPK even started writing his compiler. Personally i only had to change a single type declaration (where i was using a string as a byte buffer - i replaced it with 'RawByteString' which is... well, a string of raw bytes :-P) in my code (which i wrote ages ago) after switching to FPC 3.0.
> The differences aren't large,but that does mean they re easy to fix. My previous employer, a Delphi shop for more than 2 decades, was unable to be compatible with Freepascal over some of these issues.
Makes sense but this isn't really Free Pascal's fault IMO, after all it is a single sided endeavor (FPC developers are trying to be compatible with Delphi but Delphi developers do not seem to have any such interest). If you need compatibility it should be something that you write your code with in mind and use functionality that exists in all the Object Pascal dialects you want to target.
> With limited source I mean that things like history will not be there, or its just a single file of part of a single file bundled up, so you're missing out on context. All makes it hard for a newbie, even for someone with some experience.
You wrote 'hidden source' not limited :-P. I'm not sure where history helps if you are not a developer of the project. In any case not everyone is on or likes GitHub or even interested in collaborative projects. Personally i use Fossil on my own PC and only release .zip extracts of my code (though the .zip extract does contain the change log at least). But i'm not interested in collaborative projects either :-P.
Also what people keep forgetting, J++ was actually what he first did after joining Microsoft.
If you read Ext-VOS paper and the history of F#, that was how the upcoming COM Runtime was rebooted to use a managed language runtime.
Hence why when one knows all these puzzle pieces, UWP seems so close to what they were trying out back then.
https://docs.microsoft.com/en-us/previous-versions/visualstu...
https://docs.microsoft.com/en-us/dotnet/api/system.windows.f...
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
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...
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?
But TBH outside of GUI development there isn't anything particularly special about Free Pascal that you wont find in any other language, especially if you do not care about requiring a VM (in which case something like C# will probably be the closest equivalent).
One thing that it has though and personally i find it very important when it comes to maintenance is that the developers care a lot about backwards compatibility - existing code you wrote even 20 years ago will keep working either as-is or with very minor changes. Personally two issues i remember having were in one case when character encoding aware strings were introduced, i was treating a string as a byte buffer (prior to that change they were basically byte buffers) so i had to change a declaration from using "String" to use "RawByteString" (which behaves as a byte buffer) - that was a single line change. The other change was when at some point some years ago (i think it was when Delphi-compatible generics were introduced) the ClassName of a specialized generic class changed format.
One issue Free Pascal and Lazarus have is that sometimes they feel a bit "messy" and unorganized or unpolished. But they are projects that are 100% community driven by many people, going back decades (especially FPC) so i guess that is to be expected, especially when they do not want to break people's code in pursuit of some ideal purity.
Also, there are a few incompatibilities/differences in stdlib between Delphi and Freepascal, and it was very easy for me to run into them.
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).
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.
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.
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/) 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.
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.
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.
--------------
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.
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.
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.
And of course there are cases, especially if you have C++ somewhere, where you have to bring not just glibc but also ld.so from the ancient system... (There's a big chunk of such libs packaged together to run Loki games ports on recent distros)
Note that glibc also has non-versioned symbols. Versioning was introduced much later than the binaries i've mentioned i compiled with 1998 Red Hat were made. In addition the reason behind versioned symbols is to be backwards compatible so older binaries not working on newer systems because of versioned symbols would defeat the entire point of them existing in the first place.
Let me point again: I started the thread describing the opposite scenario:
Developing a program and delivering the binaries to the clients, including those who installed the OS on their server farms 10 years ago and not upgrading them, and who expect the binaries to "just work" there too.
That's why Red Hat and "Long Term Support" concepts exists: so that companies don't have to spend more time chasing the latest and greatest and totally irrelevant newest version of everything.
One wants to be able to deliver the products to them too, and avoid developing only on these old system, working around the bugs that were solved years ago.
The resulting binaries should just use what is available in kernel, and that's it. It's a real problem and it should be recognized.
Which results in funky situations where 22 year old binaries run, but a binary that is less than 4 year old can't - because unless you do extra work, you will get versioned symbols linked and you might be unlucky enough to fall out of the window of supported versions quicker than you think (Happened to me ~2013 when dealing with GHC at university, made for some really annoying weekend fixing binaries around)
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.
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.
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.
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.
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.
> 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?
https://forum.lazarus.freepascal.org/index.php?topic=45818.4...
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.
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.
Delphi – why won't it die? (2013)
https://news.ycombinator.com/item?id=7613543
It is about:
http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-it...
As for the subject itself you seem to be overreacting. Delphi and FreePascal/Lazarus are very decent tools.