Hacker News Reader

Comment by tangus | Hacker News Reader

I disagree with some of their reasons.

Modern: Object Pascal isn't a modern language. It was modern in 1998, maybe, but it hasn't evolved much since then. Latest big change was the addition of generics, behind almost any other language.

Fast: FPC doesn't generate particularly fast code, and the nature of OP objects doesn't help with locality. It's faster than scripting languages, but generally slower than AOT compiled languages, even those with GC.

On the other hand, the ecosystem is great. There are lots of good libraries and tools (the most remarkable one being Lazarus, the Delphi clone). In my experience, people working with FPC or Delphi don't care much about modernizing the language or things like that, the just get things done (TM). I don't see the language being attractive to new coders though, so I don't know what its future will be...

View on HN

> Latest big change was the addition of generics, behind almost any other language.

FPC added generics 17 years ago, that is far from recent. Also i'd say that anonymous functions and function references (closures) are better candidates for "big change that was added recently".

> FPC doesn't generate particularly fast code, and the nature of OP objects doesn't help with locality. It's faster than scripting languages, but generally slower than AOT compiled languages, even those with GC.

In practice the performance is fine and you can actually optimize the code as much as you need for any hotspots you find - it can be a bit more of a PITA if you use the "high level" classes compared to C++ but it isn't impossible.

Though if you really want performance out of the box with minimal effort from your side, there is a new LLVM backend. You need to compile the compiler from source to enable it as the entire runtime library, FCL, etc need to be built with the LLVM backend, but that takes only a couple of minutes. On the other hand the compiler becomes much slower (and IMO the difference in performance isn't worth it).

> Fast: FPC doesn't generate particularly fast code, and the nature of OP objects doesn't help with locality. It's faster than scripting languages, but generally slower than AOT compiled languages, even those with GC.

You're selling it short.

Firstly, as the other poster downthread pointed out, it benchmarked as fast as C++ in the past.

Secondly, it's main use is local gui apps, and there's nothing I've seen, including C# gui apps and have gui apps, that even comes close to how snappy it is.

So I am curious what benchmark you used to determine that it's about 50 times slower than it actually is.

> it benchmarked as fast as C++ in the past

Does this mean it's no longer as fast as C++ today? Do you have specific benchmark results?

You can find some in Debian benchmark game. In general FPC generated code is around 1.5 to 2 times slower the fastest entry (often C++). Note though that this is with FPC's own code generator and there is a new LLVM backend in the development version (FPC's own code generator is the default and will always be, the LLVM backend is for those who really want it and is much slower).

I'd expect synthetic benchmarks like those in the Debian benchmark game to be closer to C++'s performance with the LLVM backend.

When I had a look at the CLBG results last time the code generated by FreePascal was even about three to four times slower than C/C++; but the benchmark rules are not particularly well suited for fair comparison (some code is obviously written with inside knowledge of the particular compiler/version and not what you usually see for the given language, and the Pascal code likely includes range and overflow checks which make it slower compared to a language without these, etc.). The LLVM backend is not officially supported by FP and doesn't support all platforms as far as I know; and unfortunately micro benchmarks are usually not representative for the daily overall performance of an application; the Are-we-fast-yet benchmark suite would be better in this regard.

Anyway, I would be interested in why FP benchmarked as fast as C++ in the past, but no longer today.

> The LLVM backend is not officially supported by FP

It used to be a separate project but these days is part of the main development branch. Though indeed the OS and CPU support is very limited.

Also i agree about the micro benchmark comparison, they tend to exaggerate differences. FWIW in my own programs i never found Free Pascal's code generator to be inadequate.

I do not remember the exact difference but last year i did compile my 3D game engine with the LLVM backend and the difference was small enough for me to decide that i don't want to bother with the much slower compile times.

I read other comments of people claiming the code generated by the LLVM backend was less than factor 1.5 faster than the one generated by the original backend, which is not worth the effort (and the humongous overhead and additional dependencies) from my point of view; but I'm still trying to find information about the specific optimizations done in the current FP compiler.

> I'm still trying to find information about the specific optimizations done in the current FP compiler.

