Lazarus

Free Pascal => General => Topic started by: Blade on April 11, 2021, 07:31:10 am

Title: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 07:31:10 am
[TOPIC split from Beginning Pascal (https://forum.lazarus.freepascal.org/index.php/topic,53149.0.html)]

Contemporary with what? >:-)

Of course I can't be speak for the OP, but my impression from various forums and the Internet is there is a odd and big disconnect between Pascal, Object Pascal, and Delphi in the minds of casuals.  There is also a lot of negative propaganda from C/C++/C# circles against Pascal specifically.  To include referring to old papers from Brian Kernighan, which do not reflect modern dialects of Pascal/Object Pascal, but used to bash Pascal anyway.  There is also no mention of Pascal/Object Pascal's various advantages over C, C++, and C#. 

Many casuals would have no idea that Delphi is just a product name, and the programming language is Object Pascal.  Nor would many realize that Pascal became Object Pascal.  This fragmented or limited awareness, can lead many thinking that Pascal is some old dead language, whose last incarnation was Turbo Pascal, or something like that.

I'm quite shocked to see people, some self-proclaimed experienced programmers included, who act like they can't do proper Internet searches (at the very least), and don't know about the evolution of Pascal to Object Pascal and then the various IDEs and compilers out there (which there are many).  A quick look at the wikipedia for Pascal (programming language) and Object Pascal should give people a clue (as the language has been evolving), but it seems a lot of people glance over that.

Oddly, YouTube (Google), appears to be doing something strange when it comes to searching for Pascal (programming language).  They might be putting their foot on the scale (algorithm) for corporate reasons or something is going on that doesn't make sense and doesn't happen in searches for other programming languages.  You will get a lot of these slick ignorant videos of "dying languages" or "don't learn these languages" in the results, thus giving a negative impression of Pascal.  In addition, search for Pascal/Object Pascal/Delphi, and get lots of videos for C#, C++, or Java in your search or suggestions.  Which is a bit disturbing, considering the list of Pascal/Object Pascal/Delphi videos are quite considerable to not do that.  Also, according to the controversial TIOBE index, Object Pascal/Delphi is ranked #12 (as of April 2021).  That is, Object Pascal/Delphi is ranked above Go, Kotlin, or Dart (Swift, Ruby, Julia, MATLAB, and other notables).  But, if the person doesn't specifically direct their YouTube search for Object Pascal or know that Delphi's programming language is Object Pascal, then they can be confused or unaware as to what is going on with the language in modern times.

Hopefully, the list of books and links we gave, should be quite helpful and informative about where contemporary Pascal/Object Pascal is at.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 11, 2021, 01:08:33 pm
@Blade I think you've summed things up very nicely there, and I'd definitely echo your point about "the experienced" apparently being totally inept when it comes to using Google and Wp intelligently... to the extent that a lot of questions on the Internet (not just relating to Pascal) are indistinguishable from truculent trolling.

I think the bottom line is that Object Pascal as a *language* hasn't changed that much since the Glory Days of Delphi. OK, it's gained generics and various syntactic sugar but by and large those are things of limited relevance to somebody looking for introductory material.

The *targets* have changed a lot, with the rise of webapps and Android-based devices, and the *implementations* have obviously changed with the rise of cross-platform Lazarus challenging Delphi's limited portability.

But OP specifically asked about Pascal, i.e the *language*... although I have obviously invited him to clarify that. And if he's asking about the language without qualifying it then from our POV he might be a rank tyro with no understanding of variables and control structures, in which case if there were an outstanding book from the UCSD or early Turbo Pascal era he would be unwise to exclude it as obsolete.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: silvestre on April 11, 2021, 01:19:47 pm
An excellent and synthetic text on some key issues in the field of pascal object language knowledge.

Surely companies like Embarcadero with financial resources available, should dedicate a small team to shed light on these old ignorances by updating forums and old entries that are relevant to internet searches, and which so many sadly take as true.


Contemporary with what? >:-)

Of course I can't be speak for the OP, but my impression from various forums and the Internet is there is a odd and big disconnect between Pascal, Object Pascal, and Delphi in the minds of casuals.  There is also a lot of negative propaganda from C/C++/C# circles against Pascal specifically.  To include referring to old papers from Brian Kernighan, which do not reflect modern dialects of Pascal/Object Pascal, but used to bash Pascal anyway.  There is also no mention of Pascal/Object Pascal's various advantages over C, C++, and C#. 

Many casuals would have no idea that Delphi is just a product name, and the programming language is Object Pascal.  Nor would many realize that Pascal became Object Pascal.  This fragmented or limited awareness, can lead many thinking that Pascal is some old dead language, whose last incarnation was Turbo Pascal, or something like that.

I'm quite shocked to see people, some self-proclaimed experienced programmers included, who act like they can't do proper Internet searches (at the very least), and don't know about the evolution of Pascal to Object Pascal and then the various IDEs and compilers out there (which there are many).  A quick look at the wikipedia for Pascal (programming language) and Object Pascal should give people a clue (as the language has been evolving), but it seems a lot of people glance over that.

Oddly, YouTube (Google), appears to be doing something strange when it comes to searching for Pascal (programming language).  They might be putting their foot on the scale (algorithm) for corporate reasons or something is going on that doesn't make sense and doesn't happen in searches for other programming languages.  You will get a lot of these slick ignorant videos of "dying languages" or "don't learn these languages" in the results, thus giving a negative impression of Pascal.  In addition, search for Pascal/Object Pascal/Delphi, and get lots of videos for C#, C++, or Java in your search or suggestions.  Which is a bit disturbing, considering the list of Pascal/Object Pascal/Delphi videos are quite considerable to not do that.  Also, according to the controversial TIOBE index, Object Pascal/Delphi is ranked #12 (as of April 2021).  That is, Object Pascal/Delphi is ranked above Go, Kotlin, or Dart (Swift, Ruby, Julia, MATLAB, and other notables).  But, if the person doesn't specifically direct their YouTube search for Object Pascal or know that Delphi's programming language is Object Pascal, then they can be confused or unaware as to what is going on with the language in modern times.

Hopefully, the list of books and links we gave, should be quite helpful and informative about where contemporary Pascal/Object Pascal is at.
Title: Re: Contemporary Pascal Discussion
Post by: 440bx on April 11, 2021, 02:24:27 pm
I believe the main problem with Pascal as a language is that there is no standard pascal.  The last standard dates back to 1982 (or 1990 if you include a standard that went nowhere.)

The bottom line is, there is no group of language experts dedicating time to improving and refining the language.  What there is, is a company (a Borland descendant) which will add any quick gimmick they can think of in order to get money from their customers.  That's no way of designing a programming language.

When someone looks at that situation, they cannot be blamed for perceiving Pascal as a dead language and, for the most part, in the industry, it is dead. 

The question posed in this thread underlines the situation.  Object Pascal in Delphi is different than Object Pascal in FPC.  Object Pascal in GPC is long dead and,  Apple which at one time was a "Pascal shop" abandoned the language long ago.  Which "flavor" (to put it kindly) of Pascal is a beginner supposed to learn ?... if you ask in this forum, the answer will be FPC and, if you ask someplace else, the answer will be different.

Contrast that with C (which even today is a rather sorry programming language) and the majority of compilers available support a fairly recent standard which means, a beginner can learn GPC and "move" to MSC or Intel C will little effort.  That's not the case with current flavors of Pascal.

Sad to say all that because I love Pascal but, its future is very limited and likely going to get more limited as time goes by.


Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 02:28:52 pm
Surely companies like Embarcadero with financial resources available, should dedicate a small team to shed light on these old ignorances by updating forums and old entries that are relevant to internet searches, and which so many sadly take as true.

Actually, I think Borland/Embarcadero added to the confusion.  It appears they tried to pull a fast one, where they would differentiate their product from Pascal/Object Pascal.  Thus they pushed Delphi real hard and as if a different programming language.  However, this backfired.  This is because a single product is not going to compare to the totality of a programming language with many products.  Being part of Object Pascal has strength, you then are comparable to C#, C++, Java, etc...

For instance, PyCharm is a popular IDE for Python, but it can't compare to Python as a whole nor in the consumer awareness of casuals.  If PyCharm fails or losses in popularity, people don't think Python has disappeared too.  You now can come out with some other product for Python, because it's still popular.  If people think PyCharm is it's own language, it causes confusion and won't necessarily help the cause over the long run.  If casuals think the "PyCharm language is dead", then it likely losses any consideration when they are choosing which language to use.  Pushing the programming language of your product, helps sales.

As it stands now, Embarcadero/Idera should definitely fight harder to push the Object Pascal language into consumer awareness.  By doing so, you establish the benefits and advantages of using the language, and then spur user demand for your product.  Because if Object Pascal dies, so does demand for Delphi.  Where I give Embarcadero/Idera some credit is maintaining their academic and school outreach.  Putting Delphi into schools and into the next generation hands is the right path.  If anything, crank that up a notch.

However, it seems Embarcadero/Idera wants to straddle the fence as much as possible.  Put their foot on whichever side of the fence (programming language) that looks good at the moment.  So despite them being known mainly for Delphi, they will get behind C++, C# (.NET) again if they could, or whatever if it looks like they can make a quick buck.  This thinking and strategy has mostly failed Borland and Embarcadero.  C++ Builder (or whatever other language builder) will likely never replace Delphi in consumer mind share, because that is what they are known for.  If anything, the success of C++ Builder is linked to and because of Delphi, and how things are done there.  Also, if you don't cultivate grass root support for the product you are known for, then it's like shooting a hole in your own foot.  When demand dries up, it will be much harder to sell those very expensive licenses.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 11, 2021, 02:44:45 pm
Frankly I don't think that Embarcadero (or whatever their name de jour) gives a damn. I believe that they bought the technology since it was their chosen development tool, and some in the company might even consider having other developers use it to be a threat to their flagship product line.

There's precedent: JPI/TopSpeed imploded because "something of questionable legality" happened in the USA, and as a result it was absorbed by Clarion who were probably their biggest individual customer. I believe that Clarion is still using derivatives of the same software, but they have no interest at all in selling it to anybody else.

It might be that the fact that Lazarus/FPC is modestly successful, i.e. indicating that there is still a measure of interest in Object Pascal wider than just Delphi, is enough to convince Embarcadero that they can't just drop Delphi since doing so would lead their shareholders to ask why they've cut off a modest revenue stream.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 02:52:17 pm
Contrast that with C (which even today is a rather sorry programming language) and the majority of compilers available support a fairly recent standard which means, a beginner can learn GPC and "move" to MSC or Intel C will little effort.  That's not the case with current flavors of Pascal.

Sad to say all that because I love Pascal but, its future is very limited and likely going to get more limited as time goes by.

I agree with you about the standards issue, but part of the rest I will have to disagree.  Other programming languages have issues moving between IDEs/compilers too.  Using C/C++ in Visual Studio and then GCC, can be problematic depending on what you are doing.  Though there isn't a recent official Object Pascal standard, the different flavors do somewhat synchronize with Delphi's flavor.  Enough so, that jumping to or between different IDEs/compilers is doable.  The flavors of the language are similar enough.  In fact, the differences can be an advantage, depending on what the person wants to do.  Many people on this forum have jumped between different IDEs, or have used say Delphi material or sites for mastering the fundamentals of Object Pascal before using Free Pascal/Lazarus (which makes this easier with compatibility modes). 

I also think that Object Pascal has a bright future.  That there are several IDEs/compilers out there is a reflection of it.  If a person knows Object Pascal, they can adjust to say PascalABC's or Oxygene's flavor of the language (or those users to Free Pascal's flavor), if there is something in particular that they want. 
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 02:57:12 pm
It might be that the fact that Lazarus/FPC is modestly successful, i.e. indicating that there is still a measure of interest in Object Pascal wider than just Delphi, is enough to convince Embarcadero that they can't just drop Delphi since doing so would lead their shareholders to ask why they've cut off a modest revenue stream.

I definitely think that if Embarcadero makes a false step or drops Delphi, there will be a flood over to Free Pascal/Lazarus.  In addition, Free Pascal/Lazarus success has helped prop up Delphi, because of consumer awareness of the language in general and since there is compatibility.
Title: Re: Contemporary Pascal Discussion
Post by: pathfinder on April 11, 2021, 03:15:13 pm
Quote
The bottom line is, there is no group of language experts dedicating time to improving and refining the language.  What there is, is a company (a Borland descendant) which will add any quick gimmick they can think of in order to get money from their customers.  That's no way of designing a programming language.

There was an intent to update the standard in 1993, but there was a perceived lack of interest, so it never went any farther.

Quote
I also think that Object Pascal has a bright future.


Unfortunately, not in the commercial world it doesn't. 
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 03:59:24 pm
Unfortunately, not in the commercial world it doesn't.

1st, if Embarcadero/Idera or RemObjects (and some others) were losing money, they would have dropped Delphi and Oxygene long ago.  And not talking existing/past customers, they have to sustain a level of growth.

2nd, the benchmark is not that Object Pascal has to match the top 10.  Go, Kotlin, Dart, Swift, Rust, etc... are not in the top 10 either, but nobody thinks their languages are "failures" because they aren't or try to press home a false narrative that they have no future. 

Nor have those languages ever been at or near the top, like Pascal, Object Pascal, and Delphi have.  In regards to Pascal and variants, we are talking about a language that has maintained significant momentum for over 50 years.  A considerable achievement that few languages can say have done better.  As we speak, TIOBE (controversy aside) has Object Pascal/Delphi ranked at #12.  There are a whole lot of languages below it.  Funny, don't hear people claiming all those lower ranked languages have "no commercial future".
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 11, 2021, 04:26:21 pm
But OP specifically asked about Pascal, i.e the *language*... although I have obviously invited him to clarify that. And if he's asking about the language without qualifying it then from our POV he might be a rank tyro with no understanding of variables and control structures, in which case if there were an outstanding book from the UCSD or early Turbo Pascal era he would be unwise to exclude it as obsolete.

I agree with you that many of the old Pascal books have significant value for learning the basics and fundamentals.  If a person is starting from say zero (don't know if that is the OP's situation), jumping straight to OOP and generics is not doable.  Not to mention, part of the point of Pascal, was that it's easier to learn.  It can be a much more enjoyable experience and less frustrating getting up to speed with it.

You can take many of those older quality Pascal books and learn everything up to say basic algorithms and record data types.  Then from around there, you now can jump into the modern Pascal dialects with OOP and the newer goodies.  And even with just the basics/fundamentals (lets put this line at say arrays and records), there is whole lot a person can do.
Title: Re: Contemporary Pascal Discussion
Post by: alpine on April 11, 2021, 04:45:47 pm
I agree with you that many of the old Pascal books have significant value for learning the basics and fundamentals.  If a person is starting from say zero (don't know if that is the OP's situation), jumping straight to OOP and generics is not doable.  Not to mention, part of the point of Pascal, was that it's easier to learn.  It can be a much more enjoyable experience and less frustrating getting up to speed with it.

IMHO, the 'classic' Pascal is an irreplaceable tool for learning programming as a first PL. I'm personally feeling lucky that long ago I've started with Pascal and a copy of 'Algorithms + Data Structures = Programs'. Then, I moved to C/C++ and whatever. Never participated in so called 'flame wars', Pascal vs C, JavaVM vs CLR, SQL vs NoSQL, etc. Everything has it place when your mind is 'structured' at the very beginning  ;)

