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

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

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

http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Might%20As%20Well%20Use%20Dot%20Net%20In%20Place%20of%20FPC

So a 3 MB lcl/lazarus application is bigger than a .Net framework? I know a lot of computers neither having 1.1, 2.0 or 3.x installed including mine. BTW: Why unstripped? Does he always deliever his applications with debug info included?

Then he continues about server applications like cgi. What the hell has an lcl appliction to do with server applications? A command line hello world is 27k on win32. FPC programs consume less than programs written in any other language:
<http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=0&xmem=1> FPC applications start faster than anything else
<http://shootout.alioth.debian.org/gp4/benchmark.php?test=hello&lang=all> So what is his point about server applications?

Then I stopped reading because the logic is below anything I've seen before.

Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :)

So you found anything usefull in it?

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.

I believe FPC people do really care about speed and size since FPC is a compiler. I think the article isn't merely for FPC, but for Lazarus as well.

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.

Agree. The size problem mostly come from LCL framework. I do understand the problem, but somehow other people are being scared by that. Somehow they forgot that .Net or Java framework requires lot bigger than LCL does.

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

I've been a while no longer visiting the shootout. But.. whooaaaa.... that is indeed VERY IMPRESSIVE!

Watch what happens with those numbers when 2.2 is out.

You guys have done a great job! Thank you and congratulations! :)

There is nothing in this article we can consider, for starters because it does not contain any proposals.

As I said, maybe the article is more suitable for Lazarus people. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Op Sat, 12 May 2007, schreef Bisma Jayadi: There is nothing in this article we can consider, for starters because it does not contain any proposals.

Moreover it lacks a sense for magnitude. What can be saved in the sysutils that is so dreaded by him is 40-80kb. (and then I really remove it. If you use parts it is less) Most of this are simple text msgs btw.

The size behaviour of the VCL is also a known factor, and the LCL is about the same, with a small extra factor because it is portable and multi widget set.

Non trivial Delphi GUI apps also quickly rise to 1.5MB, and nearly any other non-handcoded commercial GUI framework does (even though sometimes hidden in external libraries)

However the biggest hint that it is all a bit exaggerated, straight from the size matters faq btw, is the fact that there hardly any cut down RTLs. If it is all that bad, surely sb would have stepped up.

I think the big mistake comes in the third paragraph. FPC HAS been set up mainly as an application compiler. From the start, because TP and Delphi are. However this focus is relatively mild. (as demonstrated by spinning off Lazarus in a separate project).

The author also seems to have a grudge about binary sizes, but fails to explain what exactly his problem is with binary sizes in the context he would like FPC to go.

P.s. I also don't get the "64-bit" gaming speed remark. What does a game do with 64-bit? Load 4 GB of textures on startup?

Op Sat, 12 May 2007, schreef Marco van de Voort:

Games will be among the first end user applications that really need > 4GB. Commercial games currently released sometimes need 2 GB, it is a matter of time until it increases beyond 3GB, which is the limit for 32-bit systems.

However, here the point is more moot than anywhere else, who cares about a few mb of exe for a game that requires gigabytes of memory and is often shipped on a 9GB dvd?! :)

And needless, to say, FPC is very well prepared for 64-bit.

Daniël

One of the things I sometimes wonder about too is how far optimizations are, most notably on non-x86 (and that includes _64). Maybe make a wiki page out of it (implemented and to-implement?)