AFAIK there isn't any explicit documentation but the "toptimizerswitch" and "twpoptimizerswitch" (the latter is for whole program optimizations) types in the compiler define the available optimizations in globtype.pas and have the following values:

    cs_opt_level1,cs_opt_level2,cs_opt_level3,cs_opt_level4,
    cs_opt_regvar,cs_opt_uncertain,cs_opt_size,cs_opt_stackframe,
    cs_opt_peephole,cs_opt_loopunroll,cs_opt_tailrecursion,cs_opt_nodecse,
    cs_opt_nodedfa,cs_opt_loopstrength,cs_opt_scheduler,cs_opt_autoinline,
    cs_useebp,cs_userbp,cs_opt_reorder_fields,cs_opt_fastmath,
    cs_opt_dead_values,cs_opt_remove_empty_proc,cs_opt_constant_propagate,
    cs_opt_dead_store_eliminate,cs_opt_forcenostackframe,
    cs_opt_use_load_modify_store,cs_opt_unused_para,cs_opt_consts,
    cs_opt_forloop

    cs_wpo_devirtualize_calls,cs_wpo_optimize_vmts,cs_wpo_symbol_liveness

level1/2/3/4 are basically collections for some of the above and are enabled for -On where n is 1 to 4. You can enable optimizations explicitly with the -OoXXX (for per-module optimizations) and -OwXXX (for whole program optimizations). The -io and -iw parameters can be used to obtain the available names for these.

I think the names are more or less self-explanatory, at least for the most part (not sure what "uncertain" does... which i think is appropriate :-P).

Some brief documentation (though very brief) is available in the programmer's guide:

https://www.freepascal.org/docs-html/current/prog/progch11.h...

Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal).

I read somewhere that there are issues with higher optimization levels. Can you confirm that?

> Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal).

FWIW you may want to check out the fcl-passrc package[0] which provides units for scanning and creating a syntax tree from FPC source code, including some helpers like resolving references.

It is used by the fpdoc documentation generator and the pas2js transpiler that converts Free Pascal source code to JavaScript, both official FPC projects. fcl-passrc is itself part of Free Pascal.

> I read somewhere that there are issues with higher optimization levels. Can you confirm that?

AFAIK the main issue is that -O4 enables some optimizations that may break code that relies on things like having the exact same math output as non-optimized versions as it enables FASTMATH, code that relies on classes having specific field order (technically class field order is not guaranteed to remain the same) since -O4 enables reordering the fields to remove unnecessary padding and code that depends on runtime errors or exceptions being thrown from code that the compiler (in -O4) decided it has not explicit side effects and removed it.

These are not "issues" per-se but Lazarus labels -O4 as having "aggressive optimizations, beware" which might give a false impression.

Aside from that there might be bugs, but that is the case with any compiler.

[0] https://wiki.freepascal.org/fcl-passrc

Thanks again for the hints; I'm not (yet) fluent with FreePascal and assumed to be much faster when quickly implementing a rudimentary parser to make arbitrary queries over the source code (the one I implemented for Lisa Pascal/Clascal including the browser/cross-referencer took a week as a side project) than discovering and learning all the required FP libraries and tools; but the FP language turned out to have some pretty dark corners which are much harder to parse than I expected from a Pascal descendant.

Yeah, Free Pascal is far from simple. It not only tries to implement everything Delphi provides (itself never being a "simple" language) but also as much as other Pascal dialects provide (via compiler modes) and various useful features from other languages - and that in backwards compatible ways (often via "modeswitches" - kinda like submodes).

With that in mind it is kinda interesting that there are (AFAIK) three parsers for it anyway: FPC itself, lcl-passrc and Lazarus' CodeTools. It does mean that any new stuff in the language gets some time to be implemented in others though.

> Free Pascal is far from simple.

It's still much less complex than e.g. Ada or C++, and unfortunately, the language has redundant, competing concepts that are probably explained by - as you say - putting different languages and design styles together; it's definitely not my favorite language.

Unfortunately, there was also no complete and correct grammar, so I had to create one myself, and even in this one there are still productions without definition, e.g. array_constant, record_constant and procedural_constant. At least the syntax diagrams were not left recursive, and also removing ambiguous alternatives was straight forward.

Surprisingly, the FP language specification does not distinguish between language variants; only the compiler knows different modes. There seems to be a common grammar for all modes.

Delphi and C++ Builder share the same compiler backed.

Nowadays it is based on LLVM.

> It's faster than scripting languages, but generally slower than AOT compiled languages, even those with GC.