Regards,
Title: Re: Contemporary Pascal Discussion
Post by: 440bx on April 11, 2021, 09:47:11 pm
Using C/C++ in Visual Studio and then GCC, can be problematic depending on what you are doing.
but that's true when the programmer chooses to use extensions that are specific to an implementation.  If the programmer sticks to one of the C standards, moving from one C compiler to another is usually fairly simple.  That cannot be said of Pascal because Delphi's object Pascal is not a standard and Delphi's object Pascal is riddled with contradictions and inconsistencies that would not survive in a bona fide standard.

Enough so, that jumping to or between different IDEs/compilers is doable.  The flavors of the language are similar enough.
Yes, it's doable but, when dealing with "real programs" it is not simple and making a single source to compile and execute successfully with the various flavors can only be done when limiting oneself to the lowest denominator.  IOW, a lot of useful features in one implementation or another have to be left unused. 


I also think that Object Pascal has a bright future.
I really hope you're right.  I'd love to see Pascal being as popular as it was in the days of Turbo Pascal 3 & 4 but, I honestly don't see that happening any time soon.

If a person knows Object Pascal, they can adjust to say PascalABC's or Oxygene's flavor of the language (or those users to Free Pascal's flavor), if there is something in particular that they want.
There is no doubt that adjusting to one flavor or another is possible but, not having a capable and portable definition across platforms is a very significant problem.  That's what C and C++ gives programmers and the industry and, it's quite likely that is a very significant portion of their success (same with Java.)

Pascal needs a "northstar".
Title: Re: Contemporary Pascal Discussion
Post by: ASBzone on April 11, 2021, 10:18:18 pm
As we speak, TIOBE (controversy aside) has Object Pascal/Delphi ranked at #12.  There are a whole lot of languages below it.  Funny, don't hear people claiming all those lower ranked languages have "no commercial future".

Overall, you have articulated well in your posts, and I largely agree with your points.

I do believe that there is an anti-Pascal sentiment that exists, but there is one other thing to consider.    There may still be quite a few people quietly using Pascal who are not performing internet searches with the regularity of other languages, and thus depriving the planet of those kinds of flawed metrics.  :)
Title: Re: Contemporary Pascal Discussion
Post by: lucamar on April 11, 2021, 11:08:53 pm
There may still be quite a few people quietly using Pascal who are not performing internet searches with the regularity of other languages, and thus depriving the planet of those kinds of flawed metrics.  :)

IMHO Pascal is in that category of languages for which most of its users are fairly advanced and need rather less "help", or more specialized than what the general web (including stackoverflow) offers, so we are not quite as visible as others.

Think, say, of COBOL programers (which are still legion), or RPG, or even Fortran. When I was programming in COBOL, the last place I went for help was Google or SO; a couple posts in Usenet and/or specialized forums (or even a couple phone calls) found way better answers to my questions and much more quickly :)

But those, of course, are not used when indexes like TIOBE are generated.

ETA a funny anecdote: I was once in an observatory for some software-related thing or other and in the middle of our talk a guy in a lab coat entered and asked something like: "how did you call that function for the trajectory of blackish oblong-shaped bodies crossing the heliosphere?". He was writing a Fortran program running on an RS6000. Those people, clearly, don't Google: they just walk to the next lab room and ask :D
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 11, 2021, 11:09:39 pm
I believe the main problem with Pascal as a language is that there is no standard pascal.  The last standard dates back to 1982 (or 1990 if you include a standard that went nowhere.)

IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code). Pascal was not one of them after the eighties, and to be frank few others have been since Ada.

Some older ones, like the standards body of C and C++ have become self propelling entities, while some extremely languages like C# and Java remain one vendor only (with sometimes a few satellites), and it hasn't braked them one bit.

If the lack of standards signifies anything, then it is the lack of fat government contracts in the eighties :)

Title: Re: Contemporary Pascal Discussion
Post by: 440bx on April 12, 2021, 12:27:14 am
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code).
But, it's not just that.  When an employer is looking for a programmer, if the programmer is well-versed in the current language standard then that programmer will quickly become productive.

With Pascal it's a different story, a programmer well versed in the last Pascal standard has a long ways to go to become proficient in FPC or Delphi.  Not to mention all the cases that are "undefined territory" in the current implementations which are traps for a programmer.

A programming language needs a formal definition to make it in the industry and real interest from highly qualified language designers to improve the language over the years.

Today, the Pascal language has no direction.  Whatever Embarcadero/idera/whoever dreams of, is it, whether good or bad.

Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 10:00:32 am
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code). Pascal was not one of them after the eighties, and to be frank few others have been since Ada.

Pascal might have been hurt by the assumption that it would be replaced by Modula-2, standardisation of which was marginally more successful than that of Pascal.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 02:06:20 pm
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code).
But, it's not just that.  When an employer is looking for a programmer, if the programmer is well-versed in the current language standard then that programmer will quickly become productive.

Recent standard knowledge can be used to test if the programmer hasn't been asleep at his desk for the last 15 years, but there are many  other things you can ask. You don't need a standard for that.

Quote
With Pascal it's a different story, a programmer well versed in the last Pascal standard has a long ways to go to become proficient in FPC or Delphi.  Not to mention all the cases that are "undefined territory" in the current implementations which are traps for a programmer.

Yeah, which is why you ask about recent Delphi or FPC versions and extensions. Same goal. But not a reason for a standard.

Quote
A programming language needs a formal definition to make it in the industry and real interest from highly qualified language designers to improve the language over the years.

A formal description of some sort can be an help to implementers. But there must be implementers to begin with, and usually there are not.  As said, the C/C++ case is a historic exception that became self propelling.

Quote
Today, the Pascal language has no direction.  Whatever Embarcadero/idera/whoever dreams of, is it, whether good or bad.

I agree somewhat, but a standard would change nothing there wrt popularity. What you need is a big wealthy patron or Cause célèbre.

You are confusing origin and effect of the standards. They are there because C was popular and inherently multi vendor from the start, because Unix was like that because AT&T couldn't capitalize on it due to the conditions of the Bell competition breakup process. And then suddenly your apps need to be portable only on source level, rather than a binary standard (though AT&T tried to change that with the IBCS standard).

Without multiple vendors chomping at the bits, such reasoning is futile.
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 02:12:31 pm
IMHO standards are there to unify vendors that want to standardize, usually for big US government contracts in the Unix sphere(where applications are traditionally delivered in source code). Pascal was not one of them after the eighties, and to be frank few others have been since Ada.

Pascal might have been hurt by the assumption that it would be replaced by Modula-2, standardisation of which was marginally more successful than that of Pascal.

I don't know. The situation is quite complex.  But I think the main problem is that the Pascal standardization didn't cater for dialects on micros (UCSD and later TP, which came out in the year of Pascal Ansi standardization), which in the end mostly won out. Probably it was simply too mainframe centric (keep in mind Pascal originated on CDC and was popular on Burroughs).

I think the M2 case is mostly sterile, an early attempt that got some following, but the problems usually start with later iterations. I always found most standards discussions in c.l.m2 to be counterproductive
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 02:28:55 pm
@Marcov as you say the situation is complex. But even in the 80s (the original standard was 1983) I got the impression that it wasn't taken particularly seriously... apart from anything else there were (IIRC) still holes in its I/O specification which could have been the result of trying to fit it to disparate architectures (record-based mainframes vs stream-based minis).

I recall very little interest in it on Burroughs kit. One of the American universities had a compiler and patched their MCP to raise additional exceptions (nil pointers being identified by the otherwise-unused tag 6 IIRC) but by and large derivatives of the Burroughs-supplied ALGOL were dominant. Wirth left Stanford before actively working on Pascal so their B5500 wasn't really relevant, Pascal was available on the B20 (single-user UNIX) and I think that there was something UCSD-like on the Modular Terminals that they introduced in the early 80s... and that was about it as far as I know. One or two research compilers but I don't think they had particularly wide use.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 12, 2021, 02:52:44 pm
I believe the main problem with Pascal as a language is that there is no standard pascal.  The last standard dates back to 1982 (or 1990 if you include a standard that went nowhere.)

There was an intent to update the standard in 1993, but there was a perceived lack of interest, so it never went any farther.

True (there was a technical committee), but I don't know if it was necessarily a lack of interest that a standard didn't come out, but maybe lack of vendor buy-in as to what the committee was doing.  For instance at that time Borland already had released Turbo Pascal 6, which had its own take on OOP.  Think Pascal (popular back then) was in conflict over Apple's implementation of Object Pascal.  The committee was proposing things like multiple inheritance, which can be very problematic.  So what the committee was proposing might not have been something that various vendors wanted or they could have taken issue with it.  I suppose more research on that has to be done for clarification.

http://www.pascal-central.com/OOE-stds.html#sect-6.3.2 (http://www.pascal-central.com/OOE-stds.html#sect-6.3.2)
(Object-Oriented Extensions to Pascal, Technical Committee X3J9)

Some older ones, like the standards body of C and C++ have become self propelling entities, while some extremely languages like C# and Java remain one vendor only (with sometimes a few satellites), and it hasn't braked them one bit.

I also agree with Marcov, that people don't seem to get hot and bothered by C# and Java.  C# was last "standardized" by the ISO in 2003.  Appears Sun just said, "Screw it!", and went down their own path.

The bottom line is, there is no group of language experts dedicating time to improving and refining the language.  What there is, is a company (a Borland descendant) which will add any quick gimmick they can think of in order to get money from their customers.  That's no way of designing a programming language.

As for the direction that Borland/Embarcadero often goes down, I agree with you about "any quick gimmick they can think of in order to get money".  Which sadly appears to degrade the quality of Delphi.

In regards to standardizing Object Pascal in these times, looks like a difficult hill.  Each of the vendors are trying to differentiate their product in some way (for example Oxygene and PascalABC are dancing with .NET), so buy-in looks hard.  I think one of the few ways to push buy-in would be to get Niklaus Wirth back involved, but he has diverted a lot of his attention elsewhere to his other "children" languages.  Object Pascal was also conceived by Apple (look up Larry Tesler), with consolation from Wirth, but Apple passed the baton to Borland/Embarcadero.  Which brings us right back to how would you get different vendors to support the standard.

Possibly another way forward is through Free Pascal/Lazarus creating their own certification exams.  It would do at least 3 things.  1) Help fund Free Pascal/Lazarus like books sales do. 2) Spark the interests of casuals, enthusiasts, students, and those wanting to make career changes.  3) Promote more Object Pascal awareness in the job and commercial market.

It can initially be something along the lines of what w3schools or the Embarcadero Delphi Certified Developer exam is doing.  These are not exams done under a professional proctor (exception being Delphi Master Developer), but taken over the Internet from a web server.  In the case of w3schools, they have a kind of "verifier", who is a person the exam taker submits as a witness or endorser (and their name is on the certificate).  Embarcadero has 2 levels, regular developer and master developer.  Level 1 is no professional proctor.  Level 2 (master developer), must have a professional proctor, but appears to be a lot of hassle must be done to make arrangements.  Probably either of these testing patterns (w3schools or Embarcadero), could initially work for the Free Pascal/Lazarus foundation.  Maybe at some point, Embarcadero could join in with a vendor neutral Level 1 Object Pascal exam, then Level 2 could be more vendor specific.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 03:24:19 pm
Possibly another way forward is through Free Pascal/Lazarus creating their own certification exams.

(With a nod to whoever posted earlier about the desirability of simplifying things in order to solve problems.)

OTOH, that would have the effect of locking down the language, confirming the presence of things in the core which might be usefully moved into optional libraries or packages.

Please don't ask for examples there, or for a description of what compiler facilities exist to support moving stuff out of the core. It's intended as a hypothetical situation, but I think it's still germane to the discussion.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: alpine on April 12, 2021, 03:46:28 pm
Don't you think that a survey should be made about the motives of those who switched to the FPC/Lazarus before considering how to promote it?
After all, the ones mentioned so far are just speculations.

Regards,
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 12, 2021, 09:21:05 pm
I think what is often ignored when considering pascal is, how niche this language is.

Most people using FPC and Lazarus came from Delphi, and Delphi is only relevant in the corporate world. There are some interesting projects like this (https://www.benfrederickson.com/ranking-programming-languages-by-github-users/) or this (https://githut.info/) where all public github repositories are searched through and track the popularity of languages. Pascal does not make it in the top 50 list, and are behind languages like Puppy, Logos or Elixir, which I have never even heard of.

This results in a lot of people simply having never heard of pascal, while knowing about C#, Python and the other languages.
The problem therefore isn't that much of people not using pascal because they got dissuaded from using it, but rather they don't use it, because they simply do not know of it's existence.

Also, the whole terminology is kinda weird. So the language family is Pascal, which contains multiple versions like the standardized ISO pascal or Object Pascal. Object Pascal is also not really a language but a kind of sub family, Delphi and the language the FPC uses (mode objfpc), where I don't even know the proper name for, are different dialects of ObjectPascal, which are vastly different in many regards. Then besides the language there is also the development tools, you can say about branding what you want, but it was a smart move by embarcadero/Borland, who ever was in charge back then, to call everything, from the language to the IDE and buildsystem simply Delphi. We on the other hand have Lazarus, which is not only an IDE but also the main buildsystem, and package manager, and internally uses the fpc, which is a general Pascal compiler.
So you have people talking about Lazarus, or about Object Pascal or about FreePascal, all basically talking about the same thing with different terminology. When I have to google something pascal related, I often google 3 times, once "lazarus ..." then "fpc ..." and then "pascal ...", sometimes even "delphi ...". Some questions in this forum about visual components are directly addressing the LCL, others are framed as general pascal questions (case in point, look at how many questions about components are in the general subforum rather the LCL subforum).

Sure technically these things have all different meanings, but are often used interchangebly. How should an outsider get a picture of this, if there we (the Pascal community) can't even decide on a coherent vocabulary?
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 09:49:24 pm
Discounting BASIC (including a vast array of BASIC-like embedded scripting languages) I think the only language quite so fractured is LISP.

I speculated a few days ago (although possibly not in this thread) that the majority of working programmers probably hadn't been born at the time of Pascal's heyday, so assuming they've heard of it is unreasonable.

However they've definitely come across its legacy, even if they don't realise it.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 10:14:04 pm
I think what is often ignored when considering pascal is, how niche this language is.

Nonsense. It has a stronghold as a workhorse for an older audience, so it simply doesn't show up in these popularity contests focussed on fads. And even less so if they are US centric, having a historic stronghold in Europe.

It is also not a language in which applications are distributed in source to be integrated by somebody else, which generates a lot of noise from integrating.

You won't hear me arguing Pascal is the most popular language in the world, or even dispute that it is on the wane, but the view from these sad language-listings-by-google demonstrates more the fundamental problem with this way of ranking rather than prove something with the absence of Delphi or pascal.

Such ranking measures what is sexy, and what people want to talk about, rather than what they use.

In the mid 2000s .NET 2 came out everybody wanted to jump ship, and I have seen the colleagues categorically entering C# in surveys and blog about it, while they were only testdriving it, while Delphi brought home the bacon. In the early 2010s, I've seen them enter LAMP as platform, but ignoring that they actually did IIS+PHP+delphi backend.  They enter what they tinker with.

Yes, Delphi is only getting smaller, and yes, sometimes they in the end converted to those technologies. But not always, and sometimes in the end they converted to something else (which e.g. was not an IT darling, but a development system that somehow had a foodhold in their vertical market).

It is like dating sites. What people say online, and reality significantly diverges. Specially if you are in a unpopular category.

Quote
Most people using FPC and Lazarus came from Delphi, and Delphi is only relevant in the corporate world.

Odd. For my feeling Delphi is mostly one person shops or one person IT departments. Teams more often conform to IT trends (rightly so or not)

Quote
Also, the whole terminology is kinda weird. So the language family is Pascal, which contains multiple versions like the standardized ISO pascal or Object Pascal. Object Pascal is also not really a language but a kind of sub family, Delphi and the language the FPC uses (mode objfpc), where I don't even know the proper name for, are different dialects of ObjectPascal, which are vastly different in many regards.

By that measure we should have all refused javascript because of the horrible confusion it causes with Java. Stop dragging things into the discussion by the hairs.
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 10:16:17 pm
Discounting BASIC (including a vast array of BASIC-like embedded scripting languages) I think the only language quite so fractured is LISP.

One dialect, one (Embarcadero) and a half(Free Pascal) vendor . I think most languages are more fragmented. :)

