Making a plea :)

[Warfley]

There seems to be an idea here that Wirth figured out everything there is to know about programming in 1980 and everything has been downhill since. This is surprising because the primary driver of new features in FPC seems to be copying Delphi. I can understand why you'd want to preserve the legacy of something historical but FPC is already way off the deep end with OOP, interfaces, generics, nested functions, dynamic arrays and everything else that was added (most for Delphi compatibility as the primary driver it appears to me).

Not necessarily, there was a time when new features were added much faster into FPC than into delphi. Generics, Operator Overloading, advanced records, etc. where all in FPC before Delphi and are still more powerful in FPC than in Delphi (delphi does not support generic functions, operators only as class operators, etc.)

It's relatively recent that the FPC team became more conservative, probably because of the growing code base of the compiler and the need for maintainance with the small team. I'm currently doing stuff in the FPC source code and yes I can tell you it is very complex due to so many edge cases and optional features everyhwere. Like for something I'm currently building I changed a bit on records and it all works well, except the ISO pascal new initialization, because this is a special case for ISO pascal I did not think about when doing my changes.

[Ryan J]

I've understood the original point such as that they did not want to write large expressions into the function call, but rather have them for readability defined elsewhere.

Yeah I think so. Why are named variables not appropriate? The only problem he had was that now his scope local things need to be part of the main function even though they're only relevant to that one scope. It's cleanliness problem basically.

[MarkMLl]

It seems to me that you don't want actual variables here, but defines:

Code: Pascal  [Select][+][-]

1. {$define x:=long expression1}
2. {$define y:=long expression2}
3. fun(x, y);

No need to add any new featrue to the compiler for this

Heretic! Those are macros! You will be cast out!

Actually, I'm about as sick of people coming along and asking why FPC doesn't implement macro parameters as I am of the developers' argument that because C-style macros are problematic there's no better way of doing it.

A straight textual substitution /can/ be valuable, but the way Rust allows the type of parameter to be defined is inherently superior.

MarkMLl

[marcov]

Because I'm trying to learn new things from other languages and address issues in Pascal that are more frustrating when I switch languages.

But is that simply because you switch languages, or because Pascal has a problem?

There seems to be an idea here that Wirth figured out everything there is to know about programming in 1980 and everything has been downhill since.

If that was the case, we wouldn't have the Delphi dialect.   But yes, we are not constantly on the lookout for random new features to implement.

The FPC dialects are already humongous, and adding new features often leads to unforeseen bugs due to combination of features.  For language experimentation, it is better to use a new language.

This is surprising because the primary driver of new features in FPC seems to be copying Delphi.

True but that was usually qualified as

... albeit at arm's length.

Which in this case fully applies :-)

I can understand why you'd want to preserve the legacy of something historical but FPC is already way off the deep end with OOP, interfaces, generics, nested functions, dynamic arrays and everything else that was added (most for Delphi compatibility as the primary driver it appears to me).

Yes and no. OOP was already part of TP, and Generics were copied from C++ before Delphi copied it from C#. 

Delphi is/was a large driver, and I'm actually one of the proponents of a high degree of compatibility. But choices have to be made, and there are way more important things than whatever desperate syntax enhancements Embarcadero did to entice subscribes to subscribe another year.

The Delphi compatibility is primarily driven by the practical concerns to getting existing code bases and components to run, and a bit less to examine Delphi release manifests and start immediately implementing. So delphi compatibility is a matter of choices, and something as benign as x64 assembler syntax (introduced XE2) IMHO hurts much more than inline variables (introduced Delphi XE10.3 or so)

But as noted elsewhere in this thread, the sense of urgency that people try to convey is totally unrealistic. Even if you start implementing it in a branch now, there is a big chance it won't be merged before the next major version is branched. (and that is the contents of trunk now, so FPC 3.4 or 4.0). With the current glacial release pace, that means 5-7 years at the very minimum. (that number is based on the historic cadence of major branches 5 years apart, and 1-2 years between branching a new major branch and its actual release).

 

[MarkMLl]

Yes and no. OOP was already part of TP, and Generics were copied from C++ before Delphi copied it from C++. 

Delphi obviously changed things by instantiating onto the heap (and hiding the pointer dereference). But arguably that was just continuing the spirit of Turbo Pascal, since I think it was that (or /possibly/ UCSD) which introduced the considerable innovation of being able to return a non-scalar (i.e. a string, record and so on) from a function.

I wonder whether Delphi would have become such a bloated monstrosity if Anders Hejlsberg hadn't defected?

MarkMLl

[marcov]

Yes and no. OOP was already part of TP, and Generics were copied from C++ before Delphi copied it from C++. 

Delphi obviously changed things by instantiating onto the heap (and hiding the pointer dereference). But arguably that was just continuing the spirit of Turbo Pascal, since I think it was that (or /possibly/ UCSD) which introduced the considerable innovation of being able to return a non-scalar (i.e. a string, record and so on) from a function.

