[continued from fpc-pascal]

Graeme Geldenhuys wrote

And yet Embarcadero is ok with breaking compatibility

Keep in mind that when Embarcadero breaks compatibility and the new version is a hit, it's a good way to encourage customers to upgrade. In our case it's primarily a good way to get complaints :)

Jonas

Jonas Maebe wrote

is a hit, it's a good way to encourage customers to upgrade. In our case it's primarily a good way to get complaints :)

The big difference you are overlooking is that in a open-source environment you get to see what is happening before a release is out. You get a changes to prepare your code while the changes are being implemented. If you were early enough you could maybe even have contributed in the thought process for the code-breaking changes.

I have been following this same path with fpGUI and our company projects. As soon as FPC announces a RC or Beta, then I start looking at what needs to change in our projects to stay compatible when the new release is finally out. Lately I have been following trunk too.

In a closed source environment the end-user is left in the dark (not even a detailed roadmap from Embarcadero) and only see what changed after you purchased the new version.

spir wrote

I'm surprised of this, fpc still systematically trying to follow Delphi, after so many years.

In some ways we follow Delphi (mostly language features), in other ways Delphi follows us (e.g. platform support). Delphi and FPC are part of the same ecosystem. We're not trying to replace Delphi, show them the one true way, or anything like that.

I can understand that at the beginning the fpc team needed to mostly comply with Delphi, as de facto object pascal standard.

You're saying that as if a standard is a bad thing. Standards, de fact or otherwise, are good. It helps with reusing knowledge, sharing code and avoiding a proliferation of ad hoc features that result in a mess that can no longer be unentangled.

As an aside, in the early days we were in fact a lot less strict in following Borland than we are today.

But then, fpc could live its own life, possibly taking the best of Delphi's innovations, but not having as main goal to be always running after it.

The main goal is implementing stuff we care about. If Delphi already implemented something similar, then unless there is an extremely good reason for doing things differently, it is stupid to implement it in a different way simply because "you don't want to follow Delphi":
* you waste time reinventing the wheel
* you waste time adding support for the Delphi-compatible way later on
* you waste other people's time because they have to relearn the feature and/or maintain two different code bases
* you risk making mistakes in the design that Borland avoided (as I've mentioned many times already on the mailing list, we've had to revert many "we do this different than Borland because they implemented useless and stupid limitations" language features over the years because our "improved" version suffered from flaws we didn't realise at first)

so why not having already made the step of declaring fpc a (object) Pascal dialect of its own?

We have. It's called ObjFPC mode. And another one is called Objective-Pascal mode. But that's not the point. Our main goal is not to design languages. Our main goal is to let people program on Object Pascal on any platform they want (well: on any platform that people add and maintain support for in FPC).

Jonas

Michael Van Canneyt wrote

Converting 2 million lines because they broke compatibility is NOT funny, and will - in all likelihood - cost us a lot of money.

Rightly so, but why? Because you got no prior warning of the scale of the change, no end-user input was sought, no time to prepare. So you were forced to follow the "wait and see what we get on release day" approach - this is terrible!.

This is exactly why I think open-source software is so great. The community gets a chance to be involved, and you can see long before what is changing and get prepared as the changes progress. And with the community involvement (more eyes on the code), better designs could be discussed (like in the case of FPC's Unicode support compared to Delphi's).

So even though there might be a code-breaking change - the effect should never be has harsh as what you get from Embarcadero. You would have much longer to prepare your code for the change. So in the end the code-breaking change (to currently maintained code) is not so bad.

The FPC Unicode implementation is such an example. It's not 100% Delphi compatible, because FPC came up with a better design - the covers more platforms and solutions. So non-compatibility is justified. I just ask that other code changes be judged with the same open minded approach.

Hello,

I would like to point out that the original message is completely missguided, because FPC supports various Pascal dialects using the {$mode } directives, therefore it is possible to support Delphi mode, FPC mode, WhateverYouInvented mode, etc.

There is no reason to drop any mode if you can support multiple ones.

So the original suggestion doesn't make sense. If you don't like
{$mode Delphi}, don't use it, use another mode, or create your own.

This brings me to another question. Don't you guys feel that FPC is good enough to stand on it's own feet. After all, our company switched to FPC 4-5 years ago without any regrets. We don't need Delphi to write our commercial software, hence we don't need Delphi compatibility as such. FPC is brilliant, and evolves faster that Delphi does.

So there is NO real benefit in trying to keep our company software or fpGUI compatible with two compilers (essentially to products). FPC does everything we want in a commercial environment. Good database support, good web support, good internet protocol support, fantastic FCL, cross-platform RTL etc.

So what's the benefit of Delphi compatibility? To keep those developers that can't make up there minds if they want to switch or not happy? They will probably will never contribute to FPC either, so what's the point in trying to please them the whole time. And it's more work for you guys.

Graeme Geldenhuys wrote

This brings me to another question. Don't you guys feel that FPC is good enough to stand on it's own feet.

It has nothing to do with being good enough or not. Please read the mail you replied to again (second paragraph I wrote).

So what's the benefit of Delphi compatibility?

See the bullet list in the mail you replied to (fourth paragraph I wrote).

To keep those developers that can't make up there minds if they want to switch or not happy? They will probably will never contribute to FPC either, so what's the point in trying to please them the whole time.

As I said in the mail you replied to (first paragraph I wrote): FPC and Delphi are part of the same ecosystem. If you keep looking at it as if it is about "us versus them", you will probably remain unhappy forever with how FPC evolves, because it will always seem as if we are doing various things out of servitude to Embarcadero and its horde of evil Delphi users.

Jonas

On 4 June 2010 19:04, Felipe Monteiro de Carvalho

So the original suggestion doesn't make sense. If you don't like {$mode Delphi}, don't use it, use another mode, or create your own.

That only affects language features doesn't it? What about classes in the RTL, eg: the workings of TWriter, TComponent etc. Changing the compiler mode will not change there interface of behaviour would it?

Maybe you haven't noticed, but neither Borland, CodeGear or now Embarcadero gives a toss about Free Pascal. They see it as a competitive compiler, hence the reason they are getting there act together now, and implementing missing feature. Also why they are implementing their own versions of a cross-platform compiler, instead of working with Free Pascal and reusing it for non-Windows platforms.

There is *no* relationship between Embarcadero and Free Pascal. The FPC core team might think otherwise, but they are the only ones that think that.

If there was any relationship between the two compilers, then Embarcadero (f**k I hate that long name) could very easily have implemented Generics in the syntax FPC came up with first, but no, they had to break the compatibility - for their gain, so FPC needs to play catch-up again or be told they are incompatible. Generics is just one such example.

You are living a dream if you think they care about FPC, so why the hell care about them. FPC is a good product, you don't need Delphi (or delphi compatibility) when you have FPC.

In our previous episode, Graeme Geldenhuys said:

As far as I know it always has....

I don't think that the extent to which Embarcadero cares or doesn't care about FPC is relevant. FPC and Delphi are part of the same ecosystem by virtue of them supporting virtually the same language and run time environment. And as I've tried to explain, supporting the same language and run time environment has advantages both for the FPC developers (by lack of an official standard to aim for, a de fact standard is a nice alternative guideline) and for the Object Pascal programming community (code reuse, less fragmentation, ...). Embarcadero loving, hating or ignoring us is besides the point.

They see it as a competitive compiler, hence the reason they are getting there act together now, and implementing missing feature.

I think that Apple's success in the consumer space and Linux' success in the server space (and more and more also in the consumer space, albeit still relatively limited compared to the alternatives) has more to do with their decision to support those platforms than the fact that we support them.

Also why they are implementing their own versions of a cross-platform compiler, instead of working with Free Pascal and reusing it for non-Windows platforms.

They'd probably have as much trouble as you, if not more, in getting everything they want/need in the compiler and RTL. They could also fork it, but the downsides of that combined with other consequences (such as no ability to integrate the compiler in their IDE without releasing the IDE under a GPL-compatible license) would probably not weigh up to simply modifying a code base they already know through and through.

Generics is a bad example. A Delphi version with generics came out a couple of months after FPC got them. That means that they probably started working on them before we did, and that they would have had to switch to our version somewhere during their quality assurance phase.

You are living a dream if you think they care about FPC, so why the hell care about them. FPC is a good product, you don't need Delphi (or delphi compatibility) when you have FPC.

Waarom spreken we Engels hoewel we elkaar ook verstaan in het Nederlands/Afrikaans?

Jonas

I can understand where you are coming from, but there are massive advantages for developers in keeping compatibility with Delphi. If a developer wants to switch from Delphi, he comes with a lot of experience with Delphi classes and components, so something with that compatibility will save a huge amount of time.

What FPC and lazarus does is making the delphi knowledge portable. It's not just the language. With subtle differences, people will spend hours lost in documentation and give up. With fpgui and mseide it takes me really long to do what I need to, since I haven't got the experience and knowledge of the classes, no wonder those communities are small.

I'm afraid that without delphi compatibility, fpc will probably also shrink to almost nothing.

Henry

You are living a dream if you think they care about FPC, so why the hell care about them.

As said before, a lot of fpc users care, see bug tracker. And as long as I didn't care much about TP, FPC was a one man show: from 1993 to 1996 I developed FPC alone and cared only little about TP, this is also why FPC source files have the extension .pp: at the very beginning I planned to create a compiler for a language I invented called Pascal++ (this is also why it had procedure overloading and exceptions from the very beginning; early compilers even had no pascal like read/write(ln)) and use it for my chess programs :) The chess programs were written in TP, but I missed 32 bit and several language features and I wanted to kick TP compatibility from them as soon as my Pascal++ compiler called FPK Pascal would be ready. Very similiar thoughts as yours.

The sad thing was: nobody was interested in this language and compiler. Then a very good friend of mine wrote a tp compatible crt unit and convinced me to implement some features like pascal like write/read(ln). After this was done, suddenly, several people started to use FPK Pascal to translate their programs. At this pointer I realized that for a success of the compiler it's important to make compromisses between the needs of users and my ideas. If I didn't do so, FPK Pascal would have probably died in the mid-nineties a silent death on my hard disk and I would have continued to work on FreeWin95 (the very beginnings of ReactOS) instead on FPC :)

Jonas Maebe wrote

supporting the same language and run time environment has advantages both for the FPC developers (by lack of an official standard to aim for, a de fact standard is a nice alternative guideline)

Why didn't you just say that from the start! ;-)
I get the picture now. No official (think ISO) standards exist for Object Pascal, so go with the second best option.

Waarom spreken we Engels hoewel we elkaar ook verstaan in het Nederlands/Afrikaans?

Sodat almal anders ook kan verstaan. En seker omdat rekenaars en programmerings tale almal in Engels is.

Hello,

Graeme Geldenhuys wrote

Why didn't you just say that from the start!  ;-) I get the picture now. No official (think ISO) standards exist for Object Pascal, so go with the second best option.

I have read superficially the ISO Standards for Pascal and I couldn't find a significant description about the Run-Time Library except for basic stuff like WriteLn:

http://www.pascal-central.com/standards.html

It seams to me that they only standarize the language itself, something which could be done adding a {$Mode ExtPascal} or something.

Having said that, think that Object Pascal as we know it should also have a standard.

Michael Van Canneyt wrote

So actually, currently it's you being dangerous, and we are protecting your job safety. Just because we like our hobby.

I don't think dangerous is the correct word to use here. My thoughts on open-source software (and this I have mentioned to a few here before) is that because it's open and free, others using that software have more time to review what is coming in the next release, and can prepare their own project to keep up with changes. Exactly what I do with fpGUI when a beta or RC release of FPC is announced.

Now compare that to Borland/Embarcadero that tells you nothing, not even a clear roadmap (unless you pay them a fortune), and then suddenly release a new version of a product.

I'm also a big believer of rather breaking a bit of code, to improve an underlying design. In the long run you reap a lot more rewards and have much better maintainable code. Compare that the Windows spaghetti mess of inconsistent API's, software riddled with bugs etc, all because they put "backward compatibility" on such a high pedestal that it affects their product line.

Our company software was often broken due to changes made to tiOPF or fpGUI. But those changes were carefully thought out, designed and then implemented. And even though such changes broke our software, it was always relatively little effort to fix - and because the frameworks were open source, I knew what was coming so it gave me time to prepare. Your changes to MGM in tiOPF was one of those times. It broke our code, but now we are much better off than before. So the one day it took to fix our software was well worth the effort. And look at the positive knock-on effect that had. You got introduced to real-world usage of Observer etc, and that made you think of possible improvements in the Classes unit.

I just think the same could be applied to any project, including FPC. So no, I am not suggesting "dangerous" changes, just well thought out improved design in some places.

Felipe Monteiro de Carvalho wrote

Having said that, think that Object Pascal as we know it should also have a standard.

I'm thinking the same thing, and am busy reading the beginnings of such a standard - which was unfortunately never completed or submitted. Maybe the Free Pascal project can continue work on this and make FPC the first Object Pascal compiler to adhere to this.

http://www.pascal-central.com/OOE-stds.html

How does ANSI or ISO standards work? Can anybody create a draft to be submitted, or do you have to be some company or organization first? I guess a Google search will answer some of this.

In our previous episode, Felipe Monteiro de Carvalho said:

Such discussions have raged several times. But most good standards are the result of a multi-vendor effort, usually under the pressure of their customers. (like the ansi C and POSIX standarization)

Unilateral standards rarely make sense, since the single vendor can deviate from them at any time, and might not even implement it fully (e.g. OOXML)