Sure, if you count all historic variants and a few far removed experiments like the various attempts to pascalize C# and Java's syntax you can get there.

But in reality, Borland dialects and compilers have been dominant for twice as long as many other mainstream languages exist. Aside from a marginally but measurable bunch of Turbo and Delphi clones (FPC included), the rest is noise only brought up in language debate.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 10:18:59 pm
Odd. For my feeling Delphi is mostly one person shops or one person IT departments. Teams more often conform to IT trends (rightly so or not)

But if that's really the case how has Borland and its successors managed to keep going after investing GOK how much to make Delphi into an enterprise-level development tool?

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 12, 2021, 10:23:20 pm
This results in a lot of people simply having never heard of pascal, while knowing about C#, Python and the other languages.
The problem therefore isn't that much of people not using pascal because they got dissuaded from using it, but rather they don't use it, because they simply do not know of it's existence.

....How should an outsider get a picture of this, if there we (the Pascal community) can't even decide on a coherent vocabulary?

Seems to me that the different dialects have to rally around the Object Pascal label, to push language recognition.  In the more well known programming languages, vendors don't go around pretending their IDE/compiler is some different language or try to hide what it uses.  The creators of PyCharm are proud to call it a Python IDE, nor do they try to pass it off as the "PyCharm language".  They understand that pushing the programming language into the mind share of casuals will benefit them overall.

As far as dissuading people from using Pascal, I will have to disagree.  There appears to be a significant effort to bash Pascal in C/C++/C# circles.  It is something embedded into their culture and has roots back into numerous Pascal VS C published papers in the early 1980s. Arguably, Pascal was perceived as a threat or unwanted competition, and some of those dots connect back to AT&T (to include Bell Labs), where they had specific commercial interests and agendas.  And the huge mess between Microsoft and Borland that lead up to the creation of C# was as plain ugly as can be.

Possibly a good way to counter some of the brand confusion and/or gain more mind share among casuals and businesses is certifications.  This puts control of the story and explaining the benefits of Object Pascal in the hands of its community.  Pascal/Delphi already has a good reputation among many schools in various countries as an educational tool, so an Object Pascal certification could add to this.  If nothing else, it will spread greater awareness.
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 10:37:05 pm
Odd. For my feeling Delphi is mostly one person shops or one person IT departments. Teams more often conform to IT trends (rightly so or not)

But if that's really the case how has Borland and its successors managed to keep going after investing GOK how much to make Delphi into an enterprise-level development tool?

Same as the language popularity contests bit, I replied to Warfley.  Big ticket features on the box that are talked about and used as upgrade reason, and what people actually use it for differ vastly in reality.

And usually the real reasons are boring. Legacy, done investments, not enough business of an uniform kind to justify costly and complex migrations. (*)

They have been harping on about portability for ages now, but I rarely see people use it, and if they do it is pretty peripheral (e.g. a subset app for a few OS X users), and the shared source principle is strenuous to say the least, specially longer term.

Ninety percent of the people that I know use VCL, and while they sometimes played with other targets and there is an occasional OS X project, most of it is just Windows.

With the mandatory subscription there is even less of a connect between features and reason for upgrading.

(*) I actually convinced my boss last Friday to allow to prepare a C++ (and then specifically MSVC MFC) migration over several years. But then we landed a big order today, so the time got cut for practical reasons before I even started. Again. Ah well, no sales is worse :-)
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 12, 2021, 10:42:11 pm
There appears to be a significant effort to bash Pascal in C/C++/C# circles.

And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.

"We're not having that in the compiler, it's too C-like".

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: skalogryz on April 12, 2021, 10:50:05 pm
And usually the real reasons are boring. Legacy, done investments, not enough business of an uniform kind to justify costly and complex migrations. (*)
Legacy

The biggest reason on unsuccess of Embarcadero's Oxygen. (it's not compatible with Delphi and there's no "easy migration")

The biggest problem for C++ language. The language cannot become slim as it has to support all the old features together with new features as well.
There's no "automated" tool to port the old code into new standards.
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 12, 2021, 11:16:07 pm
And usually the real reasons are boring. Legacy, done investments, not enough business of an uniform kind to justify costly and complex migrations. (*)
Legacy

The biggest reason on unsuccess of Embarcadero's Oxygen. (it's not compatible with Delphi and there's no "easy migration")

Oxygen is Remobjects. I personally never understood the base premise to begin with. The best thing I could come up with is people with a twisted love-hate relation with .NET that on one hand wanted to conform, and on the other hand not.

Quote
The biggest problem for C++ language. The language cannot become slim as it has to support all the old features together with new features as well.

Well, one could argue that it is simply the fate of real general purpose languages. They stay for long and amass large bodies of code. Languages that are connected to one framework or application necessarily evolve with it, and old code is pointless.

Also see the link I replied to MarkMLI about string types and conversions. That is not top-down designed with a sober mind :-)

Quote
There's no "automated" tool to port the old code into new standards.

There rarely is. Conversion tools usually are only a help, and the best ones are not open. If your codebase is large enough and relatively uniform, having a specialized conversion company can be worth it though.

Rarely worth it for vision apps :-)
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 13, 2021, 12:51:16 am
You won't hear me arguing Pascal is the most popular language in the world, or even dispute that it is on the wane, but the view from these sad language-listings-by-google demonstrates more the fundamental problem with this way of ranking rather than prove something with the absence of Delphi or pascal.

Such ranking measures what is sexy, and what people want to talk about, rather than what they use.

In the mid 2000s .NET 2 came out everybody wanted to jump ship, and I have seen the colleagues categorically entering C# in surveys and blog about it, while they were only testdriving it, while Delphi brought home the bacon. In the early 2010s, I've seen them enter LAMP as platform, but ignoring that they actually did IIS+PHP+delphi backend.  They enter what they tinker with.
The rankings I posted searched through every public project on github, these where no surveys of developers, this does literally measure what is used by people and not what people want to talk about.

As github is the largest open source platform by far I think it is fair to say that at least with repect to open source projects Pascal is not really popular


Quote
By that measure we should have all refused javascript because of the horrible confusion it causes with Java. Stop dragging things into the discussion by the hairs.
Well, I actually remember a time where this actualy lead to a lot of confusion, this was back when JavaScript wasn't as prevalent as it is now and Java Applets where still used heaviely on the web. I was active in a general programming forum back then (2012ish) and there was at least once a week a question confusing the two
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 13, 2021, 01:27:47 am
...As github is the largest open source platform by far..

I remember reading an article that GitHub only is not a good judge of language popularity by itself.  Much more of Pascal content is pre GitHub era, and many projects are at SourceForge or on websites.  Where users of a programming language mainly get their content or solutions are relative, to include how they use it can be significantly different.  Comparisons need to be more comprehensive, and include many sources.

Title: Re: Contemporary Pascal Discussion
Post by: PierceNg on April 13, 2021, 02:07:26 am
Discounting BASIC (including a vast array of BASIC-like embedded scripting languages) I think the only language quite so fractured is LISP.

One dialect, one (Embarcadero) and a half(Free Pascal) vendor . I think most languages are more fragmented. :)

Pascal is not particularly better or worse in this aspect. Consider Smalltalk, another perenially dying language: Two dominant commercial vendors, some other niche commercial products, and several open source implementations, all unmistakeably Smalltalk, all different enough that code is not write once compile  anywhere. Experienced practitioners can and do move among the implementations. Nobody seems bothered that each implementation goes beyond the language standard in different ways.

Or Common Lisp, similarly two big vendors, some smaller niche vendors, and quite a few open source implementations.
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 13, 2021, 02:54:37 am
I remember reading an article that GitHub only is not a good judge of language popularity by itself.  Much more of Pascal content is pre GitHub era, and many projects are at SourceForge or on websites.  Where users of a programming language mainly get their content or solutions are relative, to include how they use it can be significantly different.  Comparisons need to be more comprehensive, and include many sources.
Well, sourceforge is pretty dead, it hosts around half a million open source projects, github surpassed the 100 million mark in 2018. The latest number I could find was that around 1.3% of all sourceforge projects where Pascal projects (in 2013), meaning 65 thousand projects, this would make up 0.00065% of all github projects. Haskell, which is on place 25 makes up 0.39%.
So I think it is fair to say that SF does not make a dent in the numbers.

That said, SF is also stagnating with regards to the project numbers, meaning even if SF was really big and Pascal would be a major share of these projects, this would still only mean that pascal was very prominent in the past. And this isn't even surprising, around D7 times, Delphi was really big.
But today there are simply more programmers than ever, just look at these numbers, in 2009 around SF was with 200k projects considered really big, now this is less than a percantage of GitHub. I don't even think that Pascal is actually declining in usage in absolute numbers, but it is not growing as much as other languages.

What should be kept in mind is that these numbers are of course only Open Source projects, and what I think plays a major role is that OpenSource is simply not so big in the Pascal Community as it is in other development communities. It feels like the concept of non FOSS "freeware" is much more prevalent than in other languages, but this is just a feeling and is really hard to check.

Not so long ago at my university, whenever I told someone I was programming in pascal like 70% of students simply did not know what Pascal is, and we are talking about computer science students, so the kind of people you would expect the most to know about this sort of stuff. From my own experience the only people I knew that used pascal where people who once worked with Delphi usually in a professional setting (i.e. by working in a company that used Delphi since D7 or even earlier and sticked to it), or people that used to learn programming in the 2000s or earlier (like me, I first came into contact with Delphi in like 2005ish). As I said, it's not that Pascal has a bad wrap, at least with the new generation of software developers, it is more that these people simply do not know about pascal, except maybe having heard the name once as one of these "ancient" languages (like Cobol or Algol).

Personally I don't believe Pascal is dead, far from it, but it is a niche language, which has it's solid userbase, maybe is even growing in absolute terms, but I don't think that it will ever compete with the big languages like back in the TP early Delphi days.
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 13, 2021, 08:46:03 am
Not so long ago at my university, whenever I told someone I was programming in pascal like 70% of students simply did not know what Pascal is, and we are talking about computer science students, so the kind of people you would expect the most to know about this sort of stuff. From my own experience the only people I knew that used pascal where people who once worked with Delphi usually in a professional setting (i.e. by working in a company that used Delphi since D7 or even earlier and sticked to it), or people that used to learn programming in the 2000s or earlier (like me, I first came into contact with Delphi in like 2005ish). As I said, it's not that Pascal has a bad wrap, at least with the new generation of software developers, it is more that these people simply do not know about pascal, except maybe having heard the name once as one of these "ancient" languages (like Cobol or Algol).

In looking at what is taught at schools, you have to be careful not to take the situation of one country (say the USA), and think it is the same for others.  Let's remember that the USA is the birth place of Unix (in terms of being built with C), and languages like; C, C++, C#, and Java.  These were pushed by huge world reach American companies like AT&T (back then), Microsoft, Sun (before Oracle), etc...  So it's no surprise how strong their influence is within the USA. 

However, South Africa, for example uses the Delphi dialect in their high schools and colleges.  They and many other countries have a more neutral perspective on programming languages, and can favor variants of Pascal because of its teaching value and design.  South Africa evaluated Java and other languages head to head, then choose Delphi for their high schools. 

https://www.techteachers.co.za/page/2/?s=delphi+exam (https://www.techteachers.co.za/page/2/?s=delphi+exam)
(South African use of the Delphi dialect in their schools)

https://youtu.be/cRLxaBnANQ4  (https://youtu.be/cRLxaBnANQ4)
(Teaching programming with Delphi dialect)

Not just South Africa either.  Some flavor of Pascal, Turbo Pascal (as free now), Object Pascal (Delphi, Lazarus, PascalABC, etc...) specifically is taught in various school systems throughout the world.  An example list: Russia, Ukraine, Turkey, Romania, Serbia, Czech, Belgium, Croatia, Bulgaria, Hungary, Italy, Jamaica, Libya, Moldova, Tunisia, Argentina, Costa Rica, Brazil...

Then in support of what is taught in the schools, you have many Pascal/Object Pascal/Delphi websites related to teaching the language.  It is definitely a base and situation from which Object Pascal can grow stronger, from school use to more generalized use.  This is why I also think an Object Pascal certification program can catch on and increase awareness.

http://pp4s.co.uk/ (http://pp4s.co.uk/)
(Pascal Programming For Schools)

More recently, Turkey (2020) did the same thing as South Africa.  Evaluated several programming languages for their schools, then chose Delphi over the others.  Bought 1 million academic licenses from Embarcadero.

https://www.schoolinfosystem.org/2020/01/25/turkey-buys-delphi-licenses-for-an-estimated-one-million-students/ (https://www.schoolinfosystem.org/2020/01/25/turkey-buys-delphi-licenses-for-an-estimated-one-million-students/)
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 13, 2021, 09:36:19 am
There appears to be a significant effort to bash Pascal in C/C++/C# circles.

And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.

"We're not having that in the compiler, it's too C-like".

And how is that denigrating?
Title: Re: Contemporary Pascal Discussion
Post by: PascalDragon on April 13, 2021, 09:50:34 am
There appears to be a significant effort to bash Pascal in C/C++/C# circles.

And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.

"We're not having that in the compiler, it's too C-like".

And we'll say similar about features that are too Java-like or too Python-like or too Whatever-like. The point is new features need to fit nicely into the Pascal feeling (and really extend the language) and more often then not the syntaxes of other languages (especially the "curly bracket" ones) simply do not.
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 13, 2021, 10:10:49 am
And we'll say similar about features that are too Java-like or too Python-like or too Whatever-like. The point is new features need to fit nicely into the Pascal feeling (and really extend the language) and more often then not the syntaxes of other languages (especially the "curly bracket" ones) simply do not.

Agreed.  Also, Niklaus Wirth clearly had a particular design for programming languages in mind.  Well-structured programs, with high readability and maintainability, that could be more easily understood, used, and taught.