Also instruction scheduling remains important, because in this weeks (german) C'T I saw Intel is also preparing embedded in-order x86 CPU's. (and at work I use C7's).

FPC as well as gcc are worse on non x86 architectures, however, fpc performs usually better in relation.

Also instruction scheduling remains important, because in this weeks (german) C'T I saw Intel is also preparing embedded in-order x86 CPU's. (and at work I use C7's).

The problem of instruction scheduling is that it is really CPU specific. That's one of the reasons why the P4 lost performance wise: Athlon and Core/Pentium M perform well with blended code, P4 didn't.

Bisma Jayadi wrote

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

Yes, but the language used puts off some people.

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 (I'll leave the matter of whether his concerns are justified up to others to comment on). This is OK, but flame wars have been started on less strongly formulated opinions. Even when it is expressly stated that the opinions are put in an exaggerated form, as he did at the end of the page.

If you start with an exaggerated opionion, you can expect exaggerated reactions.

It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise.

Michael.

Bisma Jayadi wrote

Nicely put. ;) I've found it has good points on some arguments. It's good to be considered. :)

Everybody is entitled to their opinion. I am allowed mine and totally disagree with his statement about GUI's not being used on any other platform than Windows. And that FPC and Lazarus cannot be used for decent GUI applications.

Our development team at Master Maths are busy rewritting our 3rd major version of our flagship product using FPC and Lazarus. Been working on it for over 1.5 years now and it isn't a small 'toy' project! Also it has to be cross platform (Linux and Windows) so Delphi could not be used! Our product consists of 4 applications all GUI based, talking to a backend Firebird RDMS. The product is a CBT system with Centre Admin side and Accounting module and the content it displays to learners are being designed using Adobe (Macromedia) Flash and has a size of around 7+Gig covering school grades from 1 though 12. We also have authors busy with the Science modules now.

Our product is being used by 200+ franchisees and a few schools. Our current v2 system can only run on Windows and considering that every centre has 25+ computers, that's a lot of Micro$oft tax that they have to pay. Also they need a MS server license which adds a lot more to the cost.

We are in the process of switching all those 200+ centres to Linux which will give them a significant money saving. No more costs for server software, licensing, upgrades, etc... All this made possible by using FPC and Lazarus - and all GUI based applications.

Our product can also be used as a 'distance learning' product, where students can purchase a Maths Grade CD/DVD licensed for 1 year. They can then use that CD at home, be it on a Windows or Linux PC. Again a GUI only product. Mouse clicks are easier that command line interfaces!

We are just one such South African company - there are many more. South African is a big sponsor of Open Source software and the Linux platform.

Just my 2c worth...

Regards,
- Graeme -

There is nothing in this article we can consider, for starters because it does not contain any proposals.

It even tries to give directions on how to and how to not use a tool. Normally a tool proves itself usefull by being usefull in some way for someone. Now we got a ultraflexible, even changeable and adoptable tool. So why do we sit down and cry about the tool and give directions what to do with it and what not. Is it too expensive ? Can't we change it and make everything better what we want ? Or do we want that the tool magically adopt to our wishes without further work, even if that is not that what the tool constructors intended ?

"Everyone is able or limited to see only what he can imagine."

So - What is FPC good for?

After reading that i just have to state my opinion too by providing a so called "success story".

I program since i am 10 Years old - now i am 33 - so i have seen and tried many different things.

I hacked firmware in assembler for microcontrollers - => 2 Weeks for 1000 Lines of Code tested, understood and working. I programmed firmware in C for microcontrolers used on hundreds of Devices. => 1 Week for 1000 Lines of Code tested, understood and working.

But for my "hobbies" i always programmed in Pascal. And on an good day i program 1000 Lines of code understood, tested and working in
just 1 Day.

So after studying informatics me and a colleague made the hobby a profession.
We develop programs, projects and solutions WE consider attractive using delphi and freepascal. Where the amount of freepascal solutions is 50% and rising.

So what do we do with it? => Everything that is imaginable. Server applications on Linux using NPTL and servicing 1000 Clients simultanousely.
Embedded solutions, databaseapplications and GUI Applications, Middleware.
(We run a carrier grade Billing Solution for a Cable Net VOIP/SIP Provider here in Austria,
using Freepascal, ZEOS, and PostgreSQL)

So what is FPC good for ?

-> Maybe to make a big bunch of money using it. (we do) -> Learn programming - look as deep into the sources as you like, even the compiler.
-> Program a Scene Demo in OpenGL, make a Game, or write a "Delphi Killer" like Lazarus.
-> Waste your time with Web Applications ... :-) (just to make some emotions too)
-> It enables that our firm with 4-5 Programmers sucessfully competes with firms employed
10-20 programmers.

*) Object Pascal is a great Language allowing to make readable, understandable,
small, fast and efficient code, if you provide the skills to use it.

*) Freepascal is (IMHO) after the GNU C++ environment the most flexible free compiler
providing a useful and professional framework, for a variety of architectures.

Don't ever press FPC or Lazarus in a scheme, as it clearly depends on your skills,
what you make out of it. It is even suitable to make an OS.

I am humble, and gratefull that FPC is here allowing me to make my hobby my profession,
to earn money and to spend more time with my family - and that there is a community
which answer questions and helps on problems - as no one is able to do eveything alone.

That is what is FPC good for !

helmut

Non trivial Delphi GUI apps also quickly rise to 1.5MB

lazarus may produce apps that are size comparable with those from the recent versions of delphi but those are also megabloat compared to those produced by the older versions of delphi.

I agree with Graeme. There are professional developers out here who want a decent cross platform product and who don't like the C/++/#/Java/.net/etcetcetc because of various reasons. My own reasons are that I find C(like) languages to be semantically weak and encouraging of bad programmer behaviour. I don't have time for dealing with that sort of inefficiency, so I need a more professional option in a language. Pascal(etc) provides that, and since Delphi isn't really broadly multiplatform (even though it is a terrific piece of work in it's own right), I am left in a pickle... or at least, I would be, except that FPC has provided the solution. So all these folks can have their scathing opinions of it. Indeed, this list, and all Pascal lists seem to be a place where people like to rock up an try to justify their own attractions to C(like) languages. I often wonder whom they are trying to convince, since the folks on a list like this one have probably already asked themselves those questions and moved on in favour of Pascal(like) languages.

