On Tue, Jan 26, 2016 at 1:01 PM, Fabrício Srdic <[email protected]> wrote:
> Em 26/01/2016 11:30, "silvioprog" <[email protected]> escreveu: > > > > As I said: "... But the one of the basic steps before chosing a library > (from any language) is read its specification, and know if it provides the > needed features, works in the expected SOs, and provides a good > documentation with a stable support. I need to make a device and it need a > microcontroller, so I found that the best choice is a PIC16F64A because its > datasheet shows all the features and the basic hardware that I need". > > > > ... > > > > "... Well, the mostly C libraries work fine in many OSs. One that I use > works in the popular systems (currently I need it just for Windows and > Linux) like GNU/Linux, FreeBSD, OpenBSD, NetBSD, Android, OS X, Win32/64 > and special systems like Symbian and z/OS, and it's already available in > some tools like apt, yum, npm, maven, pacman...". > > > > You are right. However, often we can't prevent when the requirements of > our project will change and what will change. As i have said, you can find > a library that address your problem today, but after some time, your > project's requirements changes and that external dependency becomes a > problem. The problem of cross-platform availability was just an example. A > particular library may have many other kinds of limitations. Very often, > you can't just figure out which of that limitations may become a problem > in the future. > There is no a language/compiler/library that can prevent all possible future problems or customers needs. :-) > > IMHO this isn't a reason, I also can find Pascal code that works only on > a specific SO, and hard to be implemented in other systems, so I prefer to > get some C library that already do it instead of spending a long time > trying to implement it just because "oh, I can't work with libraries". :-) > > I am not against the use of libraries. What i am trying to say is, when > you add an external dependency to your code, your code becomes constrained > by the limitations of that external dependency so, would be better if you > can solve the problem without add a new level constraints to your code. > Any choice must be done carefully for everything, language, compiler, library, Pascal component etc. Sometimes is better to reuse codes that already exit, instead of spending a long time trying to solve the problem alone. For example, I still can't find a pure Pascal package to build a HTTP 2.0 server, but I can create a Pascal header to reuse some C library that already does it properly. > > The main a real reason that I find is: mostly Pascal programmers can't > debug a C libraries. And many Pascal programmers can't use or don't know > how to use shared/static libraries by themselves and can't find time to > know it, but anyway they use external libraries implicitly, when they > declare Pascal units that uses them. > > > > Imagine if Lazarus developers think this same way, they probably would > not have created Lazarus for GTK and Qt > > Why i can't make an Android app using Lazarus, as the free pascal compiler > provides support to it? Is it because there is no GTK to android? And if > the lazarus GUI framework did not depends on external libraries? > > The lazarus team did the right thing. They did not stopped to develop the > Lazarus for Unix because "they couldn't use libraries". However, how would > be the actual scenario if the GUI framework of the Lazarus was developed > using just Pascal? Perhaps, I would not currently facing the problem of not > being able to develop an android app using Lazarus provided frameworks. > I couldn't understand what you meant. -- Silvio Clécio
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