Putting anything into the language because it's a fad/gimmick somewhere else or covers some deficiency of another language, may not fit Free Pascal or be an overall negative in the long term.  Maintaining the design principles and integrity of the language, by being careful and thoughtful about what gets integrated, is a good thing.
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 13, 2021, 10:54:40 am
In looking at what is taught at schools, you have to be careful not to take the situation of one country (say the USA), and think it is the same for others.  Let's remember that the USA is the birth place of Unix (in terms of being built with C), and languages like; C, C++, C#, and Java.  These were pushed by huge world reach American companies like AT&T (back then), Microsoft, Sun (before Oracle), etc...  So it's no surprise how strong their influence is within the USA. 
It's not only what is tought, many languages are well known even though they aren't tought. In my country (Germany) most universities tech Java in the general programming class, C and Assembly as part of the operating system class and Matlab in math classes. But still most students know about C++, C#, JavaScript, Python or PHP.
Of course being shoved down students throats helps to make students aware of them, but some languages manage be well known without this
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 13, 2021, 11:01:54 am
There may still be quite a few people quietly using Pascal who are not performing internet searches with the regularity of other languages, and thus depriving the planet of those kinds of flawed metrics.  :)

IMHO Pascal is in that category of languages for which most of its users are fairly advanced and need rather less "help", or more specialized than what the general web (including stackoverflow) offers, so we are not quite as visible as others.

Think, say, of COBOL programers (which are still legion), or RPG, or even Fortran. When I was programming in COBOL, the last place I went for help was Google or SO; a couple posts in Usenet and/or specialized forums (or even a couple phone calls) found way better answers to my questions and much more quickly :)

But those, of course, are not used when indexes like TIOBE are generated.

I do think there is something to this.  The list of old Pascal books is very extensive for teaching basics.  Not to mention that some of the contemporary Pascal/Delphi ebooks and electronic manuals are quite thorough in terms of covering basics.  There are also a significant number of well established Pascal/Delphi teaching websites too (for example- http://www.delphibasics.co.uk/ (http://www.delphibasics.co.uk/)). 

Pascal is just simply an easier language to learn, when we are talking basics, so I think its users have less need for Stack Overflow.  Quality answers can also be found in books and Pascal/Delphi specific websites (https://wiki.freepascal.org/ (https://wiki.freepascal.org/) is very much included).  If people get deeply stuck, they are more likely doing some very advanced stuff.  If they are near or at professional level, those people tend to read.  They are likely to buy books, actually dig deep into the reference manuals, or do extensive research.

If you dig deep enough and use the correct search terms, even YouTube can be a valuable resource as well.  The issue is how Pascal, Object Pascal, and Delphi are often treated as different search terms with varying results. 

The way that people use and get their information about a programming language can be very different.  So, Stack Overflow can be way more of a resource for a particular language, and not so much for another.  That's why I think one has to be careful in how usage is evaluated.
Title: Re: Contemporary Pascal Discussion
Post by: ASBzone on April 14, 2021, 06:53:44 pm
As far as dissuading people from using Pascal, I will have to disagree.  There appears to be a significant effort to bash Pascal in C/C++/C# circles.  It is something embedded into their culture and has roots back into numerous Pascal VS C published papers in the early 1980s.

I saw this play out in real-time when Delphi 1 came on the scene, and my good friend, who was a stellar VisualBasic developer, took an immediate liking to Delphi.  He essentially became an evangelist of it.   Our mutual boss, however, was a big Microsoft/VB proponent, and he made it hard for us to move forward with Delphi.  My friend basically had to do significant work on his own time to make better apps or migrate our existing apps to Delphi to show how much better, and faster they were, without all that run-time foolishness.

Bossman finally relented.  Grudgingly.  But he never bought into the support and training that was needed for our team, and always assumed that Delphi would go the way of the Dodo at some point.   My friend eventually went on to another org where he introduced them to Delphi and led a team managing software development.

There has definitely been an active disinformation campaign against Pascal for years.  Even many people who don't know the language, know about (and, sadly, in some cases support) the hatred from the C/C++ community in particular.

If finding corporate support for Lazarus/FPC were easier, there could *potentially* be a great deal of good that could result from this.  Potentially.
Title: Re: Contemporary Pascal Discussion
Post by: ASBzone on April 14, 2021, 06:57:42 pm
There appears to be a significant effort to bash Pascal in C/C++/C# circles.

And there's an unacceptable amount of C denigration (can I use that word these days?) in the Pascal community.

"We're not having that in the compiler, it's too C-like".

MarkMLl

But is that really C denigration?

Quite a few of the people who program in ObjectPascal here also program in C or C++.  There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.

That's not the same as constantly bashing C/C++ as a language.
Title: Re: Contemporary Pascal Discussion
Post by: PascalDragon on April 15, 2021, 09:18:26 am
Quite a few of the people who program in ObjectPascal here also program in C or C++.  There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.

Correct. I actively use C++ at work to earn my living.
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 15, 2021, 08:49:10 pm
But is that really C denigration?

Quite a few of the people who program in ObjectPascal here also program in C or C++.  There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.

That's not the same as constantly bashing C/C++ as a language.

Agree.  Because C/C++/C# has something, doesn't mean that it fits the design and usage of Object Pascal.  And there could already be a different way that Object Pascal does it to accomplish the same/similar goals that a beginner or user of another language is not aware of.
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 16, 2021, 01:14:30 am
Pascal does not make it in the top 50 list, and are behind languages like Puppy, Logos or Elixir, which I have never even heard of.
Я даже не смотрю эти рейтинги. Они что-то поменяют для меня? Для тех кто пользуется паскалем?
google translate: I don't even look at these ratings. Will they change something for me? For those who use pascal?

As far as dissuading people from using Pascal, I will have to disagree.  There appears to be a significant effort to bash Pascal in C/C++/C# circles.  It is something embedded into their culture and has roots back into numerous Pascal VS C published papers in the early 1980s. Arguably, Pascal was perceived as a threat or unwanted competition, and some of those dots connect back to AT&T (to include Bell Labs), where they had specific commercial interests and agendas.
Да, сейчас паскаль "затаптывают" по всем фронтам. Там даже Delphi XE - ни чего сделать не может. Происходит очень сильное давление в сетях/соцсетях и других источниках информации - указывая, что Паскаль устарел и ни где не используется.
google translate: Yes, now Pascal is being "trampled" on all fronts. Delphi XE - and that is not visible. There is a very strong pressure on networks / social networks and other sources of information - by all means showing that Pascal is outdated and not used anywhere.

Warfley, я думаю вам не надо всё оценивать по общим статистикам. Сообщество Паскаля развивается. Люди об этом знают, и в наших силах чтоб об этом узнало больше людей!  ;)
google translate: I think you don't need to judge everything by general statistics. Pascal's community is evolving. People know about it, and it is in our power to make more people know about it! ;)

Quite a few of the people who program in ObjectPascal here also program in C or C++.  There are not opposed to C and the role it plays, but to making Lazarus/FPC look more like C, when its goal and objectives are different.

That's not the same as constantly bashing C/C++ as a language.
И... как бы я не хотел не изучать C/C++ похоже мне тоже придётся его использовать...
google translate: And ... as much as I would not like not to learn C/C ++, it looks like I will have to use it too ...
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 16, 2021, 06:47:14 am
Я даже не смотрю эти рейтинги. Они что-то поменяют для меня? Для тех кто пользуется паскалем?
google translate: I don't even look at these ratings. Will they change something for me? For those who use pascal?

...

Warfley, я думаю вам не надо всё оценивать по общим статистикам. Сообщество Паскаля развивается. Люди об этом знают, и в наших силах чтоб об этом узнало больше людей!  ;)
google translate: I think you don't need to judge everything by general statistics. Pascal's community is evolving. People know about it, and it is in our power to make more people know about it! ;)

Well, when I start a new project, the question which language and environment to use is always one of the first questions I ask myself, and as such I need to compare the languages on, at least mostly, objective measures, and such statistics can be very useful there.

Let me give you three examples for projects where the popularity matters. Let's consider the following, a chat using state of the art encryption techniques. So as a developer I can't be knowledgable on everything, so I rely on the works of others in form of libraries. This is especially true for crypto. There are so many forms of different attack techniques, and if your application is not hardened against them, you could simply not use crypto at all. So crypto libraries are a key, they should be well tested and maintained. So what are the options for doing crypto with Pascal (FPC+Lazarus in particular), well there is only one "big" crypto library for Pascal, DCPCrypt. It is/was maintained by a single guy (according to commit history) and the last updates were commited in 2014, which where only formating and cvs specific updates. The last real code updates came 2009, 12 years ago. It is also had only 61 downloads last week.
I mean I love pascal, but I would never use a library for security critical issues that hasn't been updated in more than a decade. There is no such thing as bug free software, and if a software that hasn't had any bugs fixed for a long time, this either means a lack of testing, or a lack of development effort or both.
So looking around other languages, we see that for python there is the big library pycryptodome, which is continuation of pycrypto, which also exists at least since 2002, and still gets bugs reported and fixed to this day (the last major version was released in feb). So if I am going to make something using cryptography, I would pretty much always choose python over pascal.

Besides technical issues with a community that small, there are also accessibility issues, especially if you do a lot of open source development. Let's consider the following, you write an application for a specific topic, something you are really into, like a tracker for sport games or something like that, basically for some kind of community (doesn't even need to be large, you might want to simply write a gag program for your friends or colleagues). You want to share that program with the community, so you make it open source. If your program is well liked it might get picked up by others from the community and continue with the project or build new things around your core, thats the beauty of open source. The thing is to make that happen your code must be accessible to others.
I like pascal, and if I thought it is a dead language, I wouldn't waste my time using it. I write and publish libraries for fpc and lazarus because I think it is worth while to extend the infrastructure available. The thing is, if I write code I want to share with others, people I know are not interested or able (e.g. due to a lack of time) to learn pascal, I bascially already burried my code before writing it, simply by choosing an unpopular language.
Of course what is "popular" depends on the community in question, if you write a simple gag program for your colleagues at an office where you only use C++, this might be the popular choice, in the same context that C++ code wouldn't be the best choice for something targetet to the users of this forum. The thing is, if you are targeting an open source audience, if you want your code to thrive, popularity is key.

Lastly there is also the issue of response time. If you find a bug withing a largly popular project like the gcc or .Net and you report it, it is often fixed within days, and shipped with hotfixes immediately (if it is a severe bug that is). I know I've written about this now pretty often, but it fits here well. I came into the situation (more then once), that I discovered a breaking bug in the FPC, breaking in the sense that there was no working around this in my project, without starting from the beginning redesigning the whole structure of the program. The fpc has a small development team, which has to ration their time, and can't fix every bug. So this is not to blame anyone, I can completely understand this, but as a result I had to abandon whole projects and throw weeks of work away. I mean these were fun projects, so it's not that big a deal, but this is something that literally has never happend to me with any of the popular languages, because there is much more testing and manpower behind it.
It should be noted that FPC does not have any hotfixes or so, bugfixes are always shipped with the next version, meaning even if your bug is fixed, unless you want to work on unstable/development code, or apply patches yourself, you probably won't see that fix for months.

Popularity, or better lack there of, can have a lot of impact on the whole software development process, it might make a software unfeasable due to lack of libraries and support infrastructure even before the a single line of code was already written, it might render your code dead on arrival as no one is willing or able to engage with that code, or it can mean that all of your efforts come to a halt because you stumble upon an issue you can't solve on your own, and the support community is simply not large enough to handle each issue, and your problem isn't top of the priority list.
And again, I love pascal, but when I decide to make a new project and consider all the programming languages out there, popularity is a factor to consider. Of course not the only one, and by far not the most important one, but it can't be dismissed
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 16, 2021, 07:40:13 am
Most people using FPC and Lazarus came from Delphi, and Delphi is only relevant in the corporate world. There are some interesting projects like this (https://www.benfrederickson.com/ranking-programming-languages-by-github-users/) or this (https://githut.info/) where all public github repositories are searched through and track the popularity of languages. Pascal does not make it in the top 50 list, and are behind languages like Puppy, Logos or Elixir, which I have never even heard of.

On this particular point, I think Pascal is simply hard to track in comparison to other languages:

1) First problem is the name. Pascal, Object Pascal, Delphi, PascalABC, Oxygene, FreePascal, DWScript, Modern Pascal, etc...

If the proper search terms are not put in, no telling what you will get.  People use the modern dialects of Pascal, which may have various different names and labels.

2) Many people don't seem to consider extensions of Pascal, as Pascal.

It's weird, but if it isn't ISO 1983 or ISO 1990 Pascal, then it isn't "real Pascal" to various critics.  But their favorite pet language might not have ever been ISO standardized or not any time recently.  Then when you talk about Object Pascal, it starts to get really weird.  Even though Embarcadero clearly states on their website for a number of Delphi product pages that it is Object Pascal, there are those that consider it a different language or don't even associate it with Pascal.

I partially think this kind of refusal to accept the modern dialects of Pascal, as "real" Pascal, is an attempt in some circles to pigeonhole and glue the language to the negative criticisms of the early 1980s in many of those C VS Pascal reports.  To be blind that Pascal evolved into Object Pascal and solved many old issues, makes it a stronger or too strong of a competitor to handle.

https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_Language (https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_Language)

https://news.ycombinator.com/item?id=19221143 (https://news.ycombinator.com/item?id=19221143)

https://news.ycombinator.com/item?id=22222117 (https://news.ycombinator.com/item?id=22222117)

Sample of other 1980s era C VS Pascal papers, besides Brian Kernighan (there are many)

https://link.springer.com/content/pdf/10.1007/3-540-09745-7_3.pdf (https://link.springer.com/content/pdf/10.1007/3-540-09745-7_3.pdf)
(Pascal versus C : A subjective comparison)

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.5244&rep=rep1&type=pdf (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.5244&rep=rep1&type=pdf)
(Comparison of the Programming Languages C and PASCAL )
Note- Alan Feuer and Narain Gehani are from AT&T Bell Labs (birthplace of C/C++)

3) The way in which people use, get answers, and get information about a programming language is different.

In Pascal circles, many people would get answers from say the Free Pascal forum, Delphi Basics, Delphi PRAXis, etc...  This includes various forums specific to the flavor of Object Pascal IDE that they are using, like for instance PascalABC or Oxygene.  Where with other programming languages, their people might tend to swarm on Stack Overflow.  This is partly language culture.  After some time, it can become a preferred way for a majority of users to get answers a particular way.

4) Other programming languages can be more confusing or difficult to use, so their users need more help.

Along those lines, it can be that up to a certain level, Pascal is just more easily understood.  We also have to add to this, that Pascal was designed to be easier to learn and that a lot of people were exposed to it at school.  On the other hand, other programming languages can be way more difficult to grasp, so their users get "stuck easier", and have an overload of questions that need answers.

5) Object Pascal, the secret weapon.

Lastly, people can be quietly using modern flavors of Pascal for a competitive edge.  It's working for them personally or their company, so don't have a need to broadcast.  However, though I can understand this point of view, I do think it's time for Object Pascal to come out into the light and get its due credit.  This would be helpful to a new generation of programmers, in terms of options.
Title: Re: Contemporary Pascal Discussion
Post by: 440bx on April 16, 2021, 07:53:19 am
It's weird, but if it isn't ISO 1983 or ISO 1990 Pascal, then it isn't "real Pascal" to various critics.  Then when you talk about Object Pascal, it starts to get really weird. 
Considering Object Pascal as not being "real Pascal" is reasonable.  The current incarnation(s) of Object Pascal would have never come into existence if Pascal had evolved in a rational and logical manner.  The current incarnations have design blunders that make anyone with some passing familiarity in language design jaw drop. 

