Pascal from tiobe in top as 8 to position :)

[marcov]

I don't know, to be honest over the past few years, I ask myself if, for any production project, I would recommend to use Pascal at al

So you are starting to learn . Soon you'll be fully enlightened, and learn to never recommend a language for a production project.

The problem with suggesting a language yourself is that it only makes sense if it goes against the grain (read: whatever the manager read to be the "Industry standard" in some rag full of advertorials) . But if you name it, you own it, and every setback in the project it will be turned to be due to the choices you made.

[dtoffe]

I don't know, to be honest over the past few years, I ask myself if, for any production project, I would recommend to use Pascal at al

So you are starting to learn . Soon you'll be fully enlightened, and learn to never recommend a language for a production project.

The problem with suggesting a language yourself is that it only makes sense if it goes against the grain (read: whatever the manager read to be the "Industry standard" in some rag full of advertorials) . But if you name it, you own it, and every setback in the project it will be turned to be due to the choices you made.

This is Wisdom... Every word of it...

Daniel

[PascalDragon]

1. Range based typing is great, but it's not really enforced:

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

1. type
2.   TTest = -5..10;
3.  
4. var
5.   t: TTest;
6. begin
7.   t:=8;
8.   Inc(t,4);
9.   WriteLn(t); // 12????
10. end.

12 is not a valid value in -5..10. Why no overflow?

Then enable range checking! It's disabled by default by design due to performance impact, so if you want it enable it. Then this example will crash.

Also range based types are limited to native types, I can't make a range larger than QWord. Modern languages can easily do arbitrary sized integers, why is this so underutilized?

And such functionality should be part of the language instead of the runtime library, because...?

3. and 4. are great but way to limited. Sets are limited to domains of 256 elements. Associative arrays can only map ordinal types. Languages like Python or Swift can do set support and map support on a language level with arbitrary types. Pascal was the first language to introduce these concepts, but they never evolved. Languages that built upon those ideas do it way better.

Again, why should it be part of the language? It being part of the runtime library makes it much easier to implement alternatives not to mention that one can implement it now.

5. is by far the best feature in the language and was the basic inspiration for algebraic typesystems introduced in ML and today utilized in most modern languages (Swift or Rust Enums, Haskell datatypes, etc.) yet even though Pascal invented it, it's borderline unusable, because it does not support the most important type in Pascal: String. Variant records cannot hold managed types, making them completely useless for anything other than C union compatibility.

If you'd think for a minute why variant records don't allow managed types you'd understand it... 🙄

Or how operator overloading is partly broken with generics (e.g. only works for advanced records as they can have class operators),

It's not broken, it's just that specializing a generic establishes the scope that was active during the declaration of the generic. The specialization can't see operator overloads (or helpers) outside the parameter types, that is by design. (I do have plans to improve that however)

or that you can do encapsulation with properties, but for some reason can get the pointer to a property value completely taking this concept ad-absurdum.

We try to reduce the occurrences where the compiler allows it precisely for that reason.

Like except for some very superficial syntax aspects like begin-end isntead of { and }, Pascal has lost it's uniqueness.

Then you probably don't use virtual class methods which I miss especially from C++ quite a bit...

To touch on @Warfley's mention of no updates in about 4 years, there are a good number of simple features and bug fixes that could be incorporated into the compiler incrementally and easily.  There is no good reason to preempt simple features and simple bug fixes.

I'm not sure what the reason for the 4 year span has been but, I'm under the impression it has something to do with ARM support not being ready for prime time.  I think it is a bad idea to delay small incremental improvement for some feature that obviously requires a lot of work (supporting a new processor is a lot of work, never mind implementation, just adequate testing is a lot of work.)

This is the first release since the switch from SVN to GIT together with a new release manager (namely fpk instead of marcov), things need to fall in place first.

I think the problem is that the majority of "hard core" and well-known programs are written in other languages, usually C and/or C++.

