[fpc-devel] what fpc is good for?
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
> 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.
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
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
"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:
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
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
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.
More information about the fpc-devel