[fpc-devel] what fpc is good for?

[Daniël Mantione]

Op Sat, 12 May 2007, schreef Bisma Jayadi:

> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Might%20As%20Well%20Use%20Dot%20Net%20In%20Place%20of%20FPC
> 
> 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 
abstraction layer.

Meanwhile, we are near the top for speed, and at the top for memory usage:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

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.

Daniël