Conversely, you don't often see Pascal people baiting list members on C language lists (not that I subscribe to too many of those - although I am familiar with C(et al) and do it use from time to time (horses for courses).

Anyway. I would like to say the all supporters of the FPC community - good stuff! Thank you thank you thank you. I have endless time and respect for you all. Keep it up! I don't have time for arguing the toss over C(like) languages and the claims of C-like superiority. I just need to get the job done and I know the right platform for it. Simple really. Industrial requirements require an industrial solution, and that's where we again to you all for a great project!

Cheers,
Mark.

> Nicely put. ;) I've found it has good points on some arguments. It's good to > be considered. :) Yes, but the language used puts off some people.

Yup. Sometimes Lars sounds to aggresive. :-D

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 (I'll leave the matter of whether his concerns are justified up to others to comment on).

Yes, like the rest of us here, he's also a big fan of FPC. He even using FPC and PWU professionally, he makes his living over FPC. So, he's not the enemy! He knows all the best of FPC and Lazarus because he uses them on daily basis. PWU is one of his contribution back to the FPC community.

If you start with an exaggerated opionion, you can expect exaggerated reactions.

Yes. Maybe it's my fault if everybody then looks at him in a negative way because of his own article. But, he published that article in his public paswiki, somebody else will find it anyway, sooner or later.

It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise.

Anyway, it did happened to me as well long time ago. ;) Programming language community is indeed a very sensitive community, we must write in a very polite manner if we want to criticize anything about the language. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

> it does not contain any proposals. "Everyone is able or limited to see only what he can imagine."

Helmut, till now, in this discussion I like your answer the best.

megabloat? A million times larger?

Small addition:
For me a strong reason for both FPC and Delphi compared to the others is that single exe deployment is still so doable.

For a lot of small stuff that I only deliver once, I don't want to set up a complicated deployment system, or argue with external IT departments about the addition of runtime libraries.

It is always useful to listen to others, regardless of the language used. The man has some valid points.

It only goes to demonstrate that to be truly critical and constructive at the same time is by no means an easy exercise.

Completely true.

Since this article seems to have stirred some debate I will take the libery to comment some aspects of it as well as express some of my personal opinions. Now, before anyone reads further, I want to state two things: One, I have deep admiration for the FPC developpers who have created a fine compiler from scratch. Two, the next few paragraphs are written from the view point of a long-time delphi/win32 developper, so don't take them personally.

Some comments about the article:

1. Linux is indeed used mostly for server apps. This is a fact. One can speculate until kingdom come why this is the case. My personal opinion is that Linux is simply a shitty desktop platform:
i. There is lack of a standard graphical api (or "toolkit"). For example, the idiots from throlltech constantly change the entire framework. (Qt2 is different form Qt3, which is different from Qt4. They are not semantically compatible. Attempts to run binary Qt2 libraries on newer distributions cause bizarre problems such as memory clashed with libstdc++, for example). Regardless of the toolkit, one cannot expect simple things, such as an X toolwindow hint to produce consistent results. No matter what, a win32 program that ran on 95 and 3.51 will still look OK today.
ii. Linux prevents people from distributing binary applications: The gcc /kernel people constantly change things. So, one cannot develop and forget. You are either forced to release the source code so that the app you are developping can be recompiled after the newest kernal/libc/++ change. The alternative is to constantly mainatin a once developped program and provide ten thousand binary variants for ten thousand distributions. And update the binary of your app every month. The later option is generally available only to large commercial organizations. Again, a win32 program that ran on 95 and 3.51 will still run and look OK today.

2. With respect to graphical applications, the man completely wrong by stating that:

"FPC is a C++/C/D killer. Not a Delphi killer or a Visual Basic killer."

It is plain clear that neither FPC will, nor Kylix did convert a s single, mildcore vi/gc fan to object pascal. There is absolutely no conceivable way this will happen. Those who use vi and fpc, please raise your hands :-) This is actually the main reason Kylix failed: they targeted linux gui developpers. I encourage everyone to read this enlightning analysis: http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html

