[fpc-devel] what fpc is good for?

[Daniël Mantione]

Op Sat, 12 May 2007, schreef L:

> > As far as I know, Lars is a FPC fan, and he merely wishes to express concern
> > about some of the issues he has with FPC
> 
> Yes I'm a fan.
> 
> It's not just the issues that I alone have with FPC since I'm not even an embedded programmer
> myself. I'm putting myself in their shoes. It isn't just me who is saying lazarus is on the edge of
> becoming the next OpenOffice sized bloatware. It is a lot of the folks on pascal game devel board
> too who are saying the same thing.

Indeed. Most however, don't read the manual and complain about 6MB exes. 
Therefore, our opinion is that there is a perceived problem rather than an 
actual problem. Still, 1mb for an empty LCL application is on the large 
side. It is not unlikely that are at least some things that can be done, 
but often it isn't so easy since many factors need to be taken into 
account.

I'd rather approach the size problem from an engineering point of view; a 
50k exe is better engineering than a 500k exe, *if* there are no other 
factors (speed, memory use, portability, maintainability, compatibility, 
...) to take into account, who play a just as important role role in 
balancing the engineering. If we can improve the engineering, we will.

> Now to address the other people's emails..
> 
> Regarding my comments about D/C++ killer..
> You guys are nitpicking me.
> 
> Regarding the idea that I don't propose any solutions to the problem. Come on now, I've written
> capstring and compactsysutils and many other units to solve many of my problems that I complain
> about. The point of the articles are always to point out that FPC isn't this *perfect* fanboy
> thing - instead of being a *fanboy* I find myself more productive jumping into a criticboy's shoes,
> while contributing code at the same time. Criticism and complaints are just like bug reports.
> Without these reports, we all just sit behind our PC's thinking that there is no room for
> improvement because FPC is already so good.
> 
> I think some of you should look at this URL below too, with regards to Java history and why Pascal
> had a big influence on Java:
> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Pascal%20is%20An%20Unrecognized%20Underdog
> 
> Above is one of my optimistic articles and doesn't contain too much pessimism.
> 
> Just because you have seen not too many C programmers float over from C and join the Pascal
> community, does not mean that D programmers and C++ programmers and Java folks won't join ship. In
> fact, over at
> PasForum there is a PHP/C programmer who is considering using the powerful web utilities. Looking
> over my web statistics, I have found quite a few people looking for D language information, and they
> bookmark my site since they accidentally stumble upon some of my pages which mention D language.
> They realize that pascal seems interesting and more mature than D, and that is a big advantage. D is
> new. Pascal is mature.
> 
> Whenever Linus Torvalds takes cheapshots on the Pascal language, I sometimes respond to the articles
> and I get some reasonable C programmers coming in to my site, and they see that current pascal isn't
> just a dead end.. and some of them jump ship and test out FPC. Maybe not millions, but one or two
> can even make a difference to spread the word. In fact some of us Pascal programmers are so humble
> and so positive, and so anti-critical, that we misinterpret Linus' flames on pascal as compliments
> to pascal. He said something once that was so rude to Pascal, and everyone thought he was
> complimenting pascal. Funny. (Bee, this was the structured vs unstructured article on kernaltrap,
> I think)

I applaud you for your advocacy efforts :) They are often brilliant.

> Anyway, as we discussed on IRC one time, the real problem with Sysutils is that it needs to be split
> up into smaller units but we would break Delphi compatibility.

Indeed. Few people disagree that sysutils is a bunch of everything. 
Splitting it up would be a good measure, for multiple reasons, one 
being exe size. However, compatibility needs to be taken into account, 
this is where things get difficult, since the compiler would need to get 
extra features in order to be able to be able to provide 
this compatibility. In other words, doing it the proper way is not so 
easy, for a small improvement in engineering (a few 10s of kilobytes at 
most).

Instead, we tried and succeeded to solve another engineering issue, namely 
that resourcestrings could not be smartlinked. This was not so easy 
either, it improves reduces sysutils overhead by several 10s of kilobytes 
too, and has a much larger impact than just sysutils alone.

