5 ms·

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. Late

• Svip 3y ago
  > 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.
  • pjmlp 3y ago
    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.
  • kmoser 3y ago
    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.
    • musicale 3y ago
      > I have no interest in languages that lack modern, robust, stable, up-to-date libraries. I guess JavaScript is out then. ;-)
  • nine_k 3y ago
    May we please have a few examples of what's missing?
    • Svip 3y ago
      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.
• zabzonk 3y ago
  FPC (if my experience with Lazarus is anything to go by) doesn't even compile quickly - certainly not compared to the Delphi compiler.
• slt2021 3y ago
  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++
  • weinzierl 3y ago
    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.
    • musicale 3y ago
      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.)
      • weinzierl 3y ago
        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.
        • 3y ago
• yeputons 3y ago
  > 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.
  • slt2021 3y ago
    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.
• lelanthran 3y ago
  > 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.
  • Rochus 3y ago
    > 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?
    • badsectoracula 3y ago
      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.
      • Rochus 3y ago
        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.
• badsectoracula 3y ago
  > 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).
• Rochus 3y ago
  > 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?
• unscaled 3y ago
  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.
  • pjmlp 3y ago
    There are other reference counted types with copy-on-write, like strings and dynamic arrays, it isn't only interfaces.
  • cxr 3y ago
    > 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.
• pjmlp 3y ago
  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.