3. As a delphi developper I have the following issues when considering FPC (I hope the following is not taken badly, I am just stating facts, as I see them):
i. Too many bugs in any official release. This is unavoidable, considering the many platforms and targets supported. But it is a fact. ii. In any stable release, there are always some incompatibilities with Delphi. Which means that Delphi developpers will have to put an extra effort (in the form of $IFDEFs) to make their code compatible. In that respect the lack of an "Object Pascal standard" in the form of some ISO specifications is partially to blame. Given the fact that Linux IS NOT a Desktop platform, this simply means that object pascal people will keep on developping for Delphi/win32. It is a catch 22: Until borland delivers a quality multiplatform tool, no delphi developpers will do linux (exceptions do not change the rule). And until there is no serious demand for linux GUI apps there will be no motivation for borland to develop a stable, reliable, bugfree, multiplatform compiler+VCL. When I say demand for GUIs, I mean a secretary wishing to play her favourite solitaire game (one of the many hundreds of office style games, which were released for win95 and whose developpers are certainly doing something else today), or a college student using his/her favourite graphical plotter app for win32, or a more traditional type, who prefers ICQ2003b istead of the newer versions, etc. For example, my favourite browser is Opera. On win32 it looks and runs fine. On slackware 10.1 it looks and runs fine. On debian it hardly runs and looks like a crossover between a frog and a polar bear. My office computer runs debian and I am not the admin, so I cannot do anything.

To summarize, if there is any chance for a large number of developpers adopting FPC, they will have to come from the delphi crowd in the form of people willing to do a little extra work of compiling their existing code with FPC. This is the essence of Simon Kissel's proposal to Borland for cross-kylix compiler. I sincerely hope that one day this will become a reality with FPC.

A final remark: the vast majority of pascal users use Delphi. So if fpc is to attract a lot of them, compatibility with delphi must be 100%. If there is only one incompatibility with a known workaround, a delphi developpers will live with it. If there is a single major thing, one can try to fix it himself. But if there are 10 or 20 small things then most delphi users will give up supporting multplaform/fpc targets. Unless your boss pays you to port delphi apps to FPC. Now, I can understand that the FPC team has put a lot of effort in making a compiler from scratch and it is natutal to do things differently. But it will be a big boost for FPC if delphi compatibility stops being and issue.

Best regards

Peter Popov

Hi,

Ok, you dragged me into responding this subject as well :) While it might sound as such, this is not Windows vs Linux fight, only a point of view for an ex Delphi developer, and a 5 years of Linux users (as only OS).

Ammm.. I'm a Linux user, so let me give you my point of view: Microsoft on any given new version of Windows *changes* API, changes libraries and technology, making even newer (the previous version was the first to have it) technology obsolete on a new version of an OS or a program. As example take a look at GDI+ (if I remember the name correctly).

I do not know many people that changes their kernel and libc once every new version. In fact while Windows release time is one in 5 years, on the Linux world it is every 6 months ! So as long as you keep yourself with what arrives with specific distribution, you will end up having problems, but note, that there are development versions of Windows, that companies can change the OS as well, so you will also require to change your tools for every such version, and also for every new version of Windows (because the kernel is changes ...).

If you are looking for a standard way of creating GUI apps with something that never changes, try to use xlib and xtoolkit. As long as the X11 protocol is in use, they never changes :) But as you can see, you are loosing a lot of features that might be added that way. For the QT from Trolltech, while I do have some issues with them, they do try and make support also for the GTK library in the area of styling.

How many programs under Windows do you know that the GUI was designed regardless of the GUI toolkit that comes with Windows ? Even Microsoft does this with their Office suites... Every version of the Office suite, gives you a different look and feel. Take a look at Microsoft Office 2007, it's so different then anything else that most people just don't understand how to use it. Or you can take the IE7 vs IE65432 ...

As I said above, the ABI changes from version to version on ANY OS even Windows... But While Windows create new version every 5 years, Linux releases more often, but most distributions releases new version every 6 months ...

There is a quotation that say "the price of freedom is endless violence". There are two point of view for things. Windows have both ways (SP can change the ABI/API as well, as SP2 made for Windows XP). And on Linux, you can have them both, but the easier way is just to deploy the code for every version, or to point things for specific version/distribution.

I believe that Pascal as a language is better the C, C++,D and Java. I do not respect VB, and I can not call it a programming language :)

I'm raising my hand (I'm using VIM rather then VI), but please excuse me for the smell, it's the beginning of summer here ;) Oh, and I know few others that uses vi/m with FPC as well...

You can correct me if I wrong, but doesn't Delphi comes with bugs as well ?! If I remember correctly, Borland releases SP on their own. In fact, even Vista did not arrives fully beaked, and as soon as you installed it, you needed to installed "few" fixes... Now sure we all wish to have bug free product, but unless you are going to help the bug solving process, please accept that nothing is 100% bug free :(

I'm using Opera as well, on my Ubuntu, and it looks very cool, specially with the skin I chosen :)

Linux is a desktop and server and live cd and OS ! you can do what you wish with Linux, unlike Windows, that arrives with what Microsoft believe you should have, and then you need to start finding other issues, on Linux you have distributions that gives you different things according to what the distribution is set to give.

The running of Windows as administrator is a security risk, and you keep on paying on that by having spyware that effect the entire computer, viruses that effect everything, and of curse your computer becomes a zombie to an army of more zombies that are controlled by spammers. If you have used it without any administration and system privileges, it would effect only your user ! But then you can not do much with Windows as well ...

