[fpc-devel] what fpc is good for?

[Marco van de Voort]

> > 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.

IMHO this whole discussion has nothing to do with embedded. True embedded
use would craft an RTL for their purpose, creating a reasonably configurable
RTL that include what they would need.

This is IMHO pure shortsighted minimalism.

> 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.

I still fail to see a decent argumentation for such bold statement.
Everybody can take some toy framework somewhere and argue that it is way
smaller and call everything larger bloatware but that is unfair. 

> It is a lot of the folks on pascal game devel board too who are saying the
> same thing.

If they know it so well, where are their patches ? 
 
> 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.

True, but to be honest, I find your criticism for the most a bit unfounded,
and close to something that would be called "populist" in politics. 

This because it's easy to scream bloat. It is harder to explain the Russian
users why foreign character set and messages support got worse due to the
demands of people that want sysutils using binary sizes under the 100k. Or
to the Delphi programmer why his application now crashes, because the
runtime errors aren't caught as in Delphi.

> 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. 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? 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.

Note that Delphi's VCL and CLX have exactly the same problem. Lazarus' dead
weight is slightly more (20-40% depending on testing circumstances), but
that's about it. 

> 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.

Sure. A 100 lines program is way easier to maintain, but also way less
fullfeatures.

But keep in mind that this way a lot of (lazarus) apps share a *lot* of
code. Having all those apps duplicating that code, or having heaps of direct
widget calls to correct for defects in the framework, *THAT* would be bloat.

> It is hard to maintain the sysutils unit with all the include files and
> millions of functions and classes in it. 

sysutils doesn't include a single class to my knowledge (except maybe
exception?) It has a few hundred basic utility functions, none of which are
the cause of bloat, since all reasonably smartlinable.

The main bloat in sysutils is the excpetionhandling,  the resource system
and internationalisation in general. However you can't really do much about
that. (some stuff has been done in the internal linker, but that is not on
all platforms)

> The LCL - well I am not an expert there and I hoped someone else would find
> a way to make it less monolithic.

You can't do much. A lot is simply linked in because its published, and
registered classes can be instantiated by runtime looking up a constructor
in some table. The whole streaming system is based on it. If you try to axe it  

The only thing you could do is place _each_ component (and also all
ancestors to more than one "end" component) in a separate unit.

This would allow some control over which "register" clauses are run, and
maybe leave out a component here on there. But all base code would still be
in for the first component that uses it.

Moreover that would require way more administration, cause Delphi
incompability, and there are significant risks that in the end it doesn't
even deliver that much, because you use e.g. some 3rd party component that
must be able to interact with component X (say a Zeos or so), then the
component will be linked in due to some uses somewhere, even while you don't
use component X, and don't interact via Zeos with a component X.

If you want to get a feel for what is possible, there has been a small
discussion about improving this kind of stuff in Delphi/FPC a fat month back
in comp.lang.delphi.misc  (.pascal.delphi.misc)? This one convinced me that
the yields of trying to eliminate virtual methods won't be as high as I had
hoped for.

Probably a Lazarus developer can explain this way better than me. THe only
real solution is to throw anything overboard and go back to handcrafting
forms, and avoiding any handy systems that allow choice (like
internationalisation, dynamic loading etc). Only the most basic (and
preferably severely limited in # properties) components.

Nearly all of the alternatives seem to work at first, but as the
programs get larger (say something the size of Lazarus itself) the
complexity increases, the benefits drop.

> 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.

The complaint is older than Delphi. People raved about Turbo Vision exactly
the same way in the nineties (giving binaries in excess of 100kb !). I think
it is simply a matter of sensitivies adapting slower than technology.

Everybody knows that you can go to far (OpenOffice is a good example on the
one side, OTOH, they are in the unique position to commit gigantic resources
to it due to that nearly everybody uses an office suite)
 
> 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.

fpdoc is IMHO a good thing, that unfortunately is not fully mature. It
really needs a circle of dedicated users that report and submit patches.
 
> I will offer you folks some system.pp units that I'm sure will help the embedded programmers too.

What do you think what sb would do with this? Who will use this? Solutions
without a clear audience that can be a community simply are no good. If you
really want to further the FPC embedded case, snap up some real embedded
developers, and start working to make something that really satisfy demands
of these people. One can shout BLOAT! and throw in some cut down code, but
that will nearly always fails, since effectively nobody is waiting for it.

> 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++?

... What are his needs? Do his needs convergate with FPC's direction? 

> The size stuff - oh no, not this again. Think about memory footprint and not just speed of
> algorithms please. The reason I use Foxit reader instead of Adobe Reader is because it is more
> responsive.

Well, you argue against Lazarus mainly. Where is lazarus and 40 kb of
sysutils related to (I assume more recent) Adobe's or OpenOffice? IMHO there
is no relation whatsoever. 

> 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.

Lazarus is never slow to my taste, except in the linking stage, something
which is not due to bloat. 

> 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

True. Or doing this for entire includefiles. But that is not the abstraction
we are refering too. It is creating abstractions for THE USER, so that he
doesn't have to make the ifdefs (and know every in or out of the problem)

> Other folks agree with me.. many people on the pascal game devel BBS are
> saying Lazarus is becoming huge and slow.  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.

Then explain how it is slow. What exactly is slow, and how slow is slow? Did
you try to profile where it comes from?

Keep in mind that the size matters faq was exactly written against this
gratituous, extremely open ended bloat thinking. Anything can be discussed,
but come with figures, measurements etc, not with a vague feeling, and when
explaination is demanded, don't point to a forum with people with similar
vague feelings.

> Memory is fairly cheap, but with things like VMWARE and Colinux running, my memory fills up darn
> quickly!

I don't know what to say about this. FPC/Lazarus use is a few tens MBs.
VMWare and Colinux eat way more. Why do you blame FPC/Lazarus and not them?

They all just use memory to reach their goals. And FPC/Lazarus are way more
sparingly with resources than the programs you also seem to run.

> 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..

No. It is about not respawning binaries. The word "fast" in fast cgi has
nothing to do with codegenration or footprint. Just with not respawning the
cgi for each and every HTTP request.

And FPC programs have the smallest footprint in the shootout, so what is
this about?

> 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. 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.

Well, this is simply not true. Or only on a so coarse scale that
interpolations are useless.