> The problem with LCL is that a lot of
> initialization stuff may need to be moved out. I may not have a PERFECT proposal for that myself..
> figuring out what we are going to do about that, so I complain and write an article and maybe other
> folk will come up with brilliant ideas. Do you see why it is important to write thoughts down,
> including both negative and positive ones?

To be honest, I think that if there were some good ideas, they would have 
already been implemented. The Lazarus team gets enough complaints.
A agree criticism can sometimes be usefull in case a team is needs 
refocusing or something. However, I think we are exactly moving in the 
right direction with the compiler.

> Even if I have tried to solve some of the problem by
> offering code such as capstring and compactsysutils, it still helps for me to get the thoughts down
> on paper and have hundreds of other developers think up solutions based on my comments - even if
> exaggerated.

I have never heard of those units. I have searched freepascal.org for both 
names and I found awfully little; assume that for the community those 
units don't exist.

Taking a look at compactsysutils. I see a cut down sysutils unit with a 
lot of assembler code inside. While such a unit could be usefull for some 
people, for the majority of our users it is not. For starters, see the 
"lack of compatibility" complaints elsewhere in this thread. Nor can we 
base FCL or even LCL on it, since in practise, both units would end up in 
end users their programs, increasing exe size instead of decreasing.

Sorry to say, but you are not interrested in embedded development at all, 
since if you were, you would have added Pascal versions of those 
procedures or added assembler versions for other processors. Assembler 
versions of common procedures are welcome, by all means, contribute them, 
as long as things stay portable.

The capstring unit is nice, but again does not take all factors into 
account and that is its usefullness for short strings. Its nice to 
increase strings by more than a kilobyte at a time, but most strings are 
small. For example, the amounts of string used by the compiler that are 
smaller than 8 characters is staggering. I.e. don't use it as ansistring 
or even shortstring replacement.

This unit addresses a widely known defficiency of ansistrings though.

> I'm not just complaining about sysutils and LCL being bloatware regarding exe size, I'm looking at a
> bigger picture here - it is bloatware as a piece of source code to maintain, too, you know. It is
> hard to maintain the sysutils unit with all the include files and millions of functions and classes
> in it.

I agree, but there is nothing we can do about this, we need all that code 
for compatibility. You can assume it'll only grow and grow.

> The LCL - well I am not an expert there and I hoped someone else would find a way to make it
> less monolithic. Sorry for complaining and not offering any LCL code.  Putting a complaint out there
> in the air is like putting a bug report out there - I may not have a solution to the bug but at
> least I reported a possible issue.

Perhaps, a possible way out is to make the LCL more plug-inable. For 
example, the LCL needs to support many graphics formats, and the code 
ending up in the program has to be designed to support them all; you don't 
know what ends up in the resource files. As a solution you could design 
"plug-in" units that add the support; i.e. don't use BMP formatted icons, 
then don't use the BMP plugin.

But I'll leave this up to the Lazarus team. They have talented developers, 
and I'm sure they are brainstorming about ideas to reduce the exe size. 
However, Lazarus developers do the engineering balancing too and weigh exe 
size against anything else.

> I also complained and complained about websnap and asp and php, and of course I also wrote some code
> that solved my problem there which is all FPC based, the poor old wiki, forum, and other utilities
> on my site that need updating. Others choose the easy solution and use ASP and PHP.. boring. I
> complained about FPDOC and wrote some extensions for my own lufdoc, and I complained about numerous
> other things and went ahead and wrote code.
> 
> I will offer you folks some system.pp units that I'm sure will help the embedded programmers too.

It is better to work on the existing embedded infrastructure that Florian 
included in the system unit: Add ifdefs to remove features.
 
> I also complained about a web based FPC compiler being a silly idea, since people could just
> download the compiler.. how hard is that.. but then I went on and wrote one because I found another
> use for it.  I see a lot of code being pumped out from myself here and this is the reason I'm not on
> the mailing lists to reply as much any more.

Yes, it is nice :)