Now you can say "I want Microsoft office", or you can say "I want a program to create presentation, a word processor, spreadsheet, or Instant message using the ICQ protocol", you can choose what you want, a specific product, or a list of programs that does this things...

I can create GUI apps with Linux, and there is a demand for it ! While people as myself that likes to use the keyboard more then the mouse, and find out that it does the job faster then the mouse, uses the commandline, we still using a GUI environment, and GUI programs, and always try to make things better !

Just that you'll know, Hollywood, is using Linux for it's GUI features to create movies, animations etc... And there are more and more games and game engines etc.. It's just that people needs to open their mind to something they still do not know, or it's different then what the used to.

I agree, but are you willing to help the team and add features that are missing in your opinion ? If you are asking "why me ?", well that's how open source works, everyone develop an answer to their own problem, and hops it will help others as well :)

Best regards Peter Popov

Ido

A.s. I already deleted it, but quite some older apps break on Vista now. Including e.g. Delphi 7. MS is also deviating from the compat path. Unfortunately.

i. Too many bugs in any official release. This is unavoidable, considering the many platforms and targets supported. But it is a fact.

This is a bit vague. I assume you mean bugs of the blocking kind. Do you have examples?

Yes. Failure of Delphi users to have any consensus about what is compiler behaviour, and what is language behaviour. Every bit of behaviour that Delphi exposes is considered gospel.

I've some doubts about that. One possibly end up in the same catch-22 we somewhat have been in TP/BP times. In the Turbo Pascal NG, there was sb declaring for about a decade that FPC was close, but not there yet, because it could not compile his TP code full of dosisms and 16-bit asm.

IMHO this is also why Kylix failed. It was geared too much to float on a Linux-on-desktop hype, hoping to force a lot of Delphi apps to be recompiled on Linux because it-is-so-easy. It failed. Borland management probably assumed that the "recompilation" market was larger than the "invest in new linux products" markets. However the "recompilation" market fell victim to its own assumptions because it had to deliver a way smoother transition, which failed in a still to volatile delphi world.

Compability is good, but should be a enabling factor to do stuff with FPC/Lazarus, not the end target for blind recompilation itself. Because then it will be just-not-good-enough forever. One can also see this currently with FPC. Major Delphi component builders start using FPC/Lazarus. They want to do things, and their customers are doing things, while FPC/Lazarus is not really registering en masse on

A final remark: the vast majority of pascal users use Delphi. So if fpc is to attract a lot of them, compatibility with delphi must be 100%.

These kinds of claims always promise heaps of users, but there are several problems with it:

- Only a fraction of users will defect to run a clone. Most will either move on to the next big thing (Java/.NET) that has a lot of publicity, or stay as long as possible with Delphi. This also because they will never leave Delphi in the first place till it is really dying (because of its OS, or the toolchain competition)
- The compability is never enough. Compromises (e.g. for portability) are not accepted, because their goal is only to get the code running, regardless of its quality or portability aspects. The "big break" is always another year away, when the compability is another magnitude bigger.
- At some point the amount of compability you can add without effectively emulation e.g. winapi stops. We are building a compiler, not Wine.
- At the same time you are alienating and neglecting your real users that do stuff with FPC.
- At some points the heaps of commercial components are the real limitation, not the compiler.
Porting is hard due to practical concerns relating to their closed source nature.

Also there is another big danger:

Even if bunches of users would convert to recompile their old Delphi stuff with FPC to give it another few years, what does it yield for FPC? These are all people planning to abandon the platform. Do you think they are going to invest majorly?

f there is only one incompatibility with a known workaround, a delphi developpers will live with it. If there is a single major thing, one can try to fix it himself. But if there are 10 or 20 small things then most delphi users will give up supporting multplaform/fpc targets.

How much will they add to FPC/Lazarus if they are not willing to invest that? Of course it is not black and white, but sb must report and fix those 10 or 20 things, (and those are not necessarily the same people).

Somebody working on a project that invests real time in a FPC solution are way more likely to play a part in that, than people looking for a quick recompilation fix.

Every so and so many months, the number of delphi component retailers and people working fulltime with FPC reaches a new level. Also the number of people contributing with FPC increases. Of course these numbers are hard to measure, but having several Borland partners on FPC implementations and even selling them is a strong sign.

Of course we could throw this slow, but steady progress all away and go for a quick fix hoping for large numbers of converts.

I hope to have explained that one must be very careful with compability, specially the "effortless" kind. IMHO the focus must be on a kind of people that are willing to invest in creating FPC apps. Delphi compability is a factor too (due to the heaps of sourcecode it makes accessable), but don't think too much in an utopic "just recompile product" way.

Correct. Well, it certainly sounds like, but it is not. I did not make a single statement regarding which one is better. My claim is that they are different - one is more popular, and I stress "popular", for desktop applications, the other for server ones.