Skype was one of the few major apps written in Pascal and, it is being retired.  New, widely used, hard core apps written in Pascal are not appearing.  That's what contributes to the growth of that cancer.

This is also true, because decision makers in those apps are typically not very well knowledgeable with Pascal. Moreover, companies still have a tendency of choosing languages whose replacement engineers are plenty. My ex-CTO in particular was very concerned about it, worrying nobody can maintain it if I left.

A pity that the talk by Ian from Embarcadero at the Pascal Conference wasn't recorded, cause I personally was quite surprised where Object Pascal is all used. It also makes one look at the future much more positively. 🥰

[440bx]

To touch on @Warfley's mention of no updates in about 4 years, there are a good number of simple features and bug fixes that could be incorporated into the compiler incrementally and easily.  There is no good reason to preempt simple features and simple bug fixes.

I'm not sure what the reason for the 4 year span has been but, I'm under the impression it has something to do with ARM support not being ready for prime time.  I think it is a bad idea to delay small incremental improvement for some feature that obviously requires a lot of work (supporting a new processor is a lot of work, never mind implementation, just adequate testing is a lot of work.)

This is the first release since the switch from SVN to GIT together with a new release manager (namely fpk instead of marcov), things need to fall in place first.

I can readily accept that the transition can take some time but, not 4 years.

I think there are some "deficiencies" in the update process.    For instance, some features are really trivial to implement, e.g, separating thousands with an underscore, that's so simple it should be included in whatever the next release is.   Some bugs also have simple solutions. 

I believe that the team should do everything it can to make the simple fixes and features available as quickly as possible.   If manpower is a problem, I am willing to pitch it.   I'd like to see a release every 6 months, which would normally consist of bug fixes (not necessarily all known bugs but those that have easy fixes that can be also be tested easily and thoroughly in a short period of time.)

Limiting some releases to bug fixes and very simple features means that the changes to the documentation can be minimal if any.  I think that a simple "addendum" should be enough.

I believe you can agree that going 4 years without even a bug fix release reflects poorly on the language and, that such a thing should not happen.

[PascalDragon]

For instance, some features are really trivial to implement, e.g, separating thousands with an underscore, that's so simple it should be included in whatever the next release is.   

Ehm... you are aware that this is in main? Just like many other things? The main problem isn't implementing new features or fixing bugs, it's release management and yes that is a valid reason, because release management of something as big as FPC is a nuisance, especially if you don't have dedicated people for this, but only people who work on this in their own f***ing free time. And if I don't have the muse to work on FPC for half a year or more then there is nothing anyone can do.

Some bugs also have simple solutions.

Again, main has many fixes, but main has also evolved away from 3.2.x, so if something can't be solved by simply cherry-picking the fix from main to 3.2.x then I won't merge it, because I have better things to do than to find out what changed.

[CM630]

Here is the status in probably the most popular jobs website in my country:

PHP (Tiobe Index 16): mentioned in 104 job positions

Kotlin (Tiobe Index 20): mentioned in 25 job positions

LabView (Tiobe Index 43): mentioned in 4 job positions

Delphi: 1 job position (a year ago it had 3 or 4 hits)

Lazarus: Mentioned in 0 job positions

Pascal: Mentioned in 0 job positions

FPC: Mentioned in 0 job positions

[440bx]

Again, main has many fixes, but main has also evolved away from 3.2.x, so if something can't be solved by simply cherry-picking the fix from main to 3.2.x then I won't merge it, because I have better things to do than to find out what changed.

It isn't my intention to be dense or demanding but, to continue with the thousands underscore separators.  It is my understanding, correct me if I'm wrong, that the thousands separator feature is _not_ part of the upcoming v3.2.4.  Honestly, I have a hard time understanding why. 

That's a feature that only involves the scanner and it is trivial to implement.  I don't think that the implementation and testing it to death would even take one full day.

I'm willing to do the work if that's what it takes to see it included in v3.2.4.

[Thaddy]

@440bx
Simple: it is not a FIX it is a feature. Does not belong in a fixes release.
Release management is difficult enough.

