I mean, I certainly buy that $VINTAGE_LANGUAGE could still be great to develop in, but I'm curious the practicalities of working on modern systems without re-inventing every single wheel.
I mean, I certainly buy that $VINTAGE_LANGUAGE could still be great to develop in, but I'm curious the practicalities of working on modern systems without re-inventing every single wheel.
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.
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... ;)
See:
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.
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.
With another C++ compiler on Windows, COM is a better approach.
Anywhere else than the usual plain C like APIs.
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.
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.
But FreePascal has many native libraries for all kinds of stuff...
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.
> But beside this historical excursion, what are the reasons that I use Free Pascal in my personal projects?