Of course it changes. But the majority of gui applications are compatible with newer versions of windows (up to vista), all the way from 3.51. And the compatibility comes at no cost (in terms of time) to the sysadmin. There are exceptions, mostly confined to system level applications, such as firewalls. This however is natural and cannot be helped on any OS. My only point is: this feature of windows makes it really easy to develop and forget. I am not claiming one is better, the other is not.

I do not know many people that changes their kernel and libc once every new version.

My sysadmin recently changed to 2.6.?? which broke the kylix debugger (2002). As a comparison, bcc 5.0 (1996) runs perfectly fine on xp.

... are you willing to help the team and add features that are missing in your opinion ?

Yes. In particulr, I would like to do something about this item: http://www.freepascal.org/mantis/view.php?id=8783

Marco van de Voort wrote

A.s. I already deleted it, but quite some older apps break on Vista now. Including e.g. Delphi 7. MS is also deviating from the compat path. Unfortunately.

Unfortunately, indeed.

Well, I did not want to put any specific examples which would necessarily be personal and would shift the focus of the discussion. I've mentioned a few later on...

That is true and is compounded by the fact that there is no ISO standard. Furhtermore, delphi users cannot insist that an independent compiler group should do something "their way".

I don't know if borland targeted the "recompilation market" or new linux developpers. If they wanted the recompilation market they should have single sourced the VCL. They should have released a reasonably bug-free multiplatform VCL. They should have priced it much cheaper and integrated the compiler into the win32 ide for cross-compiling and so on. It is actually useful to study why they failed. Kylix is certainly dead, but finding out why will help others... Some interesting views can be found here:

http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html

I agree. Actually, both are important and there should be a reasonable balance. FPC is targeting several different cpu architectures on many different os platforms. This alone is attractive to server side developpers. On the other hand, say any stable fpc release should be able to compile (on win32), without trouble the entire VCL of say, delphi 2-5. Personally for me FPC is extremely attractive for server side development. In the process of porting kylix server applications to FPC I've noticed several things:

