[fpc-devel] what fpc is good for?

[Peter Popov]

On Sat, 12 May 2007 15:40:49 -0500, ik <idokan at gmail.com> wrote:

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

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.

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

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

On Sat, 12 May 2007 16:42:43 -0500, Marco van de Voort <marcov at stack.nl>  
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.

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

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

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

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

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

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

> 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

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.

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

> - At some point the amount of compability you can add without effectively
>   emulation e.g. winapi stops. We are building a compiler, not Wine.
> .....
> 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.

True, point taken.

Best regards

Peter