[fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

[印場 乃亜]

Hi,
On 2013/02/28, at 9:16, Simon Kissel <scamp at untergrund.net> wrote:

>> I still believe FPC should leave the "delphi compatible" idea, or
>> clearly state that it means "compatible with Delphi 7 for legacy
>> purposes" and nothing newer. Then innovate the rest of the language on
>> its own in a Pascal-like manner.
> 
> This is a terrible idea. The business advantage of Object Pascal
> has always been the component market, as it reduces development
> costs and time to market. Language compatibility between FPC and
> Delphi results in more components being available on both sides.
> 

I tend to agree.  More specifically, I personally like the idea os having Pascal be its own run-time (or, ahem, compile time) environment, somewhat like Java, more than a bare-bones language like C.  We can have compatibility of built-in functions and syntax, while having a native compile system - which gives us some advantages over both C and Java.

> The Object Pascal language is too fragmented already, and depending
> on your choice of the Delphi/FPC/Oxygene/whatever flavour, you are

Oxygene may be cool and all, but I think it's not really pascal anymore.  Delphi has most of the time used the term "ObjectPascal" hidden in their documentation, and it is clear that it is an evolution of TurboPascal.  Oxygene (and Delphi.net) seem to be much more clean breaks "in the pascal style" to me.  

> locked out of a hell lot of available source code, documentation,
> knowledge and components. Right now pretty much every commercial
> component we have to patch inhouse to be compatibile to FPC.
> 
Yes, on the GUI level, I wish things would be more compatible, not less.  I don't like having to convert forms, etc., much less code.

> (On a side note: It's one of the goals of CrossFPC to make it
> easier for Delphi users and component vendors to also use/support
> the FPC compiler.)
> 
> Sticking to D7 compatibility has been OK for now as this is what
> the masses and component vendors mostly are doing, too, as they
> still have to support D7 users.

I can only trust that this is true. I used to be a Delphi programmer at work, but now it's only for small projects.  (When I do major programming at all, it's in ABAP or sometimes Java).
> 
> We ourselves have to stick with D7 language level because we still
> need CrossKylix for our Linux builds because the FPC compiled code
> is prohibitively slower than Kylix' one.
> 

Heh, I noticed this when porting the FPC run-time-library to VirtualPascal in like... 2001 or so.  It worked, but it was much much slower.  This is something that would be great to fix, but on the other hand, doing it in Pascal Source means there are some limitations.  Still, it would be a great summer of code project.

> FPCs goal to move towards D2009+ language compatibility is a right
> goal - but of course that does not mean that everything needs to be
> copied, but when things on the Delphi side are designed in an OK
> manner, are actively used in the field, and FPC wished to do the same, aiming for compatibility is a good thing. Should FPCs share of the object Pascal ecosystem one day should be *significantly* larger than Delphi's, sooner or later Delphi then will try to pick up FPC's innovations instead.
> 

I wonder if it isn't already.  Simply not for large businesses.  

> In the long run, new object pascal language features optimally
> should be discussed by those active in the field BEFORE they get
> implemented. Sadly right now Embarcadero still are far too arrogant
> and close-minded to understand that FPC actually benefits the
> ecosystem they sell products in.

Well I don't know if I would use the fighting words, since I haven't met them personally.  They probably have mixed feelings about FPC.  On the one hand, we are on their team, and FPC allows them to support iOS, etc. (I am sure they see the advantage in that!).  On the other hand, we are to some extent a competitor as well.  Delphi has certainly become less popular since v6, and I think FPC has probably become more popular.  

Still, I think that if FPC wants to do something that Embarcadero has no interest in, then we can do it our own way.  If they implement a feature in a certain way, we should try to mimic it as closely as possible in order to have the highest code compatibility.  The worse case I have seen right now is where we implement something, and then they come along and implement it differently (ahem.. generics).  They should realize that a lot of people use both products, and all kinds of forums to find answers on.  Then they look up "How to use generics in Pascal", we want there to be one single correct answer.  Not like "Well, if you're using Delphi it will be this way, and if you're using FPC it will be this way", because most of the time, specific products names may not be mentioned.

> All this being said: I know that FPC is not after business goals.

I think FPC is after having as many users as possible and developing a high quality system.  Clearly, the goal is not just "Develop a TP7 clone so we can compile old DOS programs."  (That may be some people's goals, however clearly other people want more).

I am actually impressed with FPC in some ways because while progress has been slow, it has enabled a lot of things over the years.  You can now compile GUI programs on Mac just as easily as on Windows, and there are code generators for the Java VM, etc.  Clearly FPC authors aren't afraid to experiment and try new things.

> But not damaging the ecosystem FPC works in helps everyone using
> Object Pascal, no matter if they are after commercial goals or not.
> 
Not to mention, there are commercial products that become open source (like OnGuard, etc.), as well as hobbyist/research projects that eventually become commercial.  The line between the two is getting thinner all the time, and we would like our code to be as portable as reasonably possible.  Pascal is already a niche compared to Java today, so let's not fragment a niche where we don't have to.

That said, of course we can't predict what the Delphi people will do.  If they suddenly go crazy and start implementing things in a way that doesn't make sense, nothing is to say we have to copy "Delphi 2020" 100%.  

> Cheers,

Thank you,
   Noah Silva
> 
> Simon
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal