In my experience (talking FreePascal/Lazarus here, as I'm on Linux most of the time), the library situation is not that bad, actually. The standard lib has most of the mundane stuff, and a little github-searching can often find a working version of more specific stuff (like SSH2 which I needed recently).

To the contrary, in some areas (like GUI tooling) it is far far beyond newer alternatives like Go.

Also, I think the higher level of the language than C/C++ etc can make it easier to develop your own solution, should you have to.

That's cool, this thread has definitely piqued my interest in Pascal!

We needed a app for branding. That login to a website. So it needed to do a POST request. I struggled with fp and google for 30 min, and dropped to the `RunCommand('curl',['https://ifconfig.co'],s, opt)` clutch with curl.exe(with licence file) bundled into my innosetup file... magic?!

libcurl (with examples) is bundled in the FreePascal distribution, as well as simpler alternatives like fphttp, fphttpclient, fphttpwebclient, etc.

Thanks will look into it.

It is hard to get the boss to allow you to write a mvp in non mainstream language.

So I had a quick swing at the libs and wondered about so/dll dependancies compiled against my exe; and just went for a bundled exe, yum and apt curl install script... under a day native win and ubuntu support?!:D I'm sure there is a TODO tag above my command for the junior that is going to hate me because he now needs to code in lazarus... ;)

FYI Free Pascal (and by extension, Lazarus) comes with fcl-web which contains, among others, an HTTP client.

See:

http://wiki.lazarus.freepascal.org/fphttpclient

Thanks this is the kind of info I needed. Only had a day in laz land and time was running out for my product. So had to cut corners. #TODO

At work, I maintain an in-house application written in Delphi/ObjectPascal.

In my case I do not need anything beyond what is supplied by the environment. The UI library is part of the environment, so is the database interface, ... basically, that is all the application needs.

Generally speaking, applications that basically are a UI on top of a relational database probably don't need any external libraries. And those are, uh, abundant.

Also, calling libraries written in C/C++ is possible, too.

I don't know about Object Pascal to C++, but calling C libraries is a no-brainier.

There is a bit of a definition wrapping, and then the C library looks like a pascal one, and unlike most interpreted/JIT/GC/etc languages where the programmer or wrapper has to jump through hoops to transform the data structures to match an in memory C structure, pascal just goes ahead and uses the same datastructure. This yields a far more transparent/efficient interface. Even pascal strings degrade to C strings by skipping the size header, and assuring they are null terminated before calling the C libraries.

In Delphi is quite easy if you make use of C++ Builder, since they share parts of the tooling.

With another C++ compiler on Windows, COM is a better approach.

Anywhere else than the usual plain C like APIs.

It depends on what you’re trying to do. In delphi you get a huge class library out of the box, and mostly you don’t need much else. There’s also still much third party stuff around the web from its glory years. The tricky part is interfacing with new external systems, and there it’s usually a matter of calling into a C library, which is easy to do.

I’ve found PHP to be trickier actually, because if there’s no extension to connect to the system you want, you don’t have a real fallback plan except writing your own extension in C.

Curiously enough, C still has native means to call Pascal functions.

At least in the past, the interoperability between languages was taken very seriously, because the industry used to abhor the idea of having to rewrite things just because of the need to use a different language (e.g. PL/I instead of Fortran); the object module format was designed to be language-independent.

As computers became faster much of software development switched to interpreted and VM-based languages, and language interoperability became a problem.

This is visible in the surviving IBM and Unisys mainframes.

It is easy to create bindings to the C-libraries you need, see http://wiki.freepascal.org/Creating_bindings_for_C_libraries.

But FreePascal has many native libraries for all kinds of stuff...

I haven't actually tried that, but my guess (even without checking that link) is that you are right, because:

1) C and Pascal are not too different as languages go (in some respects, both being sort of Algol-family languages), and:

2) I remember from earlier Windows API/SDK days that many Windows APIs had signatures/prototypes that went something like "long far pascal", and remember reading in computer magazines and source code listings about Pascal vs. C calling conventions (it may have been something like the order in which function parameters are pushed onto the stack before the call is executed, who cleans up the stack - caller or callee, etc.).

https://en.wikipedia.org/wiki/X86_calling_conventions

e.g. see the cdecl vs pascal conventions.

It's not a full answer to your question but I've sometimes found creative solutions to avoid FFI or ports. A good example I saw was someone who wanted to draw some 3D things generated in an obscure language without GL bindings, so they made a small external program in another language that took textual GL commands on stdin.

Delphi does have some choices in that space. https://github.com/Fr0sT-Brutal/awesome-delphi/blob/master/R...

Maybe this answers your question:

> But beside this historical excursion, what are the reasons that I use Free Pascal in my personal projects?