Not sure about FPC, but Delphi 7 was on par with C++ ten years ago in competitive programming, that is about 2-3 times faster than Java. By competitive programming I mean very short (1-3 seconds per execution max, so any JIT is at disadvantage), CPU-bound single-threaded heavily algorithmic computation on mostly default compiler/runtime settings with no external libraries or ability to tweak. The common knowledge was: you either use C++/Pascal, or use Java and occasionally rewrite your 200-300 line solution to C++ if you get "time limit exceeded" error, and it passes with flying colors.

reasons why Delphi was/is a strong option for CP:

1. Fast compilation enables edit-compile-run workflow. Fast iteration enables solving CP problems faster.

2. Native dynamic arrays, native String type

3. Easy to learn language for middle/high schoolers.

4. Usefulness for outside CP, for example I created GUI programs in Delphi for clients and earned $$$ while in 8th grade, right after I was done with competition season.

the greatest difference btw Pascal and C++ is developer experience.

Pascal uses a single-pass LL(1) compiler, which allows you to compile in milliseconds. Pascal enables REPL-like experience where you can Edit->Compile->Run in less than a second.

C/C++ with macros and slower compilation times is worse developer experience, at least it was the reason for me to learn Pascal instead of C and Delphi instead of C++

Just to add more context: Niklaus Wirth's foresight was to design Pascal's syntax to allow a single-pass compile. But it took more than 15 years until we actually had a blazingly fast single-pass compiler and that is totally Anders Hejlsberg's merit.

Every so often a thread pops up about Turbo Pascal and I'm astonished as to how nice an IDE you could fit onto a 64K CP/M system. (See also comments above/below.)

Oh, it was very very nice. I still miss it today sometimes. Here are a few highlights:

- Pressing F1 gave you reliably context sensitive help and the help content was really well put together.

- The debugger was great and was basically what we now know from Eclipse or IntelliJ and completely not like gdb. It had the same keyboard shortcuts for stepping as IntelliJ still has today.

- Computers in the 90s really did not support more than one display, but there was a weird trick that allowed you to connect one color and one monochrome monitor. Turbo Pascal fully supported that and could display the app on the color display while you saw the debugger on the monochrome one. This was before Windows and GUIs, everything was fullscreen. Without that there was no way to see debugger and app at the same time.

- The editor was so good that I preferred it over a word processor even for writing prose.

The best thing about built-in help was that it not only contained documentation of a function, but usually a short example code. That was extremely helpful and I relied on it a lot.

Back in the days of Turbo Pascal 5.5 I had a secondary monitor, a monochrome orange phosphor, connected to an EGA card, I think. The main screen was VGA. Two monitors provided a huge productivity gain, with common and cheap hardware, and it was super cool. Turbo Pascal was the only software I used that could display on the second monitor. Sometimes I miss seeing everything in orange.

I had a VGA and a Hercules card and it's probably hard to relay how super cool that was at a time and in an environment where computers alone were pure magic to most people. Then there were these kids, like us, that could not only use these magic programs but could control and manipulate them from a second screen:-)

TP IDE was indeed magical. Except for one pain point, from an emacs user POV, no extensibility. You can't tweak the ergonomics so you're stuck with what the devs put in. It was 99% perfect but that broke me out of it.

My memory is fuzzy, but even before Hejlsberg magic, Wirth parser was a light and fast (but maybe unreadable) hand coded piece of code.

> Pascal uses a single-pass LL(1)

No longer the case with the Pascal version used by the game engine.

which Pascal compiler is it - Embarcadero or FPC?

It's the language itself; I currently build a parser for FP 3.2.2 and I need more look-ahead than LL(1) in different parts of the syntax. And it has features which require more than one pass.

One thing this thread seems to forget, Pascal sources do not include literal kilometers of headers compared to C++, and there’s no code in Interface sections either. Every C++ translation unit explodes into a full set of libs at preprocessing phase. One pass or LL(1) is just a cool bonus compared to that.

Delphi and FreePascal have compiler directives and include files quite similar to C, and it's commonly used e.g. in the FP source tree, albeit to a lesser extent than in a typical C/C++ project.

> On the other hand, the ecosystem is great.

Hard disagree. I worked with Pascal for about 10 years, and the lack of modern libraries was a source of frequent frustration, meaning we often had to develop the solutions ourselves, or abandon an idea entirely.

