[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 co=
ncern
> > 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. Com=
e on now, I've written
> capstring and compactsysutils and many other units to solve many of my pr=
oblems that I complain
> about. The point of the articles are always to point out that FPC isn't t=
his *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 ju=
st like bug reports.
> Without these reports, we all just sit behind our PC's thinking that ther=
e 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 Ja=
va history and why Pascal
> had a big influence on Java:
> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=3DPascal%20is%20An%20Unrecogn=
ized%20Underdog
> =

> Above is one of my optimistic articles and doesn't contain too much pessi=
mism.
> =

> Just because you have seen not too many C programmers float over from C a=
nd 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 powerfu=
l web utilities. Looking
> over my web statistics, I have found quite a few people looking for D lan=
guage information, and they
> bookmark my site since they accidentally stumble upon some of my pages wh=
ich mention D language.
> They realize that pascal seems interesting and more mature than D, and th=
at is a big advantage. D is
> new. Pascal is mature.
> =

> Whenever Linus Torvalds takes cheapshots on the Pascal language, I someti=
mes respond to the articles
> and I get some reasonable C programmers coming in to my site, and they se=
e 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 everyon=
e thought he was
> complimenting pascal. Funny. (Bee, this was the structured vs unstructure=
d 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 i=
s 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 p=
roposal 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 m=
e to get the thoughts down
> on paper and have hundreds of other developers think up solutions based o=
n 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 mainta=
in, too, you know. It is
> hard to maintain the sysutils unit with all the include files and million=
s 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 fi=
nd a way to make it
> less monolithic. Sorry for complaining and not offering any LCL code.  Pu=
tting a complaint out there
> in the air is like putting a bug report out there - I may not have a solu=
tion 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 co=
urse I also wrote some code
> that solved my problem there which is all FPC based, the poor old wiki, f=
orum, and other utilities
> on my site that need updating. Others choose the easy solution and use AS=
P 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 e=
mbedded 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, sinc=
e people could just
> download the compiler.. how hard is that.. but then I went on and wrote o=
ne because I found another
> use for it.  I see a lot of code being pumped out from myself here and th=
is 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 i=
s needed seems to be in the
> GO game that Frank De Groot is working on.  He stated that he may be movi=
ng to C/C++ because delphi
> and FPC don't suit his needs. He could extend FPC, because it is open sou=
rce, 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.. bu=
t realistically sometimes
> programmers choose the easiest option for them. However, since Daniel men=
tioned 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 mo=
re
> 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 t=
ried 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.5G=
hz laptops for sale for
> many years now.. when is the 100.00Ghz one coming out? We have hit a barr=
ier 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 prog=
ramming.. and fast cgi is
> all about building tight code with a small footprint.. but yet whenever s=
omeone mentions a small
> system.pp unit or a small sysutils unit all of a sudden we are offended a=
bout 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 m=
y 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 offe=
r more units for you all in
> order to make things go smoother.  If you read something you don't like o=
n PasWiki, I expect you all
> to analyze me and write about me. Don't remain quiet! Make your own websi=
tes, 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 a=
ny of your comments.

Ok!

Dani=EBl