[fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
graeme at geldenhuys.co.uk
Thu Feb 28 01:41:34 CET 2013
On 2013-02-28 00:16, Simon Kissel wrote:
> This is a terrible idea. The business advantage of Object Pascal
> has always been the component market, as it reduces development
Component vendors simply aren't interested in FPC, and those that are,
are bought about by EMBT and made Delphi only.
> 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.
I stumbled across this last week too. On the same OS, I compiled the
exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running
those tests, again on the same system, the Delphi executable completes
the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same
> 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
If you want to say "delphi compatible", it must be all or nothing. EMBT
is butchering the Delphi name to hell and gone. I don't think FPC should
follow just because.
A few issues aside, I honestly believe FPC is a much better product than
Delphi. FPC should build on its strengths - it doesn't need Delphi.
eg: In a recent discussion in the Google+ Delphi Community, they asked
what new language features would Delphi developers like. After about
15-20 replies I had to post a message saying that FPC actually supports
most of the things they had on their wishlist.
As I said, FPC doesn't need Delphi. Innovate on your own and don't
follow Delphi into the grave. Plus, stay true to the Pascal language as
much as possible.
- Graeme -
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
More information about the fpc-pascal