Marco van de Voort wrote:
I think your original assumption was closer to the truth, at least for versions after 3. Featuritis, combined with the need to compete with Windows orientated competitors. (still the windows dependance of the language is not that large though)
I didn't claim that. AFAIK, only some small language elements are Windows oriented. But most existing code written for Delphi is probably quite Windows oriented.
Borland C++ Builder can compile Pascal code.
You mean what Borland likes to call Pascal ...
What 99% of the Pascal programmers calls Pascal ;-)
No. Maybe 99% of Borland (and FPC, ...) users, but most of them are not Pascal programmers since these compilers don't support the Pascal language.
Wirth has created a language and called it Pascal. That's his right. Later this language has been formally specified in the first Pascal stnadard. Others have created various modifications to the language. That's also their right. But calling these modifications also Pascal (unless they're a superset of the Pascal language) is not their right. What would you think if, say, someonse writes a compiler, calls it FPC, happens to get more popularity than your FPC and then claims his compiler is *the* FPC?
(Note that I'm not talking about extensions, but omissions from the Pascal language.)
Delphi adds exceptions (can of worms in its own right combined with your non-local goto's :-),
Uhm, you mean Pascal's non-local gotos. :-)
Their architecture looks rather mixed-up and confused to me, so much that even MS's one might be cleaner, and I wouldn't be surprised if they get overtaken and kicked out by them soon ...
MS has owned a small percentage in Borland for a while, but sold it. There are some rumors that IBM might acquire Borland, (probably more for JBuilder than for Delphi). Another possibility is bankruptcy. How can they compete if the competitor can sponspor development tools and even the sales from their OS and Office suite sales?
Yes, I suppose it will make more sense for MS to drive them into bankruptcy than buying them out ...
But Windows-only code can be also be a boost. Do you have estimates what percentage windows users there are under GPC users? For FPC I guess it Windows is twice as much as Linux, and the rest is 10% combined, so win32: 60%, linux: 30%, rest: 10%.
This might be true, but I'm not exactly interested in supporting non-free and non-portable software. The only possible reason for supporting Delphi compatibility I can imagine is to allow programmers make their Delphi programs available for other systems. But if the Windows specific code is too hard to replace (or people don't want to do this), that's pointless.
There are two reasons to implement that feature:
- You want to be Delphi compabitle someday: implement it, even though you hate it. (If it really requires completely new subsystems or other really difficult (manyear) stuff, because it e.g. conflicts too much with some ISO parts, then you can let it be the exception to the rule)
- You don't want Delphi compability, but it is a useful feature as a GPC specific extension on some of the supported dialects.
Please explain to me how this feature is useful, i.e., you can do anything with it that you can't do (easily) without?
Otherwise you might implement 250 of these parser and minor language details (like variable result for the return value of functions),
Do you mean result variables (function foo = bar: baz)? They're actually standard (EP), and GPC has had them for a long time ...
Frank