- Speed wise, especially floating point operations, applications are generally similar or slightly faster than kylix.
- I've had recurring problems with open arrays on various final releases. Some issues were fixed by the developpers, for other there was no agreement what the language standard should be so I had to make workarounds. Also, it is not clear if functions with open arrays can be exported/imported safely in dlls, as I don't know what is the internal representation of an open array in FPC.
- Static linking requires some minor code modifications in comparison to kylix (they had their internal linker, so things can't be the same)
- Various linking issues on different platforms.
- Minor issues in the FPC RTL force various workarounds. E.g. http://www.freepascal.org/mantis/view.php?id=8578
- Various features that use the internal RTTI of delphi. For example delphi 2 generates useful RTTI for automated methods, Delphi 6 for published method (in conjunction with a weird compiler directive). Clearly this is not a language feature, so one cannot insist the FPC should do things the same way. Unfortunately, currently this is a blocking issue for me.

True, but the delphi crowd is (well, still is) large. So a small fraction is not it is not only about defecting. What if FPC is available as cross-compiler inegrated in Borland's windows IDE? Personally I can see FPC server applications running on a bizarre patform and a client side compiled with delphi.

- The compability is never enough.

Well, as long as there are no blocking features and no necessity for too-many workarounds/$IFDEFs people will accept it. Alternatively, someone should define a language standard.

True, point taken.

Best regards

Peter

It's significance must not be overrated. See the relative incompat of older MSVC++ compilers.

I think so.

If they wanted the recompilation market they should have single sourced the VCL.

I guess that was not possible without compromising their main moneymaker.

They should have released a reasonably bug-free multiplatform VCL. They should have priced it much cheaper and integrated the compiler into the win32 ide for cross-compiling and so on. It is actually useful to study why they failed.

I think that is revisionism ( also a problem in Simon's article). At that time the Linux hype was at its peak, and navigating the dangers of being stoned to death by the Linux opinion makers was a top priority. ALSO crosscompilation maybe. But only crosscompilation was marketing wise not doable I think.

Kylix is certainly dead, but finding out why will help others... Some interesting views can be found here: http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html

I know the article. I've commented extensively on it when it came out in the relevant Borland groups.

developpers. On the other hand, say any stable fpc release should be able to compile (on win32), without trouble the entire VCL of say, delphi 2-5.

I don't see why that is a focus point. It's a nice testsuite, but until it is free, there is no real benefit in it. Specially since the VCL-RTL separation is not complete, and neither is the compiler - RTL separation.

- I've had recurring problems with open arrays on various final releases. Some issues were fixed by the developpers, for other there was no agreement what the language standard should be so I had to make workarounds

Yes. I assume that was the cdecl one? Since nearly any standard doesn't cover much details about external linking, and general link and calling conventions issues, I doubt a language standard would make this go away.

THe other one was fixed.

Also, it is not clear if functions with open arrays can be exported/imported safely in dlls, as I don't know what is the internal representation of an open array in FPC.

I'd guess it is safe for fully static types, and not safe for types allocating memory. So ansistrings and dynarrays, no.

- Static linking requires some minor code modifications in comparison to kylix (they had their internal linker, so things can't be the same)

(some were fixed for CrossFPC)

- Minor issues in the FPC RTL force various workarounds. E.g. http://www.freepascal.org/mantis/view.php?id=8578

This is unavoidable, without freezing the scope of the project to produce a minimal clone.

I do a lot of porting (Jcl, Indy, ICS, Decal among others), and while such issues are constantly discovered and fixed, the ones that stay like this are extremely rare.

Yes. The problem in this case is clear. Automated is deprecated and rarely used functionality. (like e.g. dynamic methods).

don't get anything per download, we are "paid" in project activity and bugreports and patches.

A higher focus on compability would hurt badly in other area's that do deliver "pay". And since the bulk of the users you pull in with such an extreme (and costly) focus on compat is of the low pay kind..

Besides it is not only about defecting. What if FPC is available as cross-compiler inegrated in Borland's windows IDE?

Do you ever see that happen in a scale that matters?

Personally I can see FPC server applications running on a bizarre patform and a client side compiled with delphi.

Oh, sure. But I don't think that that will shift the balance in any way.

> - The compability is never enough. Well, as long as there are no blocking features and no necessity for too-many workarounds/$IFDEFs people will accept it.

Talking in extremes is too easy here. My point is that everybody accepts something that is perfect. But how close to perfect is perfect? Specially when the bulk of the people are only trying to get a free ride (get their product compiled one or two years longer, or a free other OS port).

Keep in mind that we already were in such a spot with TP/BP. No mass migration started because it was all not ready when BP was somewhat alive, and when the extinction started, most jumped ship to Delphi or VB, and only tried to cheaply get their old projects (in which they didn't invest anymore) running.

This is also why I wish Delphi/native a long and prosperous life. We now also get a certain percentage of users, and a fairly skilled and willing to invest kind. If Delphi would die, this would end, and the wave of publicity that the demise would cause would only yield a larger percentage doing superficial and dumb attempts at braindead recompilation (which give you a bad name for years), hardly yielding any new users in the longer term.

Alternatively, someone should define a language standard.

Actually I don't think it would change much. Simply because the existing codebases on Delphi wouldn't change by it. It would be like the existing pascal standards and the object pascal draft standard.

Moreover, considering the stuff you describe (shared linking, external linking, calling conventions, OS specific modifiers like automated), this is generally not the stuff guaranteed ins standards.

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.

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)

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.

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

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.

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.

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. The reason I use Foxit reader instead of Adobe Reader is because it is more responsive. 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. 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. 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.

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

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

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.

Unconditional Developer Love,
Lars

Op Sat, 12 May 2007, schreef L:

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.

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.

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

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 :)

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

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.

Ok!

Daniël

Another idea is to avoid overlap of features like
- *CriticalSection functions vs SyncObjs
- TPairSplitter vs TSplitter
- TNoteBook vs TTabControl

of course this would be provided as packages for who needs

Luiz

Graeme Geldenhuys wrote

Everybody is entitled to their opinion. I am allowed mine and totally disagree with his statement about GUI's not being used on any other platform than Windows. And that FPC and Lazarus cannot be used for decent GUI applications.

I disagree too. And by the way, Lazarus cross-platform applications pay my rent, and my vacations =) And that certainly metters a lot for me.

I also just bougth a MacBook with the purpose of helping a brazilian enterprise port a windows software to Mac OS X.

None of this would be possible if fpc and lazarus weren´t good cross-platform tools.

Delphi backwards compat.

- TPairSplitter vs TSplitter

Lazarus internal (with previous versions) backwards compat

- TNoteBook vs TTabControl

Afaik Laz internal too.

of course this would be provided as packages for who needs

This kind of stuff is easily said, but in practice if you change it, some other compability or consistency camp starts complaining. There is a reason for nearly every construct.

Should not this be in fpc side ? (Is not gui related and cross-platform widgetsets can have problems implementing it).

Ok.

Luiz

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 ?

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.

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)

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?

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

Aaaargggh - a knife through my heart :-)

fpdoc not mature ?
What about the 1700 pages of rtl/fcl documentation it creates ? I'd rather hope that this is somewhat mature ? I'm not even talking about the LCL, which will probably be a lot more than 1700 pages when printed...

It does what it was designed to do. It's not perfect, and there are still some improvements that can be made, but it has steadily improved since day 1. And will continue to improve in the future.

But alas, as so often, we loose the continuous struggle with time.

(All mortals of course do, in the end...)

Michael.

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

This one is funny! :-)