String yes, other types afaik TP didn't, that is a FPC extension. And yes classes are different from TP objects, but be as it may, it is different from the Wirth philosophy.

I wonder whether Delphi would have become such a bloated monstrosity if Anders Hejlsberg hadn't defected?

If he was still at Borland around D4 times, I wouldn't hold my breath

Of course making it ad hominem is not entirely fair. Maybe Microsoft gave Anders more of a carte blanche than Borland did.

[MarkMLl]

String yes, other types afaik TP didn't, that is a FPC extension. And yes classes are different from TP objects, but be as it may, it is different from the Wirth philosophy.

I'm pretty sure that was a TP thing, and fairly early. However they did it by allocating space on the stack for the returned record (or whatever) rather than on the heap.

I've been mulling that one over since the discussion about the Str() a few days ago. I'm still not sure whether "Pascal style" strings were a Borland or UCSD innovation... Georgia Tech had an ALGOL with string extensions for which I've just found the manual ** but while it was batter than other ALGOLs of comparable age it wasn't quite as elegant as Pascal.

MarkMLl

** http://bitsavers.org/pdf/georgiaTech/GTL_Programmers_Reference_Manual_for_the_Burroughs_B_5500_Aug1974.pdf

[Thaddy]

If he was still at Borland around D4 times, I wouldn't hold my breath

If you had access to beta's at the time, you would have known.

Of course making it ad hominem is not entirely fair. Maybe Microsoft gave Anders more of a carte blanche than Borland did.

At Borland he could do what he wanted, but his team fell apart. Philipe Kahn made him rich.  He doesn't care.. he really doesn't.
Not MS, the company, but Bill Gates himself convinced him to make the transfer. Resulting first in F#, later C# and much more. Making him very much richer, unwanted, at least uncomfortable (most Danes feel uncomfortable in such situations).
I observed at the time there was a lack of focus at Borland and a braindrain.
I consider that the cause. Where's One Borland Drive? ..100 Borland way?

[simone]

Personally, I can live happily without so-called inline variables, but I realize that younger programmers, who have had training in other languages, may want this feature. That said, if Delphi compatibility is still considered important, could we consider providing this feature only for Delphi mode and not allowing it in ObjFpc mode?

[440bx]

could we not consider providing this feature only for Delphi mode and not allowing it in ObjFpc mode?

I think that's a valid thought but...

(disclaimer: I'm not an FPC developer). Personally, if I were to write the code necessary to correctly implement inline variables then it's hard to see why perfectly working code that needs to be maintained anyway should be restricted to one mode.   Particularly considering that mode Delphi does not guarantee full Delphi compatibility anyway.

IOW, if you got it... use it

[Ștefan-Iulian Alecu]

[...] Resulting first in F#, later C# and much more. [...]

Anders had no involvement in F#, that was Don Syme at Microsoft Research in Cambridge. An important man of his own and without him, C# probably would be barely on the same level as Delphi language-wise. C# wouldn't have had generics so early (or the entire CLR, for that matter) without Syme. He's given way less credit than he should deserve.

On the other hand, everyone likes to forget J++ and MFC ever existed and that's fully on Anders, so not everything he's done is brilliant. TypeScript included.

How could there be 100 Borland Way when Borland passed through dozens of hands at this point? It might be One Idera Way now and One Acme Way in 5 years. 

[Thaddy]

Anders had a really involved way in F# in that he brought the concept a step further. But indeed it is not one of his conceptions: that turned into C#.

[LV]

There seems to be an idea here that Wirth figured out everything there is to know about programming in 1980

Interestingly, in his review article for ACM Communications (March 2021), Wirth mentioned Turbo Pascal but ignored Delphi or Free Pascal. Why? https://cacm.acm.org/opinion/50-years-of-pascal/

[440bx]

Wirth mentioned Turbo Pascal but ignored Delphi or Free Pascal. Why?

Why ? ... simple... Turbo Pascal's impact on the programming field is orders of magnitude greater than any other of its contemporaries.

As of today, Pascal and specifically Turbo Pascal, is quite likely the programming language that is (or was) known by the largest number of programmers _ever_.

[MarkMLl]

There seems to be an idea here that Wirth figured out everything there is to know about programming in 1980

Interestingly, in his review article for ACM Communications (March 2021), Wirth mentioned Turbo Pascal but ignored Delphi or Free Pascal. Why? https://cacm.acm.org/opinion/50-years-of-pascal/

I read a piece which was probably printed circa 1990 (but possibly from an older interview) in which he was extremely dismissive of OOP. I can't remember the details but the impression I got was that he didn't consider it any advance over nested Pascal-style records, but I also got a whiff of "Not Invented Here" which- TBH- would not be surprising considering his motivation for designing Pascal in the first place.

I've tried to find it in the past without success, because I really would like to understand his rationale. I'd also like to know whether it would make more sense if I boned up a bit on Oberon etc.

MarkMLl