[fpc-devel] what fpc is good for?

[Marco van de Voort]

Peter Popov wrote:

> > 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.
> 
> That is true and is compounded by the fact that there is no ISO standard.  

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

> > victim
> > to its own assumptions because it had to deliver a way smoother  
> > transition, which failed in a still to volatile delphi world.
> 
> I don't know if borland targeted the "recompilation market" or new linux  
> developpers.

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.

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

Yes. The problem in this case is clear. Automated is deprecated and rarely
used functionality. (like e.g. dynamic methods). 
 
> >> 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.
> 
> True, but the delphi crowd is (well, still is) large. So a small fraction  
> is not bad at all.

Keep in mind that the actual project success is not measured in numbers. We
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.