I have used Delphi since D4 up till D7 in commercial development and switched to FPC and Lazarus about 2 years ago. I think Delphi has a great IDE, but in the last few releases it became bloatware!

We still need to maintain some Delphi based code and use Delphi 7 for that. Now on the exact same PC, Delphi 7 takes 25 seconds to start up. Lazarus takes a mere 2 seconds. Lazarus is still far from being slow an non-responsive!!!

Oh btw my PC is a Intel P4 2.4Mhz with 512Mb RAM.

Nobody disputes the size of docs. I was more talking about not generating a Windows helpformat (on my todo for years), the array [] of ansistring at

http://www.freepascal.org/docs-html/rtl/unix/fpexecle.html

not to speak of

http://www.freepascal.org/docs-html/rtl/sysutils/format.html

Which was the exactly what I meant to express.. Needs more continuous struggle from people with a direct interest to not let the improvement rate decrease.

That was also not what I wanted to hint at, just that if fpdoc can generate such an amount of pages from relatively difficult sources, it seems to me that this is not alpha-quality anymore...

I was more talking about not generating a Windows helpformat (on my todo for years), the array [] of ansistring at

RTF is on the todo list and nearly done.
.hlp or .chm is then a matter of adding some footnotes on the right places, and running the windows help compiler.

I'll have a not be hard to fix.

Agreed 100% !

Not all at once, please. There is plenty of room for enthousiasts ;-)

Michael.

Michael, can you (or I) create a wiki page or even a text document in the FPC repository with a list of what are outstanding or incomplete features. I have a few items myself. I guess the wiki might be a good place, so we can mark specific features as being worked on as to not duplicate efforts. Or should we use Mantis for this?

I have been working on the 'lazde' (Lazarus document editor) app as well to implement a few missing features.

Please use Mantis. I have emotional issues with Wiki's ;-)

I just fixed the bugs Marco mentioned, so don't enter those ;-)

I have been working on the 'lazde' (Lazarus document editor) app as well to implement a few missing features.

Great !
It's come a long way since my initial version, but the way to go is probably even longer. All steps on this way are welcome :-)

Michael.

Graeme Geldenhuys wrote

We still need to maintain some Delphi based code and use Delphi 7 for that. Now on the exact same PC, Delphi 7 takes 25 seconds to start up. Lazarus takes a mere 2 seconds. Lazarus is still far from being slow an non-responsive!!!

I guess that's Delphi 7 Enterprise with loading all possible components at startup ? So not entirely fair.

( Hear me: defending Delphi?? ;-) )

Micha

Op Sun, 13 May 2007, schreef Peter Popov:

Can take a look at the ncgrtti unit in the compiler source code and see if you understand it? This RTTI generation would need to be added here, generating RTTI itself is easy, but you need to know what to generate.

Daniël

hehe... Your guess was correct. My Lazarus also has quite a few extra component suites installed. ;-)

Yes, testsuite only.

For which I am thankful.

I'd guess it is safe for fully static types, and not safe for types allocating memory. So ansistrings and dynarrays, no.

It would be helpful if there is a clear statement how FPC processes open arrays at assembly level.

Yes. The problem in this case is clear. Automated is deprecated and rarely used functionality. (like e.g. dynamic methods).

Let me know if I can help in any way with automation RTTI compatibility? If this feature is implemented (just the RTTI, nothing further) I can release a small unit which implements remote method/properties calls over a TCP connection. Not exactly corba, but still useful.

Peter

http://shootout.alioth.debian.org

Regex program is still missing. It was discussed some time ago.

Did any licensing competent FreePascal developer try to contact http://www.regexpstudio.com/TRegExpr/TRegExpr.html about self-proclaimed "TRegExpr - Freeware Delphi Regular Expressions Library... The library source code is compatible with Delphi 2-7, Borland C++ Builder 3-6, Kylix, FreePascal"?

It worked under FPC with the benchmark some time ago, it would provide the last program for "shootout" if included in FPC.

What is wrong with the regular expression support in Free Pascal ? Is it not powerful enough for the shootout benchmark ?

Michael.

Op Mon, 14 May 2007, schreef Michael Van Canneyt:

What is wrong with the regular expression support in Free Pascal ? Is it not powerful enough for the shootout benchmark ?

Yes, it cannot handle the regular expression the benchmark uses.

Daniël

> What is wrong with the regular expression support in Free Pascal ? > Is it not powerful enough for the shootout benchmark ? Yes, it cannot handle the regular expression the benchmark uses. DaniКl

And the engine (with the word "free") I referenced works.

I bet there are other free pascal engines, and that it's possible to write a crude engine fast, but this one looks really good and names itself "free".

Yeah ok, It's not really FPC related but the source docs are from the FPC community.

http://www.screamingduck.com/Article.php?ArticleID=41&Show=ABCE

I may get to the other parts in time.