Hello! Anything new?

[LeP]

Yes LeP, thats accurate but not complete. The problem now is that FPC (main) has been allowed to evolve to far from FPC322 that its very hard to compare the two. It is, in effect, a new product. Maybe we need  new branch, fpc-ng, subject to some public testing and release as, just that, a new Pascal Compiler ?
Ok, some jest included     
Davo

I didn't want to delve into the specific development difficulties of FPC,
but the problem here seems to be that there's no concrete "governance" of the project and it's being moved haphazardly according to individual needs.
The fact that the latest official stable version still has problems with "generics" (and has been for 5 years now) is illustrative.

If a core developer got, say, $5k USD for the work, would inline variables be implemented then?
I'm just curious whether the real limitation is technical, ideological, or simply time - and if money would change anything.
If someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk?

Even if, as @FIbonacci says, someone were paid to make a new implementation (and it would be yet another one), on which version would it be applied, and what would be the release time and maintenance cycle?

Always thinking of a SINGLE FPC, because otherwise it would be enough to create your own repo and develop independently.

P.S.: many have claimed that the trunk version isn't ready for release and production, so what's the point of all the effort put into making changes to this "version"? I mean, is FPC still a viable product for building something reliable, or is it just for hobbyists?

[440bx]

I mean, is FPC still a viable product for building something reliable, or is it just for hobbyists?

A recent post from @PascalDragon specifically characterized FPC as being a hobbyist project.

This came a bit as news to me since I remember reading somewhere that FPC was meant to be an "industrial strength" compiler. 

Bottom line: it's kind of hard to know what FPC is at this point.  The one thing that is fact is that the upgrade/improvement cycle is rather long.

[marcov]

I mean, is FPC still a viable product for building something reliable, or is it just for hobbyists?

A recent post from @PascalDragon specifically characterized FPC as being a hobbyist project.

Probably mostly from a resource allocation and timescale perspective.

This came a bit as news to me since I remember reading somewhere that FPC was meant to be an "industrial strength" compiler. 

Those are the goals, yes. Keep in mind it was born as a 32-bit TP replacement. So usability and compatibility was put before redoing the language with a purist bend.

Bottom line: it's kind of hard to know what FPC is at this point.  The one thing that is fact is that the upgrade/improvement cycle is rather long.

Not exactly the same. More releases doesn't mean that development necessarily goes harder. The same development just get split up over more releases.

[440bx]

More releases doesn't mean that development necessarily goes harder.

Maybe not but, I believe that a serious piece of software (not a hobbyist thing) is characterized by a steady stream of releases to eliminate existing known bugs.

Do you know what is currently holding up the release of 3.2.4 ?

[marcov]

More releases doesn't mean that development necessarily goes harder.

Maybe not but, I believe that a serious piece of software (not a hobbyist thing) is characterized by a steady stream of releases to eliminate existing known bugs.

My point was that various aspects of the project can have various degrees of "seriousness", as you call it. One field, like compiler complexity can be further ahead than e.g. release engineering.

Do you know what is currently holding up the release of 3.2.4 ?

No.

[runewalsh]

a serious piece of software (not a hobbyist thing)

Since when is FPC a serious piece of software and not a hobbyist thing? :‌D

[marcov]

a serious piece of software (not a hobbyist thing)

Since when is FPC a serious piece of software and not a hobbyist thing? :‌D

For me: Since I started doing work in it, somewhere since 2015-2018 period.

[PascalDragon]

If someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk?

That already exists, we rejected it nevertheless. Inline variables don't fit the core concept of the language of separating variable declarations from their use which is one of the important points that makes Pascal easier to use than other languages.

I didn't want to delve into the specific development difficulties of FPC,
but the problem here seems to be that there's no concrete "governance" of the project and it's being moved haphazardly according to individual needs.
The fact that the latest official stable version still has problems with "generics" (and has been for 5 years now) is illustrative.

From the compiler's point of view generics is a rather complex feature and only comparatively recently users have started to use them more seriously so of course issues continued to be discovered. That Delphi had to use that annoying ambigous syntax (compared to the non-Delphi modes that use keywords) doesn't make things much easier, because in the worst case the parser needs to do backtracking.

[Fibonacci]

If someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk?

is one of the important points that makes Pascal easier to use than other languages.