Borland and its descendants gleefully bastardized the Pascal language for money.  It worked for a while but, the cow is running out of milk.

Fortunately, the essence of the language is not completely gone (yet.)
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 16, 2021, 07:54:37 am
I love pascal
Давайте будем честны! Вы его не любите! Для того, кто любит - нет преград!  :)

Практически всё что вы мне ответили это: просто высосанная из пальца проблема. Всё и всегда можно сделать! Есть желание - делаем! Нет желания - ищем проблему на стороне.

Если нужны новые библиотеки, берём внешние и используем их для своего усмотрения. Нет возможности пользоваться внешней библиотекой? Конвертируем код, исправляем ошибки - пользуемся.

Хотим поделиться кодом? Да пожалуйста! На любом языке программирования! (Я не изучал C/C++ но код я читаю!) Программист, который достаточно находится в программировании, должен уметь читать чужой код! Иначе, зачем такой программист нужен?  :)

Да, поддержка языка ведётся малой командой. В одном случае это хорошо, в другом плохо. Чем меньше команда, тем более слажено (зачастую) они работают. Каждый занимается своим делом. А сообщество Паскаля помогает в поиске существующих проблем. Некоторые из них надо решать немедленно, потому что они достаточно критичны, но многие могут подождать.

Разработчикам FPC - надо выразить огромную благодарность за то, что данный паскаль существует! Мало того, что существует, он компилирует код (именно компилирует!), а не как множество других - интерпретирует.

Боюсь с вами диалог надо заканчивать, вам не интересен паскаль, вы здесь пытаетесь внести раскол.
Всего доброго!

google translate: Let's be honest! You don't love him! For the one who loves - there are no barriers! :)

Almost all that you answered me is: just a problem sucked from the finger. Everything can always be done! There is a desire - we do it! There is no desire - we are looking for a problem on the side.

If we need new libraries, we take external ones and use them at our discretion. Can't use an external library? We convert the code, fix errors - use it.

Want to share your code? Yes please! In any programming language! (I haven't studied C / C ++, but I do read code!) A programmer who is sufficiently into programming should be able to read someone else's code! Otherwise, why is such a programmer needed? :)

Yes, the language is supported by a small team. In one case it is good, in the other it is bad. The smaller the team, the more well-coordinated (often) they work. Everyone does their own thing. And Pascal's community helps in finding existing problems. Some of them need to be addressed immediately because they are critical enough, but many can wait.

To the FPC developers - a huge thank you that this pascal exists! Not only does it exist, it compiles the code (it compiles it!), And not like many others - it interprets it.

I'm afraid we need to end the dialogue with you, you are not interested in Pascal, you are trying to create a split here.
All the best!
Title: Re: Contemporary Pascal Discussion
Post by: 440bx on April 16, 2021, 08:02:55 am
A programmer who is sufficiently into programming should be able to read someone else's code! Otherwise, why is such a programmer needed? :)
The problem isn't ability.  The "problem" is that a programmer is entitled to protect his mental health by not reading code that is obviously detrimental to it.  The U.S Founding Fathers anticipated the appearance of lousy programs by including the 8th Amendment in the Bill of Rights: "no cruel and unusual punishment", is to be tolerated in any form (source or object.)

Title: Re: Contemporary Pascal Discussion
Post by: PierceNg on April 16, 2021, 08:39:25 am
1) First problem is the name. Pascal, Object Pascal, Delphi, PascalABC, Oxygene, FreePascal, DWScript, Modern Pascal, etc...

C and C++ each has many implementations that a programmer may choose. Basic? Too many to count. Python 2 and Python 3 have been in use simultaneously for years. Not to mention Common Lisp, Scheme, Smalltalk etc. especially with the modern penchant to transpile, initially to Java, now to Javascript. Maybe only Perl 5, in between killing off Perl 4 and waiting for Perl 6, was sole king of one particular programming language ecosystem.

Name is only a problem for people who use single-implementation languages exclusively.
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 16, 2021, 08:51:47 am
]The problem isn't ability.  The "problem" is that a programmer is entitled to protect his mental health by not reading code that is obviously detrimental to it.  The U.S Founding Fathers anticipated the appearance of lousy programs by including the 8th Amendment in the Bill of Rights: "no cruel and unusual punishment", is to be tolerated in any form (source or object.)
"Хорошие времена порождают плохих программистов"...
Ваш ответ очень хорошо к ассемблеру применим. Не хочешь изучать - не изучай. И наплевать, что он, в большинстве случаев, нужен.  :)
google translate: "Good times breed bad programmers" ...
Your answer applies very well to assembler. If you don’t want to learn assembler, don’t. And do not care that, in most cases, he is needed. :)
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 09:13:18 am
A programmer who is sufficiently into programming should be able to read someone else's code!

(~R∊R∘.×R)/R←1↓ιR

Unless you are familiar not only with the language but with the idioms that experienced users of the language use to solve problems you have no chance of maintaining programs written in it.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 16, 2021, 09:21:38 am
1) First problem is the name. Pascal, Object Pascal, Delphi, PascalABC, Oxygene, FreePascal, DWScript, Modern Pascal, etc...

C and C++ each has many implementations that a programmer may choose. Basic? Too many to count. Python 2 and Python 3 have been in use simultaneously for years. Not to mention Common Lisp, Scheme, Smalltalk etc. especially with the modern penchant to transpile, initially to Java, now to Javascript. Maybe only Perl 5, in between killing off Perl 4 and waiting for Perl 6, was sole king of one particular programming language ecosystem.

Name is only a problem for people who use single-implementation languages exclusively.

In other languages, usually the IDEs and compilers are classified under the same umbrella and belonging to that language.  With Pascal, many perceive the different IDEs and compilers are belonging to different languages.  Antagonists, place Delphi or Oxygene (for example) as their own languages that have no relationship to Object Pascal or Pascal (despite their owners and websites saying they are Object Pascal). 

This was the problem with TIOBE.  They changed the classification of Delphi to its own language, so that both Object Pascal and Delphi rankings could drop.  Oxygene and other dialects of Object Pascal were not counted.

Then there is the argument of Object Pascal and Pascal.  As Object Pascal is an extension of Pascal, does that make it a separate language or should it be considered part of the same?  It can be argued that Object Pascal is the modern version of Pascal.  Keep in mind to, that OOP draft documents (1993) had been made by technical committees for Pascal to be officially added.  OOP being added, would not make Pascal something other.

If you count Pascal/Object Pascal/Delphi together, their rankings would be much higher and probably would surprise a lot of people.  In regards to TIOBE, probably would be in the top 10.  As it is, Object Pascal/Delphi, without some of its variants and Pascal are ranked at #12.  However, with the classification of Pascal ranked by itself and much lower, it's fuel to dump on the language and claim it's dead.  Interestingly, nobody calls the old Pascal as Classic Pascal to clarify it's time period.  Thus adding to the confusion, as to what is or is not Pascal and its true ranking. 

Take the example of Python 1, Python 2, and Python 3.  Despite some very significant changes, such as Python 3 being not completely backward compatible with Python 2, they are still considered Python.  Why can't that be the case in regards to Pascal and Object Pascal?  Pascal is still significantly compatible with its extension, Object Pascal.  It's interesting that a compatible extension is not considered part of the language, where a somewhat incompatible revision (Python 2 vs Python 3) is considered the same language.
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 16, 2021, 09:25:17 am
Lastly there is also the issue of response time. If you find a bug withing a largly popular project like the gcc or .Net and you report it, it is often fixed within days, and shipped with hotfixes immediately (if it is a severe bug that is).

So does smartlinking finally work with GCC then? FPC supported smartlinking since the last millennium, even a time with the same binutils that gcc uses.

Which compiler first worked for Win64 ?
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 09:35:09 am
So does smartlinking finally work with GCC then? FPC supported smartlinking since the last millennium, even a time with the same binutils that gcc uses.

I believe so, but I don't know what the granularity is.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 09:38:52 am
The fpc has a small development team, which has to ration their time, and can't fix every bug.

Which was in part why I suggested in the "Post-Pascal" thread that perhaps the language (not just the compiler) could be usefully refactored so that a larger proportion of bugs could be fixed without having to meddle with the core compiler and make demands of the core team's limited resources.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 16, 2021, 09:52:58 am
A programmer who is sufficiently into programming should be able to read someone else's code!

(~R∊R∘.×R)/R←1↓ιR

Unless you are familiar not only with the language but with the idioms that experienced users of the language use to solve problems you have no chance of maintaining programs written in it.

MarkMLl
Давайте будем объективными! Я писал - читать код! Для его поддержки надо больше чем уметь читать чужой код - его надо уметь переносить или менять язык программирования.  :)
google translate: Let's be objective! I wrote - read the code! To support it, you need more than being able to read someone else's code - you need to be able to port it, or change the programming language. :)
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 10:04:36 am
google translate: Let's be objective! I wrote - read the code! To support it, you need more than being able to read someone else's code - you need to be able to port it, or change the programming language. :)

Exactly: you need to be able to understand the idioms being used by the original programmer, and if necessary to switch to idioms more appropriate for the tools you're using. APL and just about everything else use different idioms, contemporary Pascal and even a fairly closely related language like C use different idioms.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 16, 2021, 10:46:46 am
So does smartlinking finally work with GCC then? FPC supported smartlinking since the last millennium, even a time with the same binutils that gcc uses.

I believe so, but I don't know what the granularity is.

Symbol granularity of course. I believe it can eliminate a whole .o, but that is often rare so doesn't count.

The last I heard in 2016/17 timeframe was that it was slowly getting to a decent development stage for COFF, but it wasn't really end-user stuff yet.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 11:27:18 am
Symbol granularity of course. I believe it can eliminate a whole .o, but that is often rare so doesn't count.

The last I heard in 2016/17 timeframe was that it was slowly getting to a decent development stage for COFF, but it wasn't really end-user stuff yet.

The point I was trying to make is that the intended granularity might be a symbol, but I don't know where they've got to in practice.

In any event, I've looked through the I/O handling on more than one C/C++ development board environment, and the bottom line is that they work so hard at being portable and general-purpose that doing something simple like changing the state of an LED takes a substantial number of uSec if done "the right way". The only real fix for that is to pick and choose and build new libraries, although in principle, a good compiler should be able to inline the nested functions, recognise board-specific constants and optimise the syntax tree.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 16, 2021, 11:43:23 am
The point I was trying to make is that the intended granularity might be a symbol, but I don't know where they've got to in practice.

To be clear: It's not so much gcc that I worry about, but binutils-on-windows, as it is a linker feature. But you don't have much choice if you want to use gcc on Windows.

Quote
In any event, I've looked through the I/O handling on more than one C/C++ development board environment, and the bottom line is that they work so hard at being portable and general-purpose that doing something simple like changing the state of an LED takes a substantial number of uSec if done "the right way".

Well, that is ok on our C/C++ cpu. 10Mhz is easily doable, and might even go as high as 35MHz. (actually we use this to make sure we configured the chip right, as toggling frequency is instruction clock/2 for read/write/modify). But we need to use an intrinsic for that too.

In reality of course you use a hardware peripheral (OC/PWM) for toggling because that is more regular, and frees up CPU.
Title: Re: Contemporary Pascal Discussion
Post by: dseligo on April 16, 2021, 12:20:12 pm
So this is not to blame anyone, I can completely understand this, but as a result I had to abandon whole projects and throw weeks of work away.

Can you give an example of a bug like this one you had mentioned here?
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 16, 2021, 03:37:18 pm
google translate: Let's be honest! You don't love him! For the one who loves - there are no barriers! :)
I love pascal, but I am not stupid, I won't choose it blindly for everything, I will always choose the language that I consider right for the job, zealously using only your favourite language only limits your ability

Quote
If we need new libraries, we take external ones and use them at our discretion. Can't use an external library? We convert the code, fix errors - use it.
Fair point, but using external libraries comes with it's own can of worms (e.g. you need to translate between high level constructs like classes or dynamic types to low level constructs for the library, which can result in more work and even more bug potential), and converting and fixing code is again running into the problem that if you don't know what you are doing (e.g. because you aren't a crypto expert), you probably shouldn't be doing it.

Quote
Want to share your code? Yes please! In any programming language! (I haven't studied C / C ++, but I do read code!) A programmer who is sufficiently into programming should be able to read someone else's code! Otherwise, why is such a programmer needed? :)

It's not about reading code, it's about other people using your code. Most programmers are fine with reading any code they like, but when it comes to extend on it or work on it, this is a completely different topic. In the worst case the thing you described earlier happens, and someone decides to use your code because they like it, but comvert it to another language. Now you have just halfed the productivity that could go into that project, and potentially just created two dead projects instead of one thats alive.

Quote
Yes, the language is supported by a small team. In one case it is good, in the other it is bad. The smaller the team, the more well-coordinated (often) they work. Everyone does their own thing. And Pascal's community helps in finding existing problems. Some of them need to be addressed immediately because they are critical enough, but many can wait.
The last breaking bug I reported was over a year ago and wasn't touched since then. Just imagine this wasn't a fun project, was something a client had payed me for. Should I just tell him: "I use this very niche language, it is really great, but it might be that the program you request can be delayed by several years due to compiler bugs". What do you think will the response be? Probably something along the lines: "Then why do you use that language, and why should I pay you for it?".

Quote
I'm afraid we need to end the dialogue with you, you are not interested in Pascal, you are trying to create a split here.
All the best!
How dare you to tell me I am not interested in pascal? I spend a lot of my free time developing open source libraries for pascal, because I believe that Pascal is a great language and I want to do my best to extend the existing infrastructure.

But as I said, languages are nothing but tools, and when I start a new project, my first and foremost goal is to archive the best result possible. This includes using the right tools for the job. You can use a hammer for putting skrews in to the wall, but I reckon that using a skrew driver will give better results. It's the same for programming languages. I have used dozens of different languages in the past, and every of them has it's advantages and disadvatages, all are designed in a way that make them more fit for some purposes and less fit for others.

You wrote that you haven't studied C/C++ (leaving the fact that C and C++ are two different languages and studying one of them is already an act in itself), well I have (at least C++, my C is really bad), and let me tell you this, there are situations in which C++ is better suited for a program than pascal, that is, you will archive the same if not better results with less effort, but there are also situations where the roles are switched, where pascal is the better choice.
As a software developer it's your due dilligence to provide the best product in the most efficient manner, what this means in detail depends on your requirements, and if you choose your tools knowing that there are other tools out there better fitted for that purpose, you are giving up on that premise.
And of course you can do what you want, but personally won't choose to create an inferior product just because I wanted to use my favorite toy.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 16, 2021, 04:29:34 pm
... let me tell you this, there are situations in which C++ is better suited for a program than pascal, that is, you will archive the same if not better results with less effort, but there are also situations where the roles are switched, where pascal is the better choice.

And anybody who tries to argue that since both are Turing Complete they are completely equivalent doesn't know what he's talking about.

I agree: there are some things for which C/C++ are better, and some for which (Object) Pascal is better. And there are many situations where a mix would be better... which was of course the (largely unfulfilled) promise of .NET.

I came across this in the Python documentation/headers:


Py_BEGIN_ALLOW_THREADS

    This macro expands to { PyThreadState *_save; _save = PyEval_SaveThread();.
Note that it contains an opening brace; it must be matched with a following
Py_END_ALLOW_THREADS macro. See above for further discussion of this macro.

Py_END_ALLOW_THREADS

    This macro expands to PyEval_RestoreThread(_save); }. Note that it contains a closing
brace; it must be matched with an earlier Py_BEGIN_ALLOW_THREADS macro. See
above for further discussion of this macro.


Leaving aside for the moment Pascal's lack of a decent macro preprocessor, and leaving aside the potential hazards of allowing semi-skilled users to define block-local variables (I think that one's been argued to death over the last few weeks): you quite simply /can't/ /do/ that sort of thing in Pascal without resorting to a separate TList (using the heap, hence potentially contributing to fragmentation) or whatever, and I can sympathise with users of other block-structured languages who consider themselves skilled and cautious but are aghast at such omissions.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 17, 2021, 12:41:21 am
Warfley, я признаю, в чём-то я мог быть не прав! Не стоит заводится из-за слов! Но всё что вы пишите - больше воспринимается как неприязнь к Паскалю!

