[fpc-devel] what fpc is good for?

Peter Popov ppopov at tamu.edu
Sat May 12 21:42:21 CEST 2007


On Sat, 12 May 2007 05:04:33 -0500, Michael Van Canneyt  
<michael at freepascal.org> wrote:

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

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



More information about the fpc-devel mailing list