[fpc-devel] what fpc is good for?

[Marco van de Voort]

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?

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

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.

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

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.

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

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.