> Regarding the 64 bit stuff - well one real world example of where 64bit is needed seems to be in the
> GO game that Frank De Groot is working on.  He stated that he may be moving to C/C++ because delphi
> and FPC don't suit his needs. He could extend FPC, because it is open source, instead of
> complaining, but he could also just do something easier.. maybe move to C/C++? I hope he doesn't and
> I hope maybe even he has the knowledge to help with the FPC compiler.. but realistically sometimes
> programmers choose the easiest option for them. However, since Daniel mentioned the next release of
> FPC will contain improvements, I hope it helps Frank a lot and I hope he doesn't choose to take the
> easy route and just move to C++/C.
> 
> The size stuff - oh no, not this again. Think about memory footprint and not just speed of
> algorithms please.

FPC programs (LCL included) have a smaller memory footprint than anything 
competing. Becuase we don't hide exe size in huge framework libraries.

> The reason I use Foxit reader instead of Adobe Reader is because it is more
> responsive.

Compared to Java, XUL, Lazarus programs are very responsive. Compared to 
bare GTK or QT, I don't notice difference.

> Whether this has to do with memory footprint, speed, size doesn't matter to me much - I
> just know it is faster by feeling it with my keyboard and mouse. I have tried out many Lazarus Apps
> by feeling them, not by just looking at Exe size. Lately, they feel slow, probably because of the
> abstractions and footprint I suspect.

Well, this is not my experience, I think situations of unresponsiness are 
candidates for bug reports.

> It's not just cross platform abstraction, I assure you, since
> many cross platform abstractions can be solved with IFDEF's which are not stored in the exe.

You cannot bridge the win32/gtk/qt/carbon differences with ifdefs. This 
needs actual abstraction code.

> Other
> folks agree with me.. many people on the pascal game devel BBS are saying Lazarus is becoming huge
> and slow.

Disagree. There are many complaints about 6MB exes, or 10 second 
compilation times. While these are actual complaints, the conclusion that 
Lazarus is huge and slow is unwarranted.

> Hey, we are just reporting a bug okay? If a bug is reported, it doesn't 
necessarily mean
> that we have the solution for the bug. Reporting the bug is still useful.

> Memory is fairly cheap, but with things like VMWARE and Colinux running, my memory fills up darn
> quickly! Even on today's newer computers. Not to mention I have seen 1.5Ghz laptops for sale for
> many years now.. when is the 100.00Ghz one coming out? We have hit a barrier that you can tap into
> folks. A lot of people are dissatisfied with the speed and size of their applications - this is the
> REASON people are spending big bucks on faster computers and hard drives... Don't you see the irony?
> A lot of you folks recommend FastCGI whenever someone asks about web programming.. and fast cgi is
> all about building tight code with a small footprint.. but yet whenever someone mentions a small
> system.pp unit or a small sysutils unit all of a sudden we are offended about an attempt to make a
> smaller program, faster program, etc.

No!

What happens is that the people that you perceive as "offended" take other 
engineering factors in account. They are not interrested to sacrifice 
compatibility (i.e. delete all those TP and Delphi compat procedures) for 
smaller exes, or portability (i.e. kick out Pascal code and replace it by 
assembler code), for example.

If you provide a patch which reduces exe size without disadvantages, be 
assured that it gets included.

> A smaller program in many many cases means a faster program -
> definitely a faster loading program in many cases. Not all cases. We are talking about general
> trends here.

Note that we have fastest startup time in the world.

> I think we AGREE on many things and your nitpickings are just as bad as my nitpickings.

Yes.

> Also folks, I think some of you know that I'm not just *talking* on that paswiki, I really have
> offered hundreds of units for the FPC community and will continue to offer more units for you all in
> order to make things go smoother.  If you read something you don't like on PasWiki, I expect you all
> to analyze me and write about me. Don't remain quiet! Make your own websites, bring it up on the
> mailing lists. I would like more people to shred me to pieces with their own websites so we can have
> some more FPC content out there. And even if you hate what I say, please continue to use my code and
> download my units - I appreciate criticism and am in no way offended by any of your comments.

Ok!

Daniël