[fpc-devel] what fpc is good for?
daniel.mantione at freepascal.org
Sat May 12 07:51:39 CEST 2007
Op Sat, 12 May 2007, schreef Bisma Jayadi:
> Nicely put. ;) I've found it has good points on some arguments. It's good to
> be considered. :)
No, it is not good to be considered. He complains we don't care about
speed or size. I have to correct him: We care, if we can optimize
something we will. As a proof FPC 2.2 will both generate faster code and
generate smaller exes.
On the other hand, we consider the current situation unproblematic. FPC
applications run faster, and less memory than other frameworks. Indeed we
generate larger exes, but nobody needs to redistribute tens of megabytes
of framework with his application. Lazarus is in the portable GUI
market, not Win32. I fully agree Delphi is king for the Win32 GUI
market. Against QT, XUL, Java, on the other hand, Lazarus is way better
than each of them.
LCL applications are large, this is known, and something the Lazarus team
has to deal with. Still, if you refuse to enable smartlinking, you have
right to complain; those exes aren't 3MB if built properly.
But apparently the unsmartlinked size scares some people.There is a good
solution to this perceived problem: make smartlinking good enough that it
can be enabled always and remove the option not to smartlink. With the new
internal linker we are almost there. Further, the internal linker will be
able to smartlink unused virtual methods, reducing the size again. So,
again you have nothing to complain about that we don't care.
If you don't consider FPC usefull for GUI programming, apparently he
does't, the LCL disappears, and the problem disappears. No way you manage
to generate 3MB exes without LCL.
If you want to do embedded programming, FPC is IMO totally suitable. You
can nowdays even remove features like the heap from the system unit, how
small do you want to go? But for such purpose you should not use large
frameworks. I'm afraid asking that the ultra-comfortable frameworks
generate embedded sizes is asking for the impossible. This is the error
he makes: If you want the comfort of the framework: pay for it.
Nobody prevents you interfacing with databases directly, with GTK directly
for teh GUI and so on. For embedded programming this is the way you should
go, since there is no space for a database abstraction layer or GUI
Meanwhile, we are near the top for speed, and at the top for memory usage:
Watch what happens with those numbers when 2.2 is out.
There is nothing in this article we can consider, for starters because it
does not contain any proposals.
More information about the fpc-devel