Lazarus
Miscellaneous => Other => Topic started by: mostlygreen on June 03, 2020, 11:42:43 pm
-
Hi guys, not a Pascal dev here but I'll start learning it soon.
I'm wondering why are there so few open-source Pascal/FP projects when comparing it with other languages. I understand that pascal is not as fancy as [xxx language], but I hear many good things about FP but cannot find so many open source projects/tools/libraries. And a lot of opinions say that when building something with Pascal, a lot of things must be built from the ground up.
Thanks!
-
The Top 350 Pascal Open Source Projects (https://awesomeopensource.com/projects/pascal)
-
It would be just simple function of number of users if true.
-
There are 10321 hits if you enter delphi in github search.
There are 1916 hits if you enter lazarus in github search.
There are 9562 hits if you enter pascal in github search.
There are 594 hits if you enter freepascal in github search.
Good part of delphi hits can be used in Lazarus with none or minimal effort (although many can not be converted that easily and some would require too much effort).
Lazarus comes with lots of libraries and components, and much more can be installed with package manager.
-
There are 4804 hits if you enter delphi in SourceForge search.
There are 893 hits if you enter lazarus in SourceForge search.
There are 2286 hits if you enter pascal in SourceForge search.
There are 179 hits if you enter freepascal in SourceForge search.
A lot would be the same than GitHub since a lot of projects fled from SourceForge but there are a bunch.
-
There are 10321 hits if you enter delphi in github search.
There are 1916 hits if you enter lazarus in github search.
There are 9562 hits if you enter pascal in github search.
There are 594 hits if you enter freepascal in github search.
Good part of delphi hits can be used in Lazarus with none or minimal effort (although many can not be converted that easily and some would require too much effort).
Lazarus comes with lots of libraries and components, and much more can be installed with package manager.
But that is almost nothing
If you enter C++ you 619 658, if you enter Python you get 1 471 952, if you enter Java you get 1 455 362
-
There is no doubt that there are more libraries written in C/C++, Python and Java than in dialects of Pascal but, that doesn't say anything about their usability.
For Delphi and Lazarus there are a large number of components that allow a programmer to _easily_ implement things that would require a lot of work with any of those languages, with libraries or without.
Also, quite a few of the _useful_ libraries written in C/C++ have bindings for Delphi and FPC. The fact that they are not written in Pascal isn't relevant as long as a Pascal interface for them exists.
Additionally, there are some things that are done faster and more easily with other languages than in Pascal, some of it due to available standard and non-standard libraries and some due to the different slant of the language.
That a lot of "things must be built from the ground up"... well, most things are, even libraries, no matter the language.
As far as Java goes, that's great stuff for someone who has no problem settling for a sluggish and clunky program. Great language for highly deficient portable tools.
-
I believe the main reason for it now is absense of a proper dependency management solution.
For those who have no idea - it's a tool which can identify, download and install (if needed) libraries of certain versions required by a project as well as the libraries recursively. List of requirements with versions is usually built on some textual file with description.
No rocket science here but with proper support from an IDE it's very handy - added a line with a dependency (library) description to a file and immediately after that can write code based on the library.
For library developers it's also a must as the situation when each library contains its own version of "common" routines and often other libraries is stupid and additionally it increases binary size. It discourages library developers.
It also pushes away newcomers from other ecosystems as almost each ecosystem has such a solution.
After using Maven in Java ecosystem I can't get used to manually download and setup libraries.
I'm aware of OPL, GetIT, Delphinus and some other attempts to bring dependency management to Pascal ecosystem but none of these attempts can be called a success.
There still no a standard, widely used and supported and (preferably) cross compiler solution for dependency management.
And it contributes a lot to attenuation of the ecosystem.
-
I believe the main reason for it now is absense of a proper dependency management solution.
C, C++ doesn't have either.
Not to mention most "average lazarus projects" have zero external dependencies.
Unlike C++ or Java, in Lazarus everything included already: gui, graphics, database (m.b. except web and mobile).
Of course the reason is that Borland lost to Microsoft.
History cannot be turned back, but who knows, maybe we wouldn't see C# and Java at all.
-
I believe the main reason for it now is absense of a proper dependency management solution.
OPM installs packages and solves dependencies: https://wiki.freepascal.org/Online_Package_Manager
-
OPM (I misspelled it in my post) is definitely a big step in right direction.
But it seems to be a part of the IDE (Lazarus) intended to quickly install packages which depend on something standard like LCL. But not on each other of certain versions.
I see no reason to bind a DM tool to some IDE or even compiler. Why to fragment ecosystem even more?
Also a DM must be a command line tool as it's often used in CI/CD pipelines.
Not to mention most "average lazarus projects" have zero external dependencies.
This is what I'm talking about. ;)
-
OPM (I misspelled it in my post) is definitely a big step in right direction.
But it seems to be a part of the IDE (Lazarus) intended to quickly install packages which depend on something standard like LCL. But not on each other of certain versions.
I see no reason to bind a DM tool to some IDE or even compiler. Why to fragment ecosystem even more?
Because thats where it is needed ? The OPM is about getting packages available to compile. Once Lazarus code is compiled, it does not need the external packages (in almost every case ?). Just to be clear, just because you installed a package to compile your app does not mean that the end user need install (or even know about) the package. Take the binary, and a very short list of very well know dependencies and it will run on most systems.
On Windows, that list is usually zero, on Mac that list is usually zero, on Linux, because Linux systems are so diverse, you need to decide if it is a GTK2 app or a Qt5 app, then you have the very normal GTK2 or Qt5 dependencies. Easy !
The exceptions are pretty much common sense, for example, if your application is designed to use XYZ database, its going to be dependent on XYZ database.
When counting the number of projects on eg Github, you also need to consider how many are active and used. Much harder than raw numbers. My sig mentions my active and well used Github project.
Davo
-
Thank you guys for your valuable insights.
In my original question, I was not only talking about libraries but also about tools or end-user projects.
-
Sorry to revive this topic.
The reason I choose FPC instead of C# .NET and VC++ when creating console apps simply because FPC creates standalone Win32 executable (am I right)?
C# .NET console app requires .NET Framework. VC++ requires VC++ runtime.
Please correct me if I am wrong.
I support Pascal since TP5.5 / 6/ 7.0, but for a good while I switched to .NET, and now I am back!
-
The reason I choose FPC instead of C# .NET and VC++ when creating console apps simply because FPC creates standalone Win32 executable (am I right)?
C# .NET console app requires .NET Framework. VC++ requires VC++ runtime.
Please correct me if I am wrong.
You are right, FPC programs do not require an external run time library to operate. Just a note, it is also possible, depending on how you code, to create a VC++ application that does not use/require the VC++ run time libraries but, it's not straightforward.
-
You are right, FPC programs do not require an external run time library to operate. Just a note, it is also possible, depending on how you code, to create a VC++ application that does not use/require the VC++ run time libraries but, it's not straightforward.
I really appreciate your acknowledgement and additional notes on this.
-
The reason I choose FPC instead of C# .NET and VC++ when creating console apps simply because FPC creates standalone Win32 executable (am I right)?
C# .NET console app requires .NET Framework. VC++ requires VC++ runtime.
Please correct me if I am wrong.
You are right, FPC programs do not require an external run time library to operate. Just a note, it is also possible, depending on how you code, to create a VC++ application that does not use/require the VC++ run time libraries but, it's not straightforward.
At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.
-
Hmm, does that also work for DLLs ? I use wrapper DLLs and that now requires a mess of runtimes to manage would be nice if that could be eliminated.
-
At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.
Thank you for that information. Visual Studio 2017 is what I use. I guess I should try again with your suggestion which I believe is one of the many things I tried but, I could be wrong about that. Though, at this point, I avoid VC++ and VS (except for debugging). MS' unsolicited VS updates have resulted in some of my programs no longer compiling, it gets tiresome to figure out what happened and, correct the "problem" only to have it happen again at a later time after another unsolicited update.
All that said, thank you again.
-
Hmm, does that also work for DLLs ? I use wrapper DLLs and that now requires a mess of runtimes to manage would be nice if that could be eliminated.
Yes, it's independant of whether you're compiling a DLL or an executable.
At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.
Thank you for that information. Visual Studio 2017 is what I use. I guess I should try again with your suggestion which I believe is one of the many things I tried but, I could be wrong about that.
At work - where we use MSVC - we've used that already back with VS 2008.