This is your very subjective opinion, and it couldn't be more different from mine. The lack of inline vars is genuinely painful to work with. I can't imagine coding in PHP without inline vars - that would be absolutely wild. Same goes for JS, C#, Rust, Go, or virtually any modern language. None of them enforce this artificial separation. The day any of those languages introduced such a restriction would be the day they died.

And that's exactly why FPC is dead. A hobby project, maintained for old-timers, with museum value at best. A language artificially kept on life support by simply making it possible to compile on modern hardware - while the language itself remains frozen in amber.

Thanks for the final confirmation - now I can leave FPC to rest in peace and move on Cheers!

[440bx]

@PascalDragon,

That already exists, we rejected it nevertheless. Inline variables don't fit the core concept of the language of separating variable declarations from their use which is one of the important points that makes Pascal easier to use than other languages.

I'm not particularly fond of Delphi's implementation of inline variables, there are definitely better ways to implement the feature than the one they chose.   With that out of the way, I believe you use C and/or C++ regularly and, if that is the case, you probably use C/C++ ability to declare variables just about anywhere.  The important point resulting from that, is that you must have noticed that there are many cases where that ability actually results in simpler and easier to understand code, which is one of Pascal's original design purposes.

Personally, I've ported a fair amount of C code to Pascal and I've noticed that being able to have separate blocks of local variables in a function makes the function easier to understand.  In Pascal porting that function requires declaring all the block-scoped variables at the top of the function which makes them global to the function, which is inappropriate because they really are not global to the function, they only apply to a few statements.  Being at the top effectively turns them into annoying noise that only applies to a few statements that are normally in their own scope but, in Pascal must be at the global function scope.

My point is: inline variables are fully consistent with Pascal's design purpose which is to facilitate the production of code that is easy to understand and maintain.  It's just a feature that has been missing in the language, one which enables _locality_ which is extremely important in good programming.    Its presence in Pascal would make the language easier to use and the code easier to understand.

[marcov]

This is your very subjective opinion, and it couldn't be more different from mine. The lack of inline vars is genuinely painful to work with. I can't imagine coding in PHP without inline vars - that would be absolutely wild. Same goes for JS, C#, Rust, Go, or virtually any modern language. None of them enforce this artificial separation. The day any of those languages introduced such a restriction would be the day they died.

And that is your very subjective opinion, dressed up with hollow phrases and comparisons to conceal/confirm preconceived biasses.
 

Thanks for the final confirmation - now I can leave FPC to rest in peace and move on Cheers!

Tada!

[Curt Carpenter]

Answering the question "anything new" with "no" is often a feature not a bug.  I think that's the case with Pascal, and I salute the developers that have (for the most part) resisted calls for innovations.  (The ultimate abstraction ("vibe code") will be upon mankind soon enough -- rage, rage against the dying of the light!).

[440bx]

I salute the developers that have (for the most part) resisted calls for innovations.

There are new features in FPC trunk, I don't know that I'd characterize them as innovations since, TTBMK, they have all been part of other programming languages for some time.

[Curt Carpenter]

I don't know if being part of other languages is much of a recommendation though, especially weighed against a seriously stable platform.  But I'm old and that probably makes me anti-change in general. 

Still, I bet there are plenty of system managers out there that shudder at the thought of new things being done to their COBOL

[440bx]

I don't know if being part of other languages is much of a recommendation though,

My point was that I haven't seen what I consider innovation in a computer language, including FPC, in a rather long time.  What I've seen a lot of is "cross polination", that is, features found in one language being adopted by another (whether or not those features are actually good and/or genuinely useful.)

But I'm old and that probably makes me anti-change in general. 

I'm a little bit on the old side myself and I don't want to waste my time on changes that implement very dubious features (I define those as features I need less than once a year.)  OTH, there are _many_ features I've longed for that are not implemented in any language and a few that are  only somewhat implemented.   

Still, I bet there are plenty of system managers out there that shudder at the thought of new things being done to their COBOL

COBOL... that's a language that is very dear to my heart.  It has _plenty_ of deficiencies but when it comes to defining and formatting data, it puts C, C++ and Pascal put together to absolute shame.  That early 60s language does it better than the majority (likely all) currently popular programming languages.   

I find it absurd how much time and effort is spent in other languages to do what in COBOL is done in seconds (and many times even less than a second if you are a reasonably fast typist.)   In spite of that, COBOL may very well be the "real programmers" favorite whipping boy (which reflects very poorly on those programmers because it shows a very severe lack of understanding of what a programming language is supposed to accomplish and how it should accomplish it.)