google translate: I admit, in some ways I could be wrong! Don't get turned on by words! But everything that you write is more perceived as a dislike for Pascal!

I love pascal, but I am not stupid, I won't choose it blindly for everything, I will always choose the language that I consider right for the job, zealously using only your favourite language only limits your ability
Quote
Fair point, but using external libraries comes with it's own can of worms (e.g. you need to translate between high level constructs like classes or dynamic types to low level constructs for the library, which can result in more work and even more bug potential), and converting and fixing code is again running into the problem that if you don't know what you are doing (e.g. because you aren't a crypto expert), you probably shouldn't be doing it.
Если мне нужно, я использую Паскаль. Нет не решаемых проблем!
Да, я признаю, что зачастую это затратная и не благодарная "работа". Если нужна срочность, то проще сделать работу на другом языке, если у вас есть возможность.

google translate: If I need to, I use Pascal. There are no unsolvable problems!
Yes, I admit that this is often a costly and unrewarding "job". If urgency is needed, it is easier to do the work in another language if you have the opportunity.

Quote
It's not about reading code, it's about other people using your code. Most programmers are fine with reading any code they like, but when it comes to extend on it or work on it, this is a completely different topic. In the worst case the thing you described earlier happens, and someone decides to use your code because they like it, but comvert it to another language. Now you have just halfed the productivity that could go into that project, and potentially just created two dead projects instead of one thats alive.
По этому поводу можно спорить и спорить. Но проблема тут не в Паскале! Многие проекты рождаются "мёртворождёными": потому что они не продуманы; потому что не хватило терпения; потому что просто бросили проект; потому что не видят цели проекта... можно продолжать до бесконечности. На том же GitHub больше заброшенных проектов, которые ни кому не нужны. Из них на паскале, даже 1% не наберётся.

google translate: On this occasion, one can argue and argue. But Pascal is not the problem! Many projects are born "dead": because they are not thought out; because there was not enough patience; because they just abandoned the project; because they do not see the purpose of the project ... you can go on and on. On the same GitHub, there are more abandoned projects that no one needs. Of these, in Pascal, even 1% will not be typed.

Quote
But as I said, languages are nothing but tools, and when I start a new project, my first and foremost goal is to archive the best result possible. This includes using the right tools for the job. You can use a hammer for putting skrews in to the wall, but I reckon that using a skrew driver will give better results. It's the same for programming languages. I have used dozens of different languages in the past, and every of them has it's advantages and disadvatages, all are designed in a way that make them more fit for some purposes and less fit for others.

You wrote that you haven't studied C/C++ (leaving the fact that C and C++ are two different languages and studying one of them is already an act in itself), well I have (at least C++, my C is really bad), and let me tell you this, there are situations in which C++ is better suited for a program than pascal, that is, you will archive the same if not better results with less effort, but there are also situations where the roles are switched, where pascal is the better choice.
As a software developer it's your due dilligence to provide the best product in the most efficient manner, what this means in detail depends on your requirements, and if you choose your tools knowing that there are other tools out there better fitted for that purpose, you are giving up on that premise.
And of course you can do what you want, but personally won't choose to create an inferior product just because I wanted to use my favorite toy.
Я надеюсь вы понимаете, что изучал я не один язык? C/C++ я просто не стал изучать и углубляться, потому что он(они) мне просто не понравился.

Моё мнение: нет ни каких "лучших", "худших", "подходящих", "не подходящих" языков программирования! Всё можно решить и на одном -ЛЮБОМ языке программирования. Надо просто знать как его использовать в нужной стезе.

В данное время я не готов тратить время на переписывание одного кода с одного языка на другой, если меня это не заинтересует! Так же я не готов впустую тратить время, на проект, который изначально будет ни кому не нужен, даже если за него заплатят миллиард и его будут пропихивать везде. Я не буду "засорять" свою совесть подобными проектами.

Если я занимаюсь делом, если оно интересно, если оно принесёт пользу людям - то я готов делать проект. Даже бесплатно! (Это не значит что надо садиться мне на шею, вы просто ни чего не получите от меня).

В первую очередь, то, чем я занимаюсь, должно быть интересно мне. Если мне это интересно - я это развиваю. Есть возможность? - Делюсь!

Пригодилось? - Хорошо!

Не пригодилось... - ну чтож... бывает... от этого ни куда не уйдёшь. Буду пользоваться только я.

google translate: I hope you understand that I studied more than one language? I just didn’t study C / C ++ and deepen it, because I simply didn’t like it (they).

My opinion: there are no "best", "worst", "suitable", "not suitable" programming languages! Everything can be solved in one - ANY programming language. You just need to know how to use it in the right path.

At this time, I'm not ready to waste time rewriting one code from one language to another, if I am not interested in it! Also, I am not ready to waste time on a project that will not be needed by anyone from the beginning, even if a billion is paid for it and it will be pushed everywhere. I will not "litter" my conscience with such projects.

If I am engaged in a business, if it is interesting, if it will benefit people, then I am ready to do a project. Even free! (This does not mean that you have to sit on my neck, you just won't get anything from me).

First of all, what I do should be interesting to me. If it's interesting to me, I develop it. I have an opportunity? - I share!

Was it useful? - Okay!

It didn't come in handy ... - well, well ... it happens ... you can't get away from this. I will only use it.
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 17, 2021, 03:50:07 am
google translate: I admit, in some ways I could be wrong! Don't get turned on by words! But everything that you write is more perceived as a dislike for Pascal!
I think thats the nature of the post and the context. My posts are about popularity of pascal, which is one of it's weaknesses, so when I talk a lot about it, it of course looks like i'm only bringing up negative points, because there isn't much good things to say about a language being not popular.

But let me ensure you there is plenty I like about Pascal, to name some of my favorite things, nested functions are pretty much one of the best tools I've seen in a language to organise code. I really like the structure of pascal in general, and that there are no scoped variables (I think that an opt-in scoping mechanism like pythons with statement could be neat, but thats another topic). The unit structure is absolutely great, making using the FPC very comfortable for any scope of project, you don't need to make overcomplicated buildsystems like you have to for C and C++, and you are not forced in a rigid package structure like Java or C#. You can start of with a small project and let it naturally grow, without having a heavy structuring effort thats either frontloaded or backloaded being a huge timesink. It has a great mix of high and low level features, which allows you to simultaniously have a very abstract/model based code utilizing the whole aspects of OOP, while in other parts going down bare metal, without either feeling cumbersome. And not to mention that I have yet to find another solution for GUI development across all classic desktop systems thats as easy to use as Lazarus with the LCL, from a simple 1 file calculator to my big 10 kloc IDE I've wrote a few years back Lazarus just makes it really easy.

I could go on

Quote
google translate: If I need to, I use Pascal. There are no unsolvable problems!
Yes, I admit that this is often a costly and unrewarding "job". If urgency is needed, it is easier to do the work in another language if you have the opportunity.

[...]

My opinion: there are no "best", "worst", "suitable", "not suitable" programming languages! Everything can be solved in one - ANY programming language. You just need to know how to use it in the right path.

You can solve any problem with any language, thats true, but it doesn't mean that they are all comparable. Some languages will make solving some problems easier than others, in some languages a given action will require a lot of boilerplate code making the code less readable, and at other times simply require more and different code (e.g. for different platforms) that mean more maintainance effort.

The simpelest example I can give you is this, I've created the program gdiff, which simply shows me the diff of a single commit in git. I chose to use bash script for it, the script is:
Code: Bash  [Select][+][-]
  1. #!/bin/bash
  2. COMMIT=${1-HEAD}
  3. git diff $COMMIT~1 $COMMIT
I could have written it in Pascal:
Code: Pascal  [Select][+][-]
  1. program gdiff;
  2. {$Mode ObjFPC}{$H+}
  3.  
  4. uses SysUtils;
  5.  
  6. var
  7.   commit: String;
  8. begin
  9.   if ParamCount < 1 then
  10.     commit := 'HEAD'
  11.   else
  12.     commit := ParamStr(1);
  13.   ExitCode := ExecuteProcess('git', [commit+'~1', commit]);
  14. end;

The bash solution is defenetly the better one here. It was much less effort to create, is concise but still conveys all the information you need with a single glance, and can be directly incorporated into the git ecosystem (which already requires a bash to be present), without the need to be compiled.

Now this is of course the most obvious example, it compares a script language that is made just to call other programs with a general purpose language. So me give you three projects, real, rather big programs I have worked on in the past and explain what languages I used and why I chose them over other, similar languages.
First one is a data visualization software. So I had a software that produced gigabytes of raw outputs in different formats, a lot of statistics and some text information as well as meta information about the run. The goal was to visualize multiple aspects of the data, compare to different runs of the same program, etc. It started out really small, I've started with a simple table program that would load the data into a table and make it searchable and so on. I wrote this in Lazarus because you can basically start lazarus and start creating a simple GUI and the very simple logic. When I was done I thought about another feature, a plotting program, that would take the data and plot it in multiple different ways. Again I decided to use Lazarus, create a new project, copy some of the code from the original and was done really quickly.
I then got a few other ideas for new features, also the table view and plot should be linked together, so I just took these seperate projects, made the forms to frames, put the common code into a seperate datastructure and created an overarching program that simply loaded these frames as "tools" into different parent objects. So I could easiely develop each tool individually, even in it's own project, as the frames where shared between projects and simply use the large program in the end to combine all the features.

Here Lazarus was by far the best solution I could have picked. It started out really small as just a small idea, but has evolved into one of the biggest projects I had worked on at the time. Because of the huge amount of data, performance was a key issue, which is not a problem with ObjectPascal and the FPC, also reading binary data is really easy using TStreams and Records. I could also reuse components I have written for previous programs (especially the plotting frame was custom created by me and the codebase is something I am using now for more then a decade).
I could have had the performance and ease of reading binary data with for example C++, but there creating the GUI and the overall project structure would have meant like tenfold the effort it did for pascal. I could have used Javascript and make it a webapp, which allows for similar ease of managing different views and creating complex GUIs, but working on binary data in javascript is a real pain in the neck and the performance of JS in the computationally expensive algorithms for preparing the data might have resulted in massive loading times (It already was like 30seconds per imported project with heaviely optimized native code). An other alternative might have been C#, but this would have bound me to windows and Linux support was key, and I don't even know if .Net would have been fast enough (if the GC starts during a computationally heavy algorithm, it can slow it down massively)
Any other solution I can think of would have meant more work for probably a worse result.


The second project is an emulator for an old console. Here I chose C++, the reason being that C++ provides a lot of tools to write really optimised code in a very elegant way. For example you can write so called constexpr which are functions (or expressions) that are evaluated during compiletime. Basically it allows you to write compiletime code within the language pretty similar to runtime code.
Take the following code:
Code: C  [Select][+][-]
  1.   constexpr uint8_t &register(Register reg) {
  2.     if constexpr(reg == Register::A) {
  3.       return accumulator;
  4.     } else if constexpr(reg == Register::F) {
  5.         return *reinterpret_cast<std::uint8_t*>(&statusRegister);
  6.     } else {
  7.       return gpRegister[static_cast<int>(reg)];
  8.     }
  9.   }
  10.  
This function dispatches registers to a logic that is known during compiletime. If you write "cpu.register(Register::A)" this will be simply translated to "cpu.accumulator" with not a single instruction being executed on runtime for this dispatching.
This means you can put code into functions without any runtime overhead, allowing for more readable code without any performance penalty. The example above allows for example to access every register in the same manner, using the same syntactic construct, which can massively help cleaning up the code. Pascal for example has no method to define functions that are guaranteed to be evaluated on compiletime.
Another thing is the power of templates in C++, they are like generics, just more powerful (turing complete infact). You can for exmple use them to implement a shallow form of inheritance using the CRTP pattern, allowing to have most features of inheritance but also restricting the virtual depth (i.e. the length of virtual function call chains) to 1. Basically you get many of the advantages of inheritance, without the runtime penalty of inheritance.
Long story short, C++ allows for some very interesting ways to write high performance code with high level concepts that usually, in languages like Pascal, are only reserved to runtime functionality and has therefore a runtime penalty to it.
So to get back to my project, as the nature of an emulator, especially one that should function well platforms with low computational power, performance is a key issue, unlike the first example, not only for key algorithms, but across the whole code base. So while in the example above I could use Pascal for both,  as it is usally very clean when writing high level code, and the low level code was only a few algorithms, where "I could get my hands dirty", in this project I needed to archive peak performance in every aspect,  and here C++ simply makes it much easier because it applys high level concepts at a compile time level, something pascal simply can not provide.


The last project is a chat, which uses encryption. I chose javascript (well technically typescript but I consider them both to be the same). One key was the requirement for a crypto library that is up to date and well tested. I already talked about the issues with crypto libraries earlier, so I won't rehash it here. Javascript has access to the browser crypto functionality, meaning the cryptolibrary is Firefox or Chromium itself, some of the arguably most well tested pieces of software available, and always providing state of the art security, you probably can't get better then this. Next is that this chat must run on mobile, I wouldn't care if it won't run on Desktop, but mobile is a must have. I am not going to pay for any of the cross platform solutions (like Xamarin or Firemonkey) so if I don't want to create two seperate apps (one for android and one for iOS), there is pretty much not an alternative. Even native development is much more tedious for android then web technology, so even disregarding cross compatibility, I would probably have chosen javascript over like Java.
I could have chosen Pascal with Lazarus here, there is the ability to write native android and iOS apps, but these apps need to be developed seperately (where as one webapp can target both platforms with the same code) while also being much more effort to implement. I could have used Lazarus with Pas2JS to generate the Javascript code, or C++ with emscripten, but this results often in even more effort, not only setting up the toolchains, but also using non web languages in the web environment, which has it's own structures and paradigms, feels very forced and often requires a lot of boilerplate code. Javascript is basically nothing but Dicts, Arrays and atomic datatypes, with everything being dynamic, which makes using it with a static language like Pascal or C++ feel very out of place.


So with these three projects, I could have done in each of them in each of the other languages, but the effort would have been much higher, and the quality of the product (let that be performance or code quality or features) would have suffered greatly.
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 17, 2021, 06:20:55 am
I think thats the nature of the post and the context. My posts are about popularity of pascal, which is one of it's weaknesses, so when I talk a lot about it, it of course looks like i'm only bringing up negative points, because there isn't much good things to say about a language being not popular.

But let me ensure you there is plenty I like about Pascal...

...You can solve any problem with any language, thats true, but it doesn't mean that they are all comparable. Some languages will make solving some problems easier than others, in some languages a given action will require a lot of boilerplate code making the code less readable, and at other times simply require more and different code (e.g. for different platforms) that mean more maintenance effort...

...So with these three projects, I could have done in each of them in each of the other languages, but the effort would have been much higher, and the quality of the product (let that be performance or code quality or features) would have suffered greatly.

On your first point about the popularity of Pascal...  While its not the most popular language, it is more popular than most and has been so for 50 years.  I think it's unfair to look down on Pascal for not being in the top 10 (though it's pretty close at #12), but not be disparaging about languages like Go, Julia, Rust, Kotlin, etc...  That have never been in the top 10 nor are as popular as Pascal/Object Pascal.

Clearly you are a polyglot programmer (which is great), but it's arguably unfair to expect others to be too.  Perhaps Object Pascal is their primary, preferred (most enjoyable), or only language, and they are trying to maximize its use.  It might seem inefficient to a polyglot, but is very practical to such programmers.  The most efficient language for a given situation, is not necessarily always the best answer.  Something else to consider, having to maintain code written in several different languages can also be a cause of problems.

Others may select Free Pascal/Lazarus for creating Android applications.  Instead of jumping around to C++, C#, JavaScript, etc...  A different programmer might want to use DWScript, Pascal Script, Pas2js, Smart Pascal, or PascalABC...  Different flavors of Object Pascal/different IDEs that allow use of .NET or transpiling to JavaScript.  The effort-benefit analysis that each programmer makes can be quite different.

Lastly, it does seem that sometimes people will bash Pascal for not being or having the same things as their pet languages, which is kind of nonsensical.  It's like someone bashing C# for not having the "With statement".  But there are ways in that language to get the same result.  Upset that Pascal For-Loops don't work exactly like they do in C++, but overlook that they could get nearly the same result if they used Pascal's While-Loop.  It's not always the case that another language is better to use, sometimes what is in or possible with a particular language is overlooked.  Of course the choice as to how to proceed to accomplish a task/project is an individual one.
Title: Re: Contemporary Pascal Discussion
Post by: PascalDragon on April 17, 2021, 11:14:54 am
The second project is an emulator for an old console. Here I chose C++, the reason being that C++ provides a lot of tools to write really optimised code in a very elegant way. For example you can write so called constexpr which are functions (or expressions) that are evaluated during compiletime. Basically it allows you to write compiletime code within the language pretty similar to runtime code.
Take the following code:
Code: C  [Select][+][-]
  1.   constexpr uint8_t &register(Register reg) {
  2.     if constexpr(reg == Register::A) {
  3.       return accumulator;
  4.     } else if constexpr(reg == Register::F) {
  5.         return *reinterpret_cast<std::uint8_t*>(&statusRegister);
  6.     } else {
  7.       return gpRegister[static_cast<int>(reg)];
  8.     }
  9.   }
  10.  
This function dispatches registers to a logic that is known during compiletime. If you write "cpu.register(Register::A)" this will be simply translated to "cpu.accumulator" with not a single instruction being executed on runtime for this dispatching.
This means you can put code into functions without any runtime overhead, allowing for more readable code without any performance penalty. The example above allows for example to access every register in the same manner, using the same syntactic construct, which can massively help cleaning up the code. Pascal for example has no method to define functions that are guaranteed to be evaluated on compiletime.

J. Gareth Moreton is playing around with concepts in the compiler to introduce such a feature to FPC as well.
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 17, 2021, 05:46:16 pm
On your first point about the popularity of Pascal...  While its not the most popular language, it is more popular than most and has been so for 50 years.  I think it's unfair to look down on Pascal for not being in the top 10 (though it's pretty close at #12), but not be disparaging about languages like Go, Julia, Rust, Kotlin, etc...  That have never been in the top 10 nor are as popular as Pascal/Object Pascal.
I think you are going by the tiobe numbers here, there is a lot of problems with it, which is why I absolutely do not like it. The tiobe index does not measure usage but how often people google "xxx programming". This is a really bad measure for several reasons.
First, I think that the volume of google searches for a particular language is highly correlated with the usage of that language, but the syntax is way to restricted by tiobe. When programming I regularly look things up, in most languages about similarly much, but I don't google things like "C++ programming std::set" or "ObjectPascal programming TProcess" I would simply google "c++ std::set" or "lazarus TProcess", both of which will not be counted by tiobe. You usually only google "xxx programming" when you don't know anything and are just seeking out the most basic description (like wikipedia). It can even be argued that it favors less popular and/or more forgettable languages, as people that already know about a language will not google for such superficial information.
Personally I can even attest to this, I have used quite a lot of Javascript in the past, but over the past 5 years I never googled "javascript programming", but you know what I have googled? "Modula programming language", "Algol programming language", "Fortran programming language" and many other languages, I was curious about due to their historic influences, but never wrote a single line of code with them. So according to the tiobe index, I am a Modula, Algol and Fortran programmer, but not a JavaScript programmer. Seems odd, doesn't it?

Then there is the problem with aliases, to which this community is no stranger, how often do people say stuff like "lazarus programming" instead of "ObjectPascal programming. So while not being well suited for measuring popularity in general, it even has a lot more issues with ObjectPascal specifically.

Overall I must say that the tiobe index is just unfit to judge a languages popularity, which is why I usually look at actual usage statistics. One example for this is what I have mentioned earlier in this thread is the Github user statistics. When looking at all of the over 100 million github open source repositories, pascal does not make it into the top 50. Go is on place 9, Rust and Kotlin make it to 14 and 15 and Julia on place 35, as of the first quater of 2021. Of course this is biased to open source projects.
There are also a lot of online surveys out there, made using popular survey providers, one of which for example was posted on statista: Link (https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/) where Pascal also didn't make it into the top 25. And of course such online surveys have a lot of porblems, you have a selection bias, as a lot of people (like me) do not enter such surveys, people can answer multiple times if they please, also more generally, people are not always truthful and so on.

But besides each of these methods having their fair share of issues, they at least attempt to measure the usage of languages directly, while the tiobe index doesn't. The tiobe index uses a proxy in the form of very specific search queries that is arguably not a well suited measure of popularity, at most it is a measure of how many people seek superficial information of a language.

As I said, I like pascal, but it is most certainly not popular. And I think thats a shame, I think it should be in the top 50 of github, it should be at least in the top 25 on such online surveys. Sure it does not need to be spot number 1, but if the place 12 as of the tiobe index would at least be close in any of the other metrices, I think this whole thread wouldn't exist.

Clearly you are a polyglot programmer (which is great), but it's arguably unfair to expect others to be too.  Perhaps Object Pascal is their primary, preferred (most enjoyable), or only language, and they are trying to maximize its use.  It might seem inefficient to a polyglot, but is very practical to such programmers.  The most efficient language for a given situation, is not necessarily always the best answer.  Something else to consider, having to maintain code written in several different languages can also be a cause of problems.

Others may select Free Pascal/Lazarus for creating Android applications.  Instead of jumping around to C++, C#, JavaScript, etc...  A different programmer might want to use DWScript, Pascal Script, Pas2js, Smart Pascal, or PascalABC...  Different flavors of Object Pascal/different IDEs that allow use of .NET or transpiling to JavaScript.  The effort-benefit analysis that each programmer makes can be quite different.
Don't get me wrong, I said when I make a new project I evaluate the fiteness of each language according to mostly objective criterias, that doesn't mean that the decision will be objective, it is very, very subjective. For example one of the criteria is how proficient am I with the language in question, which can be measured rather objectively, but is inherently subjective.
For example I know that go is really great for concurrent processes, e.g. server development. But I don't know anything about Go, so if the choice would be between Pascal and Go I would most certainly not choose Go. Also recently I made a project together with a friend who is real beginner in programming and started with javascript. The project in question would be much better suited with pascal in my oppinion, but he is simply not at a level of programming knowledge to transfer his javascript knowledge to another new language, which is why I chose javascript.

What is right for you is always a very important factor. So when I say I chose the language that I recon is best suited for the project, this does not mean simply technical, but also incorporate my personal preferences, knowledge level, etc. Also not to forget simply old code, I am programming in ObjectPascal now since I was 12ish, I have a lot of old pascal code laying around, which I often find other usages for. This is one of the great features of Lazarus (which we inherited from Delphi), that the language is so stable that a custom Listbox component with additional graphics and more features I developed like 10 years ago still works like a charm in modern applications. So all these factors are of course relevant for the choosing of a language, even though they are very subjective to me personally.

Lastly, it does seem that sometimes people will bash Pascal for not being or having the same things as their pet languages, which is kind of nonsensical.  It's like someone bashing C# for not having the "With statement".  But there are ways in that language to get the same result.  Upset that Pascal For-Loops don't work exactly like they do in C++, but overlook that they could get nearly the same result if they used Pascal's While-Loop.  It's not always the case that another language is better to use, sometimes what is in or possible with a particular language is overlooked.  Of course the choice as to how to proceed to accomplish a task/project is an individual one.

I think it is more often than not not a bashing as of  just finding something that one thinks pascal would benefit from. And then it is always a question of how well it would fit into pascal. For example I would love to see some features of C++ in Pascal, but I don't want to se Pascal becoming C++, because there already is C++ and I don't need another one.
There are a lot of features that I think are really great, and can be incorporated into pascal, this does not mean that I want every feature of these languages. For example I really like the concept of explicetly nullable pointer as you have in TypeScript or kotlin, that does not mean that I want to have a fully dynamic type system like typescript, so while I think it would be a great addition to pascal, it would need to be implemented in a pascallian way.

But this is one thing I like so much about programming languages (well also spoken languages, but I don't want to nerd about linguistics here) that features that have proven well in other languages can get assimilated in your own language thereby having the language continuously evolve. In regards to pascal, there are a lot of things that were incorporated that made the language better. OOP, Bit operations, Operator overloading, generics, enumerators, advanced records, etc. are all features that were incorporated into pascal from different languages. Every single one of these features could have been approximated using native pascal features, but they were incorporated anyway, because they are great additions. The "for ... in ... do" loop was not native to pascal, but I wouldn't want to miss it. Same for OOP, sure you can use common prefix records with pointer to do the same, but OOP makes it much easier (I actually rebuild inheritance for records completely using generics and pointers for advanced records, and let me tell you, this is something you don't want to do).

Pascal is a living language that is evolving continuously. If I read something like that we don't need new concepts because they can be approximated with old concepts, this sounds to me like you are living in a kind of ivory tower. How do you think we got were we are today? Looking around other languages and trying to incorporate features into pascal is not "bashing", it is pretty much the most important part of keeping a language vital.

J. Gareth Moreton is playing around with concepts in the compiler to introduce such a feature to FPC as well.
I know, and I am excited as a kid before christmas about this :)
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 19, 2021, 10:25:51 am
I think it is more often than not not a bashing as of  just finding something that one thinks pascal would benefit from. And then it is always a question of how well it would fit into pascal. For example I would love to see some features of C++ in Pascal, but I don't want to se Pascal becoming C++, because there already is C++ and I don't need another one.

There are a lot of features that I think are really great, and can be incorporated into pascal, this does not mean that I want every feature of these languages...

...Pascal is a living language that is evolving continuously. If I read something like that we don't need new concepts because they can be approximated with old concepts, this sounds to me like you are living in a kind of ivory tower. How do you think we got were we are today? Looking around other languages and trying to incorporate features into pascal is not "bashing", it is pretty much the most important part of keeping a language vital.

I'm definitely not against adding new features into Pascal.  We are in agreement that Pascal should be allowed to evolve, but into what is where we should be concerned about.  The point that should be emphasized is this evolution be done in a careful and thoughtful manner that fits the design and purpose of Pascal.  We should honor and reflect upon what was Niklaus Wirth's original intention and design philosophy.

Arguably, a disaster/monster has been created, when the language is no longer well-structured, begins losing readability and maintainability, and/or poorly thought out concepts are forced which are difficult for users to grasp and use.  There is a danger in pushing the creation of overly convoluted and complex code that is part of a fad, quick buck, or an unnecessary attempt to impress others or stroke one's ego.  There is nothing wrong with simplicity, which has its own kind of beauty and sustainability.

"Genius is making complex ideas simple, not making simple ideas complex" -- Einstein
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 19, 2021, 04:39:30 pm
I'm definitely not against adding new features into Pascal.  We are in agreement that Pascal should be allowed to evolve, but into what is where we should be concerned about.  The point that should be emphasized is this evolution be done in a careful and thoughtful manner that fits the design and purpose of Pascal.  We should honor and reflect upon what was Niklaus Wirth's original intention and design philosophy.
Absolutely not, Niklaus Wirth was finished with Pascal and made two new languages, Modula and Oberon. If I wanted a language that sticked closer to Niklaus Wirths design philosophy, I would choose one of these languages, the latest version of Oberon, Oberon 07 came out just last year and was completely designed by Wirth himself. So why isn't everyone here in this forum using Oberon instead, which is arguably much closer to Wirths original intention and design philosophy of Pascal then current day Pascal is. One of the reasons for this is pretty simple, while Wirth layed a solid foundation, the derivations from his original design is what made the language flurish in the first place. One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.
Oberon does also not support OOP, there was Oberon2 which supported limited OOP, but was ditched by Wirth in favor of working on Oberon-07. It is continued in a separate project called Component Pascal, which sees moderate success (that is in the small niche that is oberon development), but it is fair to say that OOP is also not part of Wirths design philosophy and it can be argued that the success of Component Pascal is partly due to them derivating from Wirths intend.

So long story short, a lot of the things that are highly useful and make pascal what it is, are explicitly against Wirths original intend and design philosophy, and this is a good thing. Wirth gave a solid foundation and had a lot of good ideas, but also a some bad/impractical ideas for real world development. We should keep what is good, but not discard other good things, like OOP, just because they don't align with what Wirth intended. If it fits into the language and is something the pascal community as a whole benefits from, why care what Wirth would have thought of it?
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 19, 2021, 06:05:46 pm
Absolutely not...

...One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.

Oberon does also not support OOP, there was Oberon2 which supported limited OOP, but was ditched by Wirth in favor of working on Oberon-07. It is continued in a separate project called Component Pascal, which sees moderate success (that is in the small niche that is oberon development), but it is fair to say that OOP is also not part of Wirths design philosophy...

We should be careful to not misrepresent Niklaus Wirth, out of at least respect and factual correctness.  In all that I read about the matter and the quotes that I could find on him talking about OOP, he didn't disparage it.  He simply points out that OOP is not the "be all, end all" (if I may boldly sum it up).  That it has its place, along with other paradigms.  OOP and procedural programming are tools that can complement and are to be used together.  Let's not also forget that classic Pascal already had the powerful record data type, so that OOP becomes more of a "cherry on top" as oppose to base necessity.

“Was the development of Object Pascal a positive thing? Is the result still, recognizably ‘Pascal’?”  -- Richard Morris (7/2009)

“During my sabbatical at Xerox Research in Palo Alto in 1985, Larry Tesler approached me with his proposal for an object-oriented version of Pascal. He was a member of the team around Alan Kay implementing Smalltalk. I believe it was a valuable contribution to provide the object-oriented paradigm in a language with static typing. It contained several additions, but essentially retained the character and appearance of Pascal.” -- Wirth

“How do you see the future for procedural programming languages? “ -- Richard Morris

“Procedural programming is still the most common paradigm, and it will remain so, because the semantic gap between procedural languages and computers is smaller than for any other paradigm. Instruction sequences are represented by statements, and the state space by variables.

I consider object-oriented languages also as procedural. They emphasize the grouping of related data into objects, and the attachment of methods to objects. The close relationship between object-oriented and procedural views becomes apparent if we relate the respective terminologies: Basically the terms class, object, and method stand for the classical type, variable, and procedure. Instead of calling a procedure, we now send a message.” -- Wirth

On Oberon and OOP.

“...and in Oberon it was object-orientation in disguise, combined with a rigorous desire to reduce the number of features and facilities, to get rid of bells and whistles.” -- Wirth

https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/niklaus-wirth-geek-of-the-week/ (https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/niklaus-wirth-geek-of-the-week/)
(Niklaus Wirth: Geek of the Week)

Nowhere have I've read that Wirth was against bit operations, but rather his languages provide ways to simplify and organize processes when possible.

So long story short, a lot of the things that are highly useful and make pascal what it is, are explicitly against Wirths original intend and design philosophy...

This looks to be a mischaracterization and misrepresentation of what Wirth is about.  I got the impression that he's about well-structured and organized programming, readable and maintainable code, and then simplifying processes when possible.  What fits into that is likely something he would agree with. 
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 19, 2021, 07:53:22 pm
I did not make any claims about what wirth personally thinks about concepts in general, but if or if not they are part of the original intend of pascal. Let's first start about bit operations, because this is simple. Bit operations where part of Algol, a language Wirth had a lot of influence on. In Pascal later, he did not include bit operations, so assuming that he not suddenly forgot that this concept exists, it is fair to assume that it is a conscious design decision to not include them, therefore they are definitely not a part of Wirths original intend for the language.

About OOP it should be noted that Wirth had a pretty narrow view on OOP
Quote
“Procedural programming is still the most common paradigm, and it will remain so, because the semantic gap between procedural languages and computers is smaller than for any other paradigm. Instruction sequences are represented by statements, and the state space by variables.

I consider object-oriented languages also as procedural. They emphasize the grouping of related data into objects, and the attachment of methods to objects. The close relationship between object-oriented and procedural views becomes apparent if we relate the respective terminologies: Basically the terms class, object, and method stand for the classical type, variable, and procedure. Instead of calling a procedure, we now send a message.” -- Wirth
The kind of OOP he is talking about is only a fraction of the OOP paradigm as it is employed today. It is much more than "grouping related data into object and the attachment of methods to objects". Key aspects of OOP include generally, but are not limited to:
So his comment: "I consider object-oriented languages also as procedural." does not really work when you apply it to the whole picture of OOP, at least as it is implemented in modern day ObjectPascal. Also you can clearly see that his comment “...and in Oberon it was object-orientation in disguise [...]" only works in this very narrow context of OOP, where OOP basically is only the first point on the list.

Thats not to say that there is one version of OOP, different languages embrace different features to varying degrees. Javascript for example is prototype based, while Pascal is Class based, where prototypes are so to say the "base" version of the instanciated object, while classes are a meta object that are linked to the instance.
Some languages also only implement only small parts of OOP, for example in Go there is no inheritance but only interfaces, which is why the Go company, developing the Go language does not consider itself to be an OOP language, but a lightweight OOP language.
Both Modula and Oberon only implement a fraction of the OOP paradigm, and similar to Go do not embrace all the aspects of OOP. So can these languages be called OOP? Sure why not, I don't want to play the arbiter on the meaning of words, but this form of OOP if you want to call it that is undeniable worlds apart from the OOP of modern day Object Pascal.

Oberon is his newest brainchild and, under the assumption that he knows about all the implementations of OOP, he clearly rejected a lot of concepts that are employed in the fully OOP embracing languages like it is ObjectPascal or Java or C++. So while my wording previously might have been a little bit misleading (that it goes explicitly against the original intend), as this only applies to bit operations, it can be said, that Wirth is at least not so fond of these concepts that he left a lot of them out of his newer creations.
That said it is of course impossible to find out if OOP would have been part of his original intend, as back then OOP did not exist, and even if you would ask him today, people change their opinions over time, so this question can never be answered, and it was bad by me to bring it up.

But I stick to what I wrote, I not care what was his original intend, because times change, people change and technology changes. Some concepts simply did not exist back when Pascal was first concieved, and some things might have been around but technically not possible at that time and other concepts can have been refined over time to better suite different situations. A feature must stand and fall on it's own merits only with respect to it's direct influence on the matter. Calling to the "original intend" is basically delegating the explanation to an external authority, if someone tells me a feature is good or bad, I want reasons for this that are about the feature itself, what someone else from 50 years ago thinks about the feature should not have any bearing on the feature itself. If you invoke this to judge a feature, this is just a cop out. The judgement should be done on good reasoning, not on invoking an authority.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 19, 2021, 09:26:17 pm
I submit that when Wirth designed Pascal he was in a towering rage over his attempted contribution to ALGOL-68 having been rejected, he was intentionally trying to break ALGOL syntax and start over, and he was using table-driven recursive ascent with manually-constructed tables which are notoriously laborious and error prone.

I will go out on a limb and suggest that McCarthy intentionally nobbled ALGOL (by sending vW off on various wild goose chases) because his interest was now in Lisp and he saw ALGOL as a competitor. I will continue by pointing out that until very recently Wirth had been one of his junior colleagues at Stanford, and would suggest that he was unwilling to accuse him of improper behaviour hence (as is well known) resigned from the ALGOL-68 committee.

By and large, the things Wirth put in Pascal were things he could do fast and fairly reliably using material he had to hand: changes to declaration order relative to ALGOL etc. He didn't attempt to fix the dangling else problem- despite knowing about it- because it would have been dangerous and risky, and that is also why he didn't introduce novel concepts like bitwise operations.

In the UK, .Exe in the 1990s reprinted an interview with (or paper by) Wirth in which he was scathingly dismissive of OO programming, insisting that there was nothing in it that couldn't be done using records. I'm afraid I don't have a reference or a pointer to the original paper, and don't know whether at the time of the original he was in his "Modula Phase" or had progressed to his "Oberon Phase".

Pascal's broken. We're stuck with it.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 19, 2021, 09:44:45 pm
I did not make any claims about what wirth personally thinks about concepts in general, but if or if not they are part of the original intend of pascal. Let's first start about bit operations, because this is simple. Bit operations where part of Algol, a language Wirth had a lot of influence on. In Pascal later, he did not include bit operations, so assuming that he not suddenly forgot that this concept exists, it is fair to assume that it is a conscious design decision to not include them, therefore they are definitely not a part of Wirths original intend for the language.

Bit operations in early Pascal does get a bit sticky (:-), so not saying you don't kind of have a point on that, but they appear to be part of various Pascal flavors of the time when the 1983 ISO standard came out and definitely by 1990 ISO.  When you start going back into the early 1970s and 1960s, there is other terminology used instead such as partial-word operations, which can obscure specifics and purpose.  It looks like Wirth tried to simplify with the set type, but that wasn't enough for the liking of various parties. 

Do keep in mind there were important early variants of Pascal, like UCSD Pascal (1977) and Apple Pascal (1979).  Clearly and significantly early in its history, Pascal was doing bit manipulation/partial-word operations.  From interviews, Wirth was supportive of these variants/extensions, where they made sense and in the commercial space.  Let's not pretend that Wirth was opposed to extending the language.

About OOP it should be noted that Wirth had a pretty narrow view on OOP...

What is OOP is clearly a matter of interpretation.  But Wirth had a front row seat given to him by Larry Tesler (who worked on Smalltalk and under Alan Kay) and Apple.  Interviews show that Larry Tesler and Wirth had plenty of talks about OOP.  Clearly Wirth, a man of high intelligence, knows what OOP is about.  So he should be given the benefit of the doubt about accepting (pretty much said so) and contributing to the creation of Object Pascal.

As a matter of language design, Wirth seems to prefer to keep things streamline, make more efficient, or simplify.  His ideas about OOP appear to be often about reflecting on its core elements and what's necessary.  He is entitled to his opinions on OOP, and has a greater understanding of the subject than likely 99% of programmers.

Lastly, I'm not saying that what Wirth thinks is the final arbitrator of what Object Pascal can or can't put into it.  Clearly, people and companies have long took divergent paths very early in Pascal's history.  Rather, it would be good to have an understanding of what his intent and design principles are, and then be thoughtful about what does get added in.  The path that Object Pascal goes down, should arguably be what fits the language best, not incorporate any fad or gimmick.

Quote from: MarkMLl
Pascal's broken. We're stuck with it.

If Pascal is "broken", then all programming languages are.  Don't know of a language that has remained unchanged since its introduction.  All languages have to evolve, and Pascal is.
Title: Re: Contemporary Pascal Discussion
Post by: Warfley on April 19, 2021, 10:01:54 pm
and that is also why he didn't introduce novel concepts like bitwise operations.
Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits.
I can't find the original source on that one, i.e. the quote where he said that he did not include bit operations because of sets, but in 2007 he wrote a piece about Sets (anbd why they are great on ARM processors) where he at least states that he introduced sets in pascal for handling bit sets on a mathematical level: https://people.inf.ethz.ch/wirth/Oberon/SETs.pdf
Title: Re: Contemporary Pascal Discussion
Post by: Seenkao on April 19, 2021, 11:24:39 pm
In the UK, .Exe in the 1990s reprinted an interview with (or paper by) Wirth in which he was scathingly dismissive of OO programming, insisting that there was nothing in it that couldn't be done using records. I'm afraid I don't have a reference or a pointer to the original paper, and don't know whether at the time of the original he was in his "Modula Phase" or had progressed to his "Oberon Phase".
Вероятно я бы его поддержал в этом. Я ещё не видел ни одной программы, которая использует ООП и которую нельзя было бы перевести в процедурный вид. Но, зачастую я встречался в этом же ООП, где код был практически идентичен и ни кто даже не собирался это исправлять в ООП. В процедурном программировании я встречался с этим меньше! (вероятно из-за того, что людей программирующих процедурно сейчас на порядок меньше).

Google translate: I would probably support him in this. I have not yet seen a single program that uses OOP that cannot be translated into a procedural form. But, often I met in the same OOP, where the code was almost identical. and no one was even going to fix it in OOP. I've seen less of this in procedural programming! (probably due to the fact that there are an order of magnitude less people who program procedurally now).
Title: Re: Contemporary Pascal Discussion
Post by: Blade on April 20, 2021, 04:14:59 am
Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits...

It also appears that ISO 1983, might have messed up Wirth's original implementation of the set type.  Originally the cardinality of the set type was limited by the length of a machine word.  This is sometimes referred to as a "narrow" set.  The ISO standard relaxed the constraints on the set type, which can be referred to as a "wide" set.  The confusion about the ISO standard, implementation, and usage might be one of the reasons why a lot of Pascal variants went with the more "standard use" bitwise operators.  By the 1985 time frame, those kind of operators are in the documentation for various different flavors of Pascal.  Definitely, Turbo Pascal's 4 owner manual (1987) references bitwise operators.

It might be better to not characterize the issue as any kind of intentional oversight by Wirth, but more of a miscalculation or misjudgment that it would be more widely used for bit manipulation and how effective the set type would be considered for such a purpose. 

Introduction of the set type, could be considered a moderate success (when used for other purposes) as they offered additional functionality not found in other languages.  Furthermore, users of modern dialects of Pascal (and for quite some time) are given the bitwise operators and other tools for bit manipulation.  It clearly wasn't a hindrance to Apple Pascal (1979) and that line of variants that lead to Object Pascal (1986), as Apple created various OSes with it. 

This includes that this was the situation prior to Brian Kernighan's famous critique of Pascal (1981), demonstrating he wasn't aware of various flavors of Pascal or was attempting to pigeonhole it to bolster his argument.  By 1987 (Turbo Pascal version 4 hits the streets), various popular flavors of Pascal have nullified many arguments, despite his paper and many similar to his being continually used as weapons to shape public opinion for years to come.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 20, 2021, 08:57:14 am
It also appears that ISO 1983, might have messed up Wirth's original implementation of the set type.

In any event, Modula (-2?) introduced the concept of a bitset, which was explicitly defined as being the size of a machine word and with explicit bit ordering. Considering Hoare's input, records were considered to be ordered but sets weren't and their implementation was undefined (i.e. a large set could potentially be implemented as a hash table etc.).

"Oversight" is not a word I'd use in this particular case. Wirth felt that he had time constraints, and even though he was one of the most effective compiler writers of the time the technique he was using- table-driven recursive ascent- was arduous and not conducive to quick fixes.

So when I say "broken but we're stuck with it", I mean that I believe that Wirth was very much aware that what he was doing was far from perfect... and he might already have had the germ of ideas for fixing things in a successor language. But assuming that we're talking about the few weeks after his resignation from the ALGOL committee (and possibly prior to the "Minority Report" to which he at least put his signature), then his major focus was trying to get something working to preempt what he considered to be McCarthy's bad-faith manoeuvre.

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 20, 2021, 09:47:09 am
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.
Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 20, 2021, 10:19:25 am
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.

I think the /explicit/ definition that it was represented by a machine word (even if that omitted the size of the word and the numeric representation of the bit ordering) was important. Before that implementations could have claimed that their sets complied with the rather loose standard even if they'd been implemented by linked lists or unpacked arrays... as would have been done by abominations like Lisp and APL which still had noticeable market share.

(I'm not saying there that Lisp and APL were invariably abominable, merely that "higher level" languages such as those and of course Smalltalk were inclined to pretend that they had efficient low-level data structures when the truth was very different.)

MarkMLl
Title: Re: Contemporary Pascal Discussion
Post by: marcov on April 20, 2021, 10:40:12 am
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.

I think the /explicit/ definition that it was represented by a machine word (even if that omitted the size of the word and the numeric representation of the bit ordering) was important. Before that implementations could have claimed that their sets complied with the rather loose standard even if they'd been implemented by linked lists or unpacked arrays... as would have been done by abominations like Lisp and APL which still had noticeable market share.

Yes. I think that matters too for languages that don't standardize pragma's.  But the TP-FPC-Delphi block somewhat standardizes those too. (though the set packing ones are not among them, but I think some attempt at standardization would).


Title: Re: Contemporary Pascal Discussion
Post by: MarkMLl on April 20, 2021, 11:23:35 am
Yes. I think that matters too for languages that don't standardize pragma's.  But the TP-FPC-Delphi block somewhat standardizes those too. (though the set packing ones are not among them, but I think some attempt at standardization would).

I agree, although I think that when pragmata were adopted it was anticipated that they would be compiler-specific. It would obviously be desirable if "obvious" pragmata like overflow checks could be universally uniform, but back in those days there were still systems which made little if any distinction between integers and reals which would possibly have needed a different form (i.e. "variables must not exceed" rather than "turn range checking on").

Whatever, even if Pascal pragmata are a bit messy we have- as you say- got a modicum of standardisation and just have to put up with it... just as we have to put up with the messy bits of the language itself.

MarkMLl
TinyPortal © 2005-2018