In regards to Delphi there were plenty of them, sold by companies specialised in component libraries.

Naturally one had to be willing to pay for them.

Yep. Unless it's part of a legacy project, or I'm developing something as a fun experiment, I have no interest in languages that lack modern, robust, stable, up-to-date libraries.

> I have no interest in languages that lack modern, robust, stable, up-to-date libraries.

I guess JavaScript is out then. ;-)

May we please have a few examples of what's missing?

The situation may obviously have changed today, it's been a few years since I last worked with Pascal. Back around 2016, we were looking for a different way of communicating between our services (you could kind of see them as micro-services, but I would not describe them as "micro"), which until then had relied on our own communication implementation on top of Windows socket. Our implementation was OK, but could not communicate beyond a single Windows machine, and it definitely did not allow multiple instances of the same services. We wanted to scale up, so we started looking into new technologies.

Our lead developer was interested in building a RabbitMQ prototype. There were two libraries around to find, but none of them were finished, so we spent a lot of time finishing one of those implementations. We also looked into ProtoBuf, but that was a steeper hill to climb. When I left in early 2019, we were still using the old WinSock communication, though I understand from former co-workers, that they've switch to an UDP-based system instead now.

That's the most vivid one I can remember, because we pushed on, despite the available libraries being weak. I also remember trying MongoDB, which required a lot of polishing the available libraries as well. Other ideas I remember pursuing briefly, until I recognised finished some of the libraries would be too tall an order.

For the record, I don't have a problem with Pascal in general, nor its community. But considering how trivial it is to find a solid robust library for modern technologies (even if kind of fads) for other popular languages, compared to Pascal, it definitely feels weird to call its ecosystem "great".

Of course, the libraries I've mentioned may be great today. But RabbitMQ and MongoDB are also a bit older technologies today.

I also think the modern part is exaggerated here. Object Pascal was had cutting edge features and developer experience in the 1990s, but I think it's hard to see it this way nowadays.

There are two big features that one expects in a "modern" language that are missing in object pascal:

1. Some sort of automatic memory management that prevents memory leaks and dangling pointers. Modern languages usually have GC, automatic reference counting (like Swift or Python) or some form of static analysis (like the Rust borrow checker) - Zig is probably the only outlier here, but it does have better memory safety tooling (like defer). Object Pascal really feels like going back to C++ as it was during the 1990s and early 2000s, before smart pointers and later move semantics caught on. If I remember correctly, COM interfaces, but they carry the COM baggage and nobody is using interfaces for everything.

2. A package manager that is isolated (not impacted by the global environment), supports specifying dependency version in a configuration file and supports repeatable builds with lockfiles. fppkg doesn't seem to go that far.

There are other features that you could argue for I guess, like type inference, simplified expression syntax, asynchronous I/O and more, but they would be more controversial.

I don't think I can honestly call Object Pascal a modern language, and it's sad, since I still have a warm place in my heart for Pascal.

There are other reference counted types with copy-on-write, like strings and dynamic arrays, it isn't only interfaces.

> A package manager that [...] supports specifying dependency version in a configuration file

This is an anti-pattern common among modern programming ecosystems that they should ideally be moving away from—and ecosystems that are not already afflicted with this sort of thing shouldn't make the mistake of making it a milestone to aim for.

These versions listed in a text file that you refer to are nothing more than a way to route around one's own version control system (example: package.json and Git). The version control system should be used for version control—not text-file based hacks that end up being the source of unreproducibility. And to the extent that one's version control system can't be used because it doesn't do what you want, then that's something that should be fixed at the appropriate level (i.e. the version control system itself)—not with band-aids applied there, either.

FPC (if my experience with Lazarus is anything to go by) doesn't even compile quickly - certainly not compared to the Delphi compiler.

> but generally slower than AOT compiled languages, even those with GC.

Is this an assessment by experience or do you have specific performance data, e.g. comparing a set of benchmarks with C++? What's the difference if checks (range, overflow, etc.) are disabled?

The Object Pascal as originally created by Apple, not.

The Object Pascal adopted by Borland, and evolved into Delphi, is on par with plenty of C++ capabilities, given the Delphi/C++ Builder symbiotic relationship.

Reply on news.ycombinator.com