I have struggled enough in my life to support any thoughts otherwise.
Run your head into a wall, plz. Maybe, just maybe you wake up.
The reasons are / have been explained may times.

I will run my head into a wall if a fixes release get coerced into containing features.

[Warfley]

Then enable range checking! It's disabled by default by design due to performance impact, so if you want it enable it. Then this example will crash.

Sure, if I want a crash, but often you don't want crashes but overflow. There is this disconnect that ranges that coincide with byte sizes can be used for overflow while ranges that don't can't be used like that.

And such functionality should be part of the language instead of the runtime library, because...?

1. consistency, when I define 0..255 the compiler automatically chooses a 1 byte representations. With 0..65535 it chooses 2 bytes, etc. So the compiler transparently takes a range and generates code utilizing the optimal internal representation. That's great... But why stop ant Int64? Why can't I define myself Int128 that way?
Like sure it can be provided by the runtime (and AFAIK already is) but then the question is why have ranges at all and not just define the 8 basic types (singed/unsigned into 8-64 bit) and call it a day.
Effectively this feature in pascal gives no advantage over the C integer types

2. because pascal is a high level language that has a lot of features where you write things and the compiler "makes it happen". Taking this to the extreme, why does pascal need arrays, sets, classes etc in the first place? Those can all be provided by the runtime like in C.

Again, why should it be part of the language? It being part of the runtime library makes it much easier to implement alternatives not to mention that one can implement it now.

Languages should make common things easy, you can implement sets in runtime, yet pascal has language level sets. Same for dynamic arrays or strings.
In swift you can easily write a custom map type, yet the language provides maps on language level, because its such a fundamental datatype that it warrants a special syntax.

Again those are things pascal understood in the beginning, the language was explicitly designed to abstract such things to the language level.
Pascal was a revolutionary language in the 70s-90s, but for some reason we decided to freeze and now its a very conservative language? Thats a pretty big flip in philosophy

If you'd think for a minute why variant records don't allow managed types you'd understand it... 🙄

Yes, I thought about it,  I figured there is no reason why it doesn't work, and implemented it I to the FPC: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/822

It clearly can be done... So, what's the issue?

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/822
It's not broken, it's just that specializing a generic establishes the scope that was active during the declaration of the generic. The specialization can't see operator overloads (or helpers) outside the parameter types, that is by design. (I do have plans to improve that however)
[/quote]
Sure it's not broken it's just badly designed. But haskell solved this in the 90s, so...

[440bx]

@440bx
Simple: it is not a FIX it is a feature. Does not belong in a fixes release.
Release management is difficult enough.

I don't care whether it is a fix or a feature.  What I care about is that its implementation and testing is simple and straightforward.  Those are the characteristics that make a release less work and, THAT is what this compiler has been missing.

Main may have fixes and features BUT, it is not a formal, honest-to-goodness release, because of that it doesn't count.
 
If understanding the above is too complicated for you, I'm sure there is a wall nearby you can put to good use.

[Thaddy]

Well, you run first, maybe I do it later. Fixes is fixes: no new features. Otherwise use trunk.
This has nothing to do about being trivial.
E.g. the bug we found this morning for TStrings.Reverse has more chance, because that would be a fix, not a feature.

One should take pressure away from a release manager, not add to it.

[schuler]

We are ahead of: Perl, Go, Rust, PHP, Swift and Ruby.

CELEBRATION TIME!

[Kays]

[…] [Pascal] became popular more and more as 8 in position from tiobe nov 2025 !! […]

The fifteenth topic containing “TIOBE” in its title. Do we really need to stoop to this level and partake in this ████‑measuring contest? Show me another forum dedicated to a different programming language that is so obsessed with its ████ size as the Free Pascal/Lazarus forum is.

[…] getting started it may seem awful, e.g. mix between german and english identifiers (_KLAMMERAFFE is my favorite ), […]

I suggested to amend this but it was refused.