Recent

Author Topic: Delphi adopted FPC?  (Read 41586 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11452
  • FPC developer.
Re: Delphi adopted FPC?
« Reply #60 on: November 22, 2014, 02:59:38 pm »
Here's the problem. Is it possible to be better than Delphi, by only repeating after Delphi?
Not. But compatibility is required if FPC is interested in increase of users audience. But it is necessary to remember that today's Delphi users is not Delphi 7 - guys.

You are confusing Delphi usage with FPC growth. FPC will take the disgruntled users, and those are much more likely not to upgrade.

In XE2 time Embarcadero not had own iOS compiler, but already in XE4 had. FPC was a temporary and limited solution, because modern Delphi features could not be used on iOS and was subject to criticism.

I was told they were originally planning to use their own for XE2, but it was not ready for various reasons, and when it was clear it wouldn't make it for the XE2 release, they reused FPC which they initially meant as a start to develop the libraries in parallel to the compiler to get a quicker time-to-market.

The bit about modern Delphi features is true, but not from users, but from Embarcadero itself. They wanted to have Datasnap mobile clients as soon as possible, and that team too liberally inserted usage of the new features.  They probably thought nothing about that because they expected their own compiler to be ready. It was STILL not ready for XE3, so they skipped the mobile offering, leaving users with investments in the cold waiting for XE3.5 (which was sold to them as XE4, of course no discounts...).

So basically it is a story about Embarcadero's failed roadmap planning.

Sure FPC has limitations, but hitting those could easily have been avoided or amended. But they didn't avoid due to their roadmap problems. Amending FPC (even if they had recognized it early enough) was probably politically impossible since  they would even have to donate compiler improvements back to a "competitor" because of the GPL(despite that they were eager to use it to bolster XE2 feature lists and make a buck extra of a sale).

Without mobile, XE2 only had 64-bit as appeal.

The rest is just salesfolk trying to cover up, and get you to stump for XE4+ addition to get the mobile offering. (if they were so unhappy with it, they shouldn't have released XE2, they held all the cards and new everything up front, so no excuses)

Don't be a sheep think!   If you really believe Embarcadero's spin of events, get a refund for XE2, because they sold you something THEY say is not up to snuff.

FPC didn't sell you XE2, and didn't make cash on it. Embadero did. The fact that the critique on the XE2 situation came AFTER they sold it to you, and when they had something different to sell to you says enough.
« Last Edit: November 22, 2014, 04:17:14 pm by marcov »

Leledumbo

  • Hero Member
  • *****
  • Posts: 8757
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Delphi adopted FPC?
« Reply #61 on: November 22, 2014, 03:20:31 pm »
But it is necessary to remember that today's Delphi users is not Delphi 7 - guys.
Many of Delphi XE users I know are existing Delphi 7 users as well, some even chose to stick with Delphi 7 due to many reasons.
I'm not topic starter, but think that false illusions is not good for anybody.
One example is enough to break a theorem. Snorkel is just one example, I know many other Delphi guys who finally uses Lazarus to replace Delphi in their business. So your false illusions theorem has been broken. FPC/Lazarus CAN replace Delphi, it's just a matter of time and conditions when they finally do it. Of course a lot of Delphi users are still satisfied with Delphi and they haven't even tried Lazarus once.

sam707

  • Guest
Re: Delphi adopted FPC?
« Reply #62 on: November 22, 2014, 04:05:39 pm »
dear kazalex what makes a 'standard' is not popularity or your will, please give us a link to an International Standard Organization (ISO) Pascal then we can discuss! as long as you can not provide this, you are out of any conversation just by assuming that delphi is standard! Clear? It is to YOU to open your eyes! have you any clue around the word 'standard'? hahaha did you ever try to make Champagne in Moscow or Vodka in Paris?  :D

As long as there is no standard, the only acceptable are THOSE FROM THE ORIGINAL AUTHORS and the Universities they were/are working in, that are WorldWide known!

Where's delphi's University? I.S.O. department??  :D in yer dreams!
« Last Edit: November 22, 2014, 04:47:18 pm by sam707 »

sam707

  • Guest
Re: Delphi adopted FPC?
« Reply #63 on: November 22, 2014, 04:22:08 pm »
thank you @Leledumbo and @marcov

yes Lazarus/FPC has become a Big Boy and can do it!!!

Refine the UIs in a dynamic crossplatform way and im quite sure that many Programmers + Designer Artists are going to catch the Laz Train running!
« Last Edit: November 22, 2014, 04:35:34 pm by sam707 »

kazalex

  • New Member
  • *
  • Posts: 29
Re: Delphi adopted FPC?
« Reply #64 on: November 22, 2014, 08:01:51 pm »
You are confusing Delphi usage with FPC growth. FPC will take the disgruntled users, and those are much more likely not to upgrade.
And what will be when the user will understand that use FPC returns him on Delphi 7 with generics?

The bit about modern Delphi features is true, but not from users, but from Embarcadero itself.
I remember users complaints on forum of Embarcadero, because many already began using custom attributes and RTTI in own code, but could not compile this code for iOS. It's blame of Embarcadero, not FPC. But it also show degree of readiness of FPC.

Many of Delphi XE users I know are existing Delphi 7 users as well, some even chose to stick with Delphi 7 due to many reasons.
Just they as before Delphi 7 guys. Not the license for the new version changes world view.

Snorkel is just one example, I know many other Delphi guys who finally uses Lazarus to replace Delphi in their business. So your false illusions theorem has been broken. FPC/Lazarus CAN replace Delphi, it's just a matter of time and conditions when they finally do it.
Please, read my answer for Snorkel.

dear kazalex what makes a 'standard' is not popularity or your will, please give us a link to an International Standard Organization (ISO) Pascal then we can discuss! as long as you can not provide this, you are out of any conversation just by assuming that delphi is standard!

I want to ask... You understand value of "de-facto"?

FPK

  • Full Member
  • ***
  • Posts: 118
Re: Delphi adopted FPC?
« Reply #65 on: November 22, 2014, 08:15:15 pm »
You are confusing Delphi usage with FPC growth. FPC will take the disgruntled users, and those are much more likely not to upgrade.
And what will be when the user will understand that use FPC returns him on Delphi 7 with generics?

FYI, things like helpers and advanced records are post D7. I understand that not everybody knows when each feature was introduced, but if you have no clue about it, just stop making wrong statements.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11452
  • FPC developer.
Re: Delphi adopted FPC?
« Reply #66 on: November 22, 2014, 08:30:14 pm »
You are confusing Delphi usage with FPC growth. FPC will take the disgruntled users, and those are much more likely not to upgrade.
And what will be when the user will understand that use FPC returns him on Delphi 7 with generics?

Well, as demonstrated, the version delivered with XE2 can add two numbers together with generics, while Embarcadero's native compiler can't. So that is a matter of viewpoint.

I remember users complaints on forum of Embarcadero, because many already began using custom attributes and RTTI in own code, but could not compile this code for iOS. It's blame of Embarcadero, not FPC. But it also show degree of readiness of FPC.

There are always people that are fond of shiny toys. You can spin that into  a silly "readiness" argument (that you can abuse for every difference between FPC and Delphi, so that is a bit silly), but that same crowd was happy to use the old stuff only 2 years before.

More importantly, all this is also because Embarcadero didn't properly prepare for it, and shipped FPC without doing any work on it.  Users ran into a brick wall. Bad planning and roadmap again. With a bunch of fulltimers they could have fixed that in half an year.

FPC could have been ready, Embarcadero  just didn't want to. They'd rather sell you XE4, and spend not one dime on the competition, even if they used their product, and afterwards used it as a scapegoat.

(at least the ones that could wait _another_ 1.5 years, wanted to fork out the extra cash and didn't  reprogram in objective C like most, which is probably all serious users. leaving the whiners)

Many of Delphi XE users I know are existing Delphi 7 users as well, some even chose to stick with Delphi 7 due to many reasons.

(to be honest, I don't know one user personally that is really using the mobile stuff. Everybody is looking and experimenting, but even now at XE7, nobody seems to be rolling out)

dear kazalex what makes a 'standard' is not popularity or your will, please give us a link to an International Standard Organization (ISO) Pascal then we can discuss! as long as you can not provide this, you are out of any conversation just by assuming that delphi is standard!

I want to ask... You understand value of "de-facto"?


De-facto is something for historians in retrospect. Might also come up in a helicopter view discusson on management level.  Extremely generic, and signifies more intent than anything practical.

For it to mean anything  practical you need a document or specification. An ISO one, or de-factor Embardero one, anything.

There isn't one, and various Delphi versions are subtly incompatible to eachother. They make it up as they go.

kazalex

  • New Member
  • *
  • Posts: 29
Re: Delphi adopted FPC?
« Reply #67 on: November 22, 2014, 08:51:01 pm »
FYI, things like helpers and advanced records are post D7. I understand that not everybody knows when each feature was introduced, but if you have no clue about it, just stop making wrong statements.
Oh, sorry, of course Delphi 2006 with generics. Everything changes it! But why even Delphi 7 can parse this expression:
Code: [Select]
const  ManagedObjects   = {$IF Declared(vmtArcOffset) And (vmtArcOffset <> Integer(0))}Succ{$IFEND}(False);
..but FPC not. No answer is required, however.

FPK

  • Full Member
  • ***
  • Posts: 118
Re: Delphi adopted FPC?
« Reply #68 on: November 22, 2014, 09:14:25 pm »
FYI, things like helpers and advanced records are post D7. I understand that not everybody knows when each feature was introduced, but if you have no clue about it, just stop making wrong statements.
Oh, sorry, of course Delphi 2006 with generics. Everything changes it!

Great, we are getting forward. Next one: Exit having a parameter and pointer math.

Quote
But why even Delphi 7 can parse this expression:
Code: [Select]
const  ManagedObjects   = {$IF Declared(vmtArcOffset) And (vmtArcOffset <> Integer(0))}Succ{$IFEND}(False);
..but FPC not. No answer is required, however.

Indeed, here it works.

kazalex

  • New Member
  • *
  • Posts: 29
Re: Delphi adopted FPC?
« Reply #69 on: November 22, 2014, 09:35:07 pm »
Well, as demonstrated, the version delivered with XE2 can add two numbers together with generics, while Embarcadero's native compiler can't. So that is a matter of viewpoint.

But native compiler can do it for single method:
Code: [Select]
function Test<T>:T;
...when FPC not. This is true a matter of viewpoint.

There are always people that are fond of shiny toys. You can spin that into  a silly "readiness" argument (that you can abuse for every difference between FPC and Delphi, so that is a bit silly), but that same crowd was happy to use the old stuff only 2 years before.
Toys? Probably it will cease to be a toy as soon as begins to be supported FPC.  And to good toys very quickly get used, therefore distance per two years seems a fathomless pit.

(to be honest, I don't know one user personally that is really using the mobile stuff. Everybody is looking and experimenting, but even now at XE7, nobody seems to be rolling out)
Because Firemonkey is Failmonkey. Really, no way with this.

De-facto is something for historians in retrospect. Might also come up in a helicopter view discusson on management level.  Extremely generic, and signifies more intent than anything practical.
It is enough to look at whom copy and everything becomes clear at once.

kazalex

  • New Member
  • *
  • Posts: 29
Re: Delphi adopted FPC?
« Reply #70 on: November 22, 2014, 09:50:46 pm »
Great, we are getting forward. Next one: Exit having a parameter and pointer math.
Exit parameter? WOW! Now i happy. Pointer math? But what more from D2009? Anonymous methods maybe or nested exceptions?

Indeed, here it works.
Good job. On rev:29112 it not worked.

FPK

  • Full Member
  • ***
  • Posts: 118
Re: Delphi adopted FPC?
« Reply #71 on: November 22, 2014, 10:11:23 pm »
Great, we are getting forward. Next one: Exit having a parameter and pointer math.
Exit parameter? WOW! Now i happy.

Good  :)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11452
  • FPC developer.
Re: Delphi adopted FPC?
« Reply #72 on: November 22, 2014, 10:20:23 pm »
But native compiler can do it for single method:
Code: [Select]
function Test<T>:T;
...when FPC not. This is true a matter of viewpoint.

The native compiler can't do it afaik. If you can, please show how.

Quote
There are always people that are fond of shiny toys. You can spin that into  a silly "readiness" argument (that you can abuse for every difference between FPC and Delphi, so that is a bit silly), but that same crowd was happy to use the old stuff only 2 years before.
Toys? Probably it will cease to be a toy as soon as begins to be supported FPC.  And to good toys very quickly get used, therefore distance per two years seems a fathomless pit.

Why do you think so ? btw, I work with delphi exclusively in my day job, so it is not unfamiliarity with those features, most of which I'm lukewarm about at best.

Generics are about the only important feature after D2009 IMHO, and that is bugfixing rather than new features.  I think D2010's RTTI is a good thing in moderate doses, but they ODed that by providing it hardlinked into the libraries, doubling EXE sizes. Not elegant, and worse, bad for anti-reverse  engineering purposes.

Quote
Because Firemonkey is Failmonkey. Really, no way with this.

It seems that Datasnap will be to go first. Embarcadero is dropping it for EMS it seems.

« Last Edit: November 22, 2014, 10:22:36 pm by marcov »

kazalex

  • New Member
  • *
  • Posts: 29
Re: Delphi adopted FPC?
« Reply #73 on: November 22, 2014, 11:55:06 pm »
The native compiler can't do it afaik. If you can, please show how.
https://www.dropbox.com/s/5w22qx98xxk6onj/DXE4_On_VB_Screenshot%20from%202014-11-23%2001%3A44%3A59.png?dl=0

Why do you think so ? btw, I work with delphi exclusively in my day job, so it is not unfamiliarity with those features, most of which I'm lukewarm about at best.

Because code:
Code: [Select]
TPerson = Record

  FirstName  : UnicodeString;
  MiddleName : UnicodeString;
  LastName   : UnicodeString;

  [XmlRpcMapping.Optional]
  NickName   : UnicodeString;

  [XmlRpcMapping.Optional]
  Birthday   : TDate;

  [XmlRpcMapping.Optional]
  Photo      : XmlRpcBinary;

 End;
more readable and clear than:
Code: [Select]
TPerson = Record

  FirstName  : UnicodeString;
  MiddleName : UnicodeString;
  LastName   : UnicodeString;
  NickName   : UnicodeString;
  Birthday   : TDate;
  Photo      : XmlRpcBinary;

 End;
...
// XmlRpcMetadata.RegisterField(TypeInfo, FieldOffset, FieldTypeInfo, FieldName, MappingOptions);
XmlRpcMetadata.RegisterField(TypeInfo(TPerson), Integer(@TPerson(NIL^).NickName), TypeInfo(UnicodeString), 'NickName', [fmOptional]);
XmlRpcMetadata.RegisterField(TypeInfo(TPerson), Integer(@TPerson(NIL^).Birthday), TypeInfo(TDate), 'Birthday', [fmOptional]);
XmlRpcMetadata.RegisterField(TypeInfo(TPerson), Integer(@TPerson(NIL^).Photo), TypeInfo(XmlRpcBinary), 'Photo', [fmOptional]);
...

Generics are about the only important feature after D2009 IMHO, and that is bugfixing rather than new features.
Generics undoubtedly good feature, but not in Delphi implementation. Besides their appreciable restrictions also not cleverest linker inflates executable modules.

I think D2010's RTTI is a good thing in moderate doses, but they ODed that by providing it hardlinked into the libraries, doubling EXE sizes. Not elegant, and worse, bad for anti-reverse  engineering purposes.
I agree about moderate doses and OD. But for your own code RTTI allow to regulate quantity of information which will be stored. Generally RTTI very useful for jobs like a data mappings. Also RTTI unit has very useful things as TVirtualMethodInterceptor and TVirtualInterface. TVirtualInterface may be used for implementing of duck typing for example.


sam707

  • Guest
Re: Delphi adopted FPC?
« Reply #74 on: November 23, 2014, 01:07:38 am »

I want to ask... You understand value of "de-facto"?

YES SO DE FACTO YOU ARE THE KING OF THE TROLLS AND THE MASTER OF NONSENSE?

:D

Just wondering about the proper usage of "de facto" hehehehe
« Last Edit: November 23, 2014, 01:24:43 am by sam707 »

 

TinyPortal © 2005-2018