Lazarus

Miscellaneous => Other => Topic started by: valdir.marcos on November 30, 2019, 07:11:50 am

Title: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: valdir.marcos on November 30, 2019, 07:11:50 am
Afaik, ETH's P4 was meant as bootstrap compiler because the small bytecode interpreter would be easily portable.
Since the compiler didn't use the full ISO dialect, neither did P4.

That's why Scott made P5, which is P4 expanded to support the full ISO dialect.

Pascal ISO 7185:1990

Standard Pascal
In 1974, the creator of the Pascal language, Niklaus Wirth wrote a book with Kathleen Jensen, titled Pascal User Manual and Report published by Springer-Verlag. This book became a de-facto standard for the Pascal language. In 1983 the International Standards Organization (ISO) formalized the de-facto standard as ISO 7185:1983. In 1990 ISO released an updated version - ISO 7185 :1990 - that didn't introduce any new concepts, but cleared up ambiguities and corrected errors that were in the earlier version. The ISO 7185 standard is referred to as Standard Pascal. The standard defines the minimum level that a Pascal compiler must support in order to be a true compiler of the Pascal language
https://wiki.freepascal.org/Standard_Pascal

http://pascal-central.com/docs/iso7185.pdf


ISO/IEC 10206:1991

Extended Pascal
Extended Pascal is the name given to the version of Pascal specified in International Organization for Standardization (ISO) standard 10206. It specifies an enhanced version of the Standard Pascal language that was specified in the ISO 7185 specification. The 214-page ISO 10206 document was published in May 1991 and not been revised since.
Support in Free Pascal for Extended Pascal is planned, and will be via compiler mode extendedPascal.
https://wiki.freepascal.org/Extended_Pascal

https://www.iso.org/standard/18237.html

http://www.pascal-central.com/docs/iso10206.pdf

In the beginning, Pascal, C and C++ were spread in many flavors on different architectures, machines and operating systems.
Why C and C++ standardization flourished up today and Pascal stopped in 1991?
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: Thaddy on November 30, 2019, 08:29:53 am
Due to three main players:
- Wirth himself moved on to - clearly Pascal derived - other languages which could even have been named after Blaise Pascal again...Modula and Oberon. Although he always showed interest in Pascal developments, he really did not put in real effort.
- Borland became protective and restrictive on their - commercial - language extensions. Although Borland employed at one point over 50 computer scientists and mathematicians (I left out programmers!) , they did not share their scientific results, nor pursuited a new standard based on their work.
- There were new standards possibly based on Objective Pascal from Apple, but Borland saw (after 1992) no good reason for that. From 1992-1994 Delphi was being worked on and was kept as best a secret as could for pure commercial reasons. Apple gave up...

When major industry players do not cooperate you won't get new standards.
To the defense of Borland, I have to say 2 things:
- that they were quite open to visitors to show their advances: I visited the Borland campus a couple of times in the mid '90's
- that contrary to standardizing Pascal, they (and their subsequent new owners) did and maybe do play a major role in the C++ standards committee

This is only less than half the story, but these observations come from my personal past. I feel that the benefits of open standards and open source - in terms of software, not hardware - were not fully understood by the major stakeholders at that point in time. No reference implementations for newer language additions could be agreed either..

It would still be quite feasible to write a new standard based on the two new major players (FPC and Delphi)

Software patents do kill standards, though.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 09:14:12 am
Why C and C++ standardization flourished up today and Pascal stopped in 1991?
That's a good question and I doubt anyone can offer a definitive answer.  My guess and, that's all it is, a guess, is that the Pascal language has never been targeted in production to a specific area of computing. 

If we compare it to C (some people won't like the comparison but... oh well), from its conception the language was meant to be a systems programming language, a "high level assembler" as it has sometimes been dubbed.   While the design of the C language is a _genuine atrocity_ (unparalleled until C++), even those who strongly dislike it (myself among them) must acknowledge that once you learn how to use it, it can be a very effective tool for someone doing systems programming. 

If we compare it to COBOL (yes, there are still plenty of COBOL programs out there and new ones are _still_ being written), that language was designed to be mostly self documenting and meet simple procedural business requirements.  In spite of a very large number of deficiencies for other uses (and some even for its primary use), it fulfills its goal really well, much much better than C or Pascal or both put together in that area.

And for those who enjoy and extoll portability, the _first_ portable program was written in COBOL and, well written COBOL programs are very easy to port from one architecture to another.

The story is the same when we consider FORTRAN. It lacks many capabilities but, for pure raw number crunching, it packs a punch no other "somewhat general" language has.  For that reason, there is a 2018 standard for the n-th iteration of the very first compiler.

Pascal was the first and, possibly last, not overly focused language designed to teach, not programming but, _how to program_, i.e, use and apply the structured programming methodology with a language that elegantly supports its constructs.  It fulfills that purpose quite well.  The problem is, that methodology can be taught using other languages (particularly when today's "structured programming" includes dynamic gotos), as a result, Pascal's claim to fame is no longer unique and, it has no other one (at least not so far). 

Because their purpose (C, COBOL, FORTRAN, others) is clearly defined, there is continued interest in improving them to make them better tools to accomplish their purpose.  Pascal's purpose - to teach structured programming - doesn't really require updating the language.  The answer is: learn using another language.

Until someone clearly states what Pascal is for (other than to learn programming) and, starts extending its _design_ instead of just bolting junk found in other languages to it, it is quite unlikely the situation will change.  To add to the problem, somewhere along the line, Borland figured they could make some quick money by adding junk into the language instead of making the language better.  There is still no visible light in that tunnel which is not a good thing for Pascal.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: Thaddy on November 30, 2019, 09:57:47 am
Well, Beginners' All-purpose Symbolic Instruction Code was the actual teaching language that created multi-billionaires (Gates actually wrote - not bought- a compiler/interpreter)
Pascal was and is about teaching, but also about structure. C derivatives never were. Not even C++.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 11:12:36 am
Well, Beginners' All-purpose Symbolic Instruction Code was the actual teaching language
It's rather regrettable to see there is a parallel between BASIC and Pascal.  Neither language elicits enough interest for a standards body to define and improve them since the early nineties.

Pascal was and is about teaching, but also about structure. C derivatives never were. Not even C++.
Pascal was, at least long ago, part of most CS curriculums.  BASIC was usually (justifiably) regarded as a "toy" programming language and rarely, of any significance in a CS curriculum (if present at all.)

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on November 30, 2019, 12:08:39 pm
While the design of the C language is a _genuine atrocity_ (unparalleled until C++), even those who strongly dislike it (myself among them) must acknowledge that once you learn how to use it, it can be a very effective tool for someone doing systems programming.

Let's dial back the butt-hurt a little bit. I think you're assuming that your peculiar personal experience is universal. It isn't. Pascal's biggest virtue is apparently its plainness. You're not gonna ride the tiger with Pascal.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: MarkMLl on November 30, 2019, 01:11:17 pm
I don't like adolescent language wars. However it's interesting to consider that the problems people have with C are overwhelmingly not to get it do do jobs effectively, but instead are to ensure basic robustness: no pointer abuse (intentional or otherwise), making sure that memory is correctly allocated and freed, and so on.

Such things were necessary back when people wrote assembler. They shouldn't be necessary in a high-level language.

At the same time, I will agree with 440bx that C /can/ be effective and efficient. Its advantage there is that because it doesn't "waste" stack space with exception and managed-type state handing the resulting binary can be "lean and mean", and it manages that in part by not using precompiled units heavily: it could /potentially/ use the same function in two different places in the same program with different calling conventions if the compiler were smart enough to spot that as a potential optimisation.

I don't like C. I've argued vehemently against C at the application level for the last 35 years, and C++ isn't all that much better. But C still does have a niche as a "better assembler than assembler".

MarkMLl
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 01:16:45 pm
Let's dial back the butt-hurt a little bit.
Thank you for the chuckle.  Your reaction indicates you're the one who's feeling some pain and, it also seems to be affecting your mood. It may be time for you to dial up on the pain medicine. I hope the hurt will be as ephemeral as possible.

I think you're assuming that your peculiar personal experience is universal.  It isn't.
Very regrettably, my conclusion is not universal.  As far as my personal experience, it includes being a C programmer.  That language is a design disgrace but, there are times when it can be the appropriate tool.

Pascal's biggest virtue is apparently its plainness.
Define what "plainness" is in a language and how it is present in Pascal.  IMO, among Pascal's biggest virtues are its strong typing, clear, readable, very rarely ambiguous and, rarely prone to lead to unintended errors, syntax (unlike the "==", "||", "|", "<", "<<" and other such common and numerous examples found in C's "great design".)

You're not gonna ride the tiger with Pascal.
That's a hobby you and I don't share, I don't ride tigers.  Good luck with that one and, don't forget to feed the kitty. Forgetting to feed it could lead to no ride (and that may not be the worse part.)

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on November 30, 2019, 01:22:20 pm
I don't like C. I've argued vehemently against C at the application level for the last 35 years, and C++ isn't all that much better. But C still does have a niche as a "better assembler than assembler".

MarkMLl

Therein lies the rub. The confusion of C++ with C. Two entirely different languages. Trust me on this. Any language wars between C and Pascal belong back in the 1990's. I couldn't care less. I've moved on.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 01:43:19 pm

In the beginning, Pascal, C and C++ were spread in many flavors on different architectures, machines and operating systems.
Why C and C++ standardization flourished up today and Pascal stopped in 1991?

C++ is a separate language.   C is a API description language for Unix that sometimes doubles as programming langauge (joking, but the motivation for the standarization is more Unix related than general C application programming related)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: julkas on November 30, 2019, 03:19:57 pm

In the beginning, Pascal, C and C++ were spread in many flavors on different architectures, machines and operating systems.
Why C and C++ standardization flourished up today and Pascal stopped in 1991?

C++ is a separate language.   C is a API description language for Unix that sometimes doubles as programming langauge (joking, but the motivation for the standarization is more Unix related than general C application programming related)
OK. C++ is a separate .... C is a API description ... What is Pascal ?


Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 03:38:21 pm
OK. C++ is a separate .... C is a API description ... What is Pascal ?

Pascal is less tied to a single goal, like C to Unix/system programming. As said there was some education in the original concept (though that is often wrongly associated with initial first year programming courses, the original use was for students further in their studies, and about algorithms and compiler building), but nowadays due to Delphi I guess it is mostly application building in a very general sense of the word.

Not unlike C++, but I would lump Delphi/object pascal more in the productivity languages group (C#,Java, VB), and less next to C++, though technically it is closer to C++.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on November 30, 2019, 04:02:38 pm
Also: without C you have no NumPy. And without NumPy, Python is dead in the water.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on November 30, 2019, 04:05:16 pm
Sorry, I know I'm not qualified to post here but I would like to see someday people could come up with kernel module written in Pascal, people used Pascal to develop their existing OS side by side with C thanks to the painless interfacing between Pascal and C, we could import C header and have it generate working Pascal unit without having to edit anything by hand... Ah, it's just dreaming!
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 04:35:22 pm
I would lump Delphi/object pascal more in the productivity languages group (C#,Java, VB), and less next to C++, though technically it is closer to C++.
I believe that's one of the problems that afflicts Pascal.  I suspect that if it weren't for the RADs, Lazarus and Delphi, Pascal would be even less popular than it already is.  IOW, the value of the language isn't determined by the language's ability but, instead by the abilities of the RAD systems that use it (two (2) in this case.)

I believe its dependence on the RADs is preventing it from being developed in a clear and specific direction, such as, a systems programming language.  Since RADs are definitely not something that will be standardized and, there is no specific purpose for the language, that causes it to not be defined for anything in particular hence the absence of an evolving standard for it.

Basically, Pascal is behaving like many productivity languages/environments that come and go, instead of behaving like a programming language with a clear purpose in one of the areas of computer science.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 04:36:36 pm
we could import C header

Technically not possible. A C header partially works by substitution in C source, and thus can't be converted, since only the actual use will provide the exact meaning.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on November 30, 2019, 04:44:47 pm
Basically, Pascal is behaving like many productivity languages/environments that come and go, instead of behaving like a programming language with a clear purpose in one of the areas of computer science.

COBOL had a clear purpose. Yet ... it came ... and it went.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 05:05:35 pm
COBOL had a clear purpose. Yet ... it came ... and it went.
Just because you don't see it doesn't mean it's gone.  COBOL is far from gone.  Some of the programming on big iron has shifted to SQL and supporting interpreters such as PL/SQL but, there is still _plenty_ of COBOL there and, occasionally, new COBOL programs are developed to support/integrate processes that include two different "environments" (different files types and/or different databases.)

For a lot of business logic, COBOL is still in many cases the best choice around.  All that said, it is not used as extensively as it was 30+ years ago.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on November 30, 2019, 05:14:01 pm
COBOL had a clear purpose. Yet ... it came ... and it went.

That was in part (a great part) because COBOL was tied with big-irons and minis and those went into a steep decline with the rise of "personal" computers. COBOL is also considered, usually, a *big* language relatively difficult to learn and apply to relatively simple task. It's somewhat akin to what happened to Ada: by the time good optimizing compilers were made for PCs programmers had already swung away from them and used "simpler" languages, like BASIC, C, Pascal, etc.

Nonetheless, there is still a great market for COBOL programmers not only to maintain the huge existing code base but also for new development. But since this is most often done internally inside big enterprises (banks, huge multinational, etc.) this development is not as visible in Internet as the one done in C, Python, JS, Java, etc.

Note also that most COBOL programmers are by now in or close to the retirement age and there are so few able to replace them that they're offered quite big incentives. Those looking to programming as a life-time carer would do well to become at least acquainted with it beyond the mere basics of "it has too many divisons, and sections, and subsections, and is extremely verbose" :)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 05:29:33 pm
I would lump Delphi/object pascal more in the productivity languages group (C#,Java, VB), and less next to C++, though technically it is closer to C++.
I believe that's one of the problems that afflicts Pascal.  I suspect that if it weren't for the RADs, Lazarus and Delphi, Pascal would be even less popular than it already is.  IOW, the value of the language isn't determined by the language's ability but, instead by the abilities of the RAD systems that use it (two (2) in this case.)

I agree, but would generalize that, namely that a language's popularity depends on factors mostly not related to language.

Quote
I believe its dependence on the RADs is preventing it from being developed in a clear and specific direction, such as, a systems programming language. 

There is no dependence on RADs. Just like C++ has no dependence on RADs because C++Builder exists.

Quote
Since RADs are definitely not something that will be standardized and, there is no specific purpose for the language, that causes it to not be defined for anything in particular hence the absence of an evolving standard for it.

As said, the case is mostly the same as for C++, just accents differ because Pascal's tooling is less far except for the RAD aspect.

Quote
Basically, Pascal is behaving like many productivity languages/environments that come and go, instead of behaving like a programming language with a clear purpose in one of the areas of computer science.

I've no idea what you mean by that. Specially you give no counter examples of languages that have stuck in a certain niche for a very long time. (say >20 years)

Sure, there is C and its systems programming niche, but there is only room for one such language, and its ascent was not exactly planned.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on November 30, 2019, 05:41:52 pm
There is no dependence on RADs. Just like C++ has no dependence on RADs because C++Builder exists.

Real dependency maybe not, but to most computer people today "Pascal" means either "Turbo Pascal" (if they are old enough ;)) or "Delphi"(/"Lazarus") and their defining characteristic is in fact the IDE to the extent that the language itself becomes meshed-up with it. Didn't help either that Borland started referring to "their" language as "Delphi" discarding the "Pascal" used previously.

No serious contendient to Borland/CodeGear/Embarcadero hegemony came along so in the end "Pascal" and "Delphi" have become almost sinonymous, unfortunately. :(
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: julkas on November 30, 2019, 06:01:54 pm
@lucamar Why GNU Pascal is dead?
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on November 30, 2019, 06:44:30 pm
@lucamar Why GNU Pascal is dead?

Almost dead, I'd say, and IMO for the same reason most other Pascals (except niche ones) are quite dead: there are not that many Pascal programmers and most of them have become accustomed to have an advanced IDE like Delphi or Lazarus. GNU Pascal is, let's say, "primitive" in this regard. A related drawback is that most Pascal programmers have come to identify "Pascal" with Borland's Pascal while GPC proudly boast of being an almost pure (somewhat extended) "standard" Pascal. If you have ever used a standard-compliant Pascal you know what I mean ;)

It also suffers, though in a lesser degree, in being seen merely as a "Pascal" front-end to GCC, which is still regarded mostly as the "GNU C Compiler" rather than the "GNU Compiler Collection".

Of course, that's just my opinion (backed by a somewhat large experience) and it's not set in stone; there may be other reasons of which I'm not aware. I was once very interested in GNU Pascal as an alternative to Borland's, but then I discovered Free Pascal (and eventually Lazarus) and the rest is history. 8)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 07:16:43 pm
There is no dependence on RADs. Just like C++ has no dependence on RADs because C++Builder exists.

Real dependency maybe not, but to most computer people today "Pascal" means either "Turbo Pascal" (if they are old enough ;)) or "Delphi"(/"Lazarus") and their defining characteristic is in fact the IDE to the extent that the language itself becomes meshed-up with it.

Maybe, but yeah, which language has no associations from the past? Not having them means you are squeaky new or unused. Neither of which is really a good thing.

I think the stigma of Pascal is mostly older IT guys having being forced to do their intro to programming in it. But that is also not really relevant for a future course. We just have to live with that.

Quote
No serious contendient to Borland/CodeGear/Embarcadero hegemony came along so in the end "Pascal" and "Delphi" have become almost sinonymous, unfortunately. :(

Not so much a problem IMHO. True multi vendor languages are rare.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on November 30, 2019, 07:20:35 pm
a language's popularity depends on factors mostly not related to language.
I agree that the popularity of a language depends on some factors that are not built into the language itself but, I wouldn't say "mostly".  Two important factors I can think of that aren't really related to the language (or loosely related to it) are a good debugger and a good linker.

There is no dependence on RADs. Just like C++ has no dependence on RADs because C++Builder exists.
For Pascal there is clear dependence on RAD but, I agree there is no, or extremely small, dependence on RAD for C++.   The reason is that there are plenty of "plain" C++ compilers that stand on primarily the language's merit.  If Delphi and Lazarus were to disappear, the use of Pascal would drop significantly (a very unfortunate fact.)  As far as C++ Builder is concerned, as a RAD environment, its mindshare seems to be even smaller than that of Delphi, thus reinforcing the fact that RAD is almost inconsequential in a programmer's decision to use C++ (Builder or other.)


Basically, Pascal is behaving like many productivity languages/environments that come and go, instead of behaving like a programming language with a clear purpose in one of the areas of computer science.
I've no idea what you mean by that. Specially you give no counter examples of languages that have stuck in a certain niche for a very long time. (say >20 years)
What I mean by that is, if a language is used because of its RAD (such as Delphi and Lazarus) instead of mostly because of its intrinsic features/power, it will grow in popularity then decline until it's gone or close to gone.  Examples, among many, that come to mind are dBase, FoxPro, Clarion and many others which at one time may have been very popular yet, after some years, are of little interest to the majority of programmers.  This is in stark contrast with languages like C, FORTRAN and COBOL which are used because of their features/power in a particular area.  Those languages have been around a long time and will be around for a long time  (COBOL may be more affected because one of its uses was to access databases which has been mostly taken over by SQL enabled relational databases but, in spite of that, isn't about to vanish.)


Sure, there is C and its systems programming niche, but there is only room for one such language, and its ascent was not exactly planned.
I don't believe that.  While a lot of C programmers are just blind worshippers of the language, there is also an important percentage who are fully aware of what an incredibly poorly designed language it is and, use it because using another language for systems programming is basically risky.  Using FPC for large scale development _is_ risky. There is no guarantee (financial or otherwise) that enough of the current compiler developers will remain interested or will have the time to continue developing the language.   While individual developers or, a very small shop may be willing to take that risk, most companies aren't willing to make a multi-million dollar investment in producing software with a compiler with an uncertain future, e.g, FPC sadly.

I sincerely believe that if Pascal was extended to match C feature for feature _and_ it produced code as well (or better) optimized than C's (that's not easy but, it is doable), a very significant percentage of programmers would switch.

Combine that with a good debugger and capable linker and C's future would not be as certain as it is today.

Don't worry, I know that is not going to happen (IOW, the above is _not_ a features request.)   If I wanted a systems programming feature added to FPC, I'd go to church to ask for it, better chances that way.


Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on November 30, 2019, 07:28:21 pm
COBOL had a clear purpose. Yet ... it came ... and it went.

That was in part (a great part) because COBOL was tied with big-irons and minis and those went into a steep decline with the rise of "personal" computers. COBOL is also considered, usually, a *big* language relatively difficult to learn and apply to relatively simple task. It's somewhat akin to what happened to Ada: by the time good optimizing compilers were made for PCs programmers had already swung away from them and used "simpler" languages, like BASIC, C, Pascal, etc.

Nonetheless, there is still a great market for COBOL programmers not only to maintain the huge existing code base but also for new development. But since this is most often done internally inside big enterprises (banks, huge multinational, etc.) this development is not as visible in Internet as the one done in C, Python, JS, Java, etc.

Note also that most COBOL programmers are by now in or close to the retirement age and there are so few able to replace them that they're offered quite big incentives. Those looking to programming as a life-time carer would do well to become at least acquainted with it beyond the mere basics of "it has too many divisons, and sections, and subsections, and is extremely verbose" :)

Good answer. I love COBOL - I was just giving him a hard time.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: winni on November 30, 2019, 07:41:10 pm
Hi

One of the problems that Pascal does not seem to be active  like C or "modern" languages is the wide spread different kinds of applications made with Pascal/Delphi/Lazarus.

The german Telekom used Delphi plus dBase tables for the fax logs. FritzBox did the same. An acquaintance coded medical insulin pumps with Delphi. In the time of the fractal hype a lot of demos were coded with Turbo Pascal. The complete train station Hamurg Altona was controled with Turbo Pascal software - all signals and turnouts. The first 3 days with no train: They had disabled stack checking ...

So there is no core area for Pascal because there are so many different application areas.

And the second point is that Nikolas Wirth created Modula (II) and later Oberon and his Oberon OS.  So Pascal at Zürich ETH was "yesterday". And he invented horrible things like case sensitivity. Gave me thousands of compiler errors in Modula II. The ISO Pascals were always behind the times and made it realy complicate to work with it.

So the standard was set by Turbo Pascal/Delphi.  And monoculture is never good. Nowhere.

So I'm glad that free pascal / Lazarus exists.

@julkas
 Gnu Pascal: there is no development anymore since 2005, have a look at http://www.gnu-pascal.de (http://www.gnu-pascal.de)

Winni
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on November 30, 2019, 07:56:31 pm
a language's popularity depends on factors mostly not related to language.
I agree that the popularity of a language depends on some factors that are not built into the language itself but, I wouldn't say "mostly".  Two important factors I can think of that aren't really related to the language (or loosely related to it) are a good debugger and a good linker.

Development system, IDE, toolchain and libraries, as well being better than average in a certain thing as attracting factor.

There is no dependence on RADs. Just like C++ has no dependence on RADs because C++Builder exists.
For Pascal there is clear dependence on RAD but

Then explain. There is {$M+} support for RTTI that the formdesigner uses, but that is so little. The rest of the language is independent. I've programmed FPC and Delphi with the textmode IDE, with notepad, and with JOE.

Delphi also has a commandline compiler.

Quote
, I agree there is no, or extremely small, dependence on RAD for C++.   The reason is that there are plenty of "plain" C++ compilers that stand on primarily the language's merit. 


Having standalone compilers doesn't mean it is not RAD dependent. At least not any more than C++ does.

If Delphi and Lazarus were to disappear, the use of Pascal would drop significantly (a very unfortunate fact.) 

If two out of three of (LLVM,GCC,VS) die, you have probably also a significant drop. Even more so if the rumours are true that VS will change to LLVM. (which I still find a bit odd)

Cutting out the most major players always hurts. For any language.

Quote
As far as C++ Builder is concerned, as a RAD environment, its mindshare seems to be even smaller than that of Delphi, thus reinforcing the fact that RAD is almost inconsequential in a programmer's decision to use C++ (Builder or other.)

Classically in Europe it is 10 Delphis to every BCB, and in the US the other way around.

What I mean by that is, if a language is used because of its RAD (such as Delphi and Lazarus) instead of mostly because of its intrinsic features/power, it will grow in popularity then decline until it's gone or close to gone. 

Examples, among many, that come to mind are dBase, FoxPro, Clarion and many others which at one time may have been very popular yet, after some years, are of little interest to the majority of programmers. 

Those languages stood or fell by their 4GL database product. Lazarus/Delphi is different that it makes apps, and a much wider array.

Quote
This is in stark contrast with languages like C, FORTRAN and COBOL which are used because of their features/power in a particular area. 

I don't agree. I think this is convoluted. First of all, these are not used because of features, but because of platform inertia with some major use case, respectively Unix and OS development, math and 40 year old banking software.

There is no real "features" or "power". C is nearly the definition of the absence of features in a language.

If C had lost Unix in say 1990, most of us couldn't even name it by now. Cobol is already more or less in that space (except the much regurgitated "in financial institutions", but most of that is heresay rather than actual practical knowledge).

Fortran is the master of 70s and 80s math. It is still strong, but loosing slowly to C++ libraries with scripting languages on top of them.

Quote
Those languages have been around a long time and will be around for a long time  (COBOL may be more affected because one of its uses was to access databases which has been mostly taken over by SQL enabled relational databases but, in spite of that, isn't about to vanish.)

Maybe, but even when not dead, they are becoming eincreasingly irrelevant to the daily practice. Fortran and Cobol are mostly already there, confined to certain institutions and much less relevant to every day programming than e.g. Pascal.

But the delusion is that it has anything to do with features or planning. They just hit the jackpot somewhere during their existence in being tied to an application that was so big it became self-fulfilling, and which will take a long time to atrophy naturally.  Linking it to properties of the language, or some grand plan is just delusional. Chance and other non technical, non-language reasons. Nothing more.

Sure, there is C and its systems programming niche, but there is only room for one such language, and its ascent was not exactly planned.
I don't believe that.  While a lot of C programmers are just blind worshippers of the language, there is also an important percentage who are fully aware of what an incredibly poorly designed language it is and, use it because using another language for systems programming is basically risky. 

Sure. All known for 40 years, yet still here we are. (ok, at least there is a contender now, Rust, but I have my doubts)

Quote
Using FPC for large scale development _is_ risky. There is no guarantee (financial or otherwise) that enough of the current compiler developers will remain interested or will have the time to continue developing the language.   

Sure. But only for the largest classes of development. (and maybe not even that, since a real major program could simply start to maintain FPC itself)

That's how it works with other languages too.

Quote
While individual developers or, a very small shop may be willing to take that risk, most companies aren't willing to make a multi-million dollar investment in producing software with a compiler with an uncertain future, e.g, FPC sadly.

I think this is mostly deflecting talk to rationalize a non rational decision that was already made.
The same companies do put enormous sums in new frameworks and scripting languages that will be dead and buried when Delphi finally kicks the bucket.

Yet when it is about Delphi or FPC it suddenly is all about conservatism.

Reality is that it is simply cowardise, and "nobody got fired for chosing X" or "1000000 lemmings can't be wrong"  mentality.

Making a real decision takes guts, and all kinds of sycophants will be waiting to say "I told you so" if it blows up. Choosing something safe is then simply the default. Even if it is not really (technically, economically) safe, if you can simply point and say "everybody is doing it", you get a managerial "get out of jail free" card.

But that only means that those are not the places to promote alternative languages. Start in smaller shops that have some direct gain.

I sincerely believe that if Pascal was extended to match C feature for feature _and_ it produced code as well (or better) optimized than C's (that's not easy but, it is doable), a very significant percentage of programmers would switch.

Totally ridiculous in my opinion. C's popularity is not about C but about clout. In people minds and in toolchains. You don't solve that with a few haphazardly ported language features.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on December 01, 2019, 03:54:18 am
Development system, IDE, toolchain and libraries, as well being better than average in a certain thing as attracting factor.
I agree with that.


Having standalone compilers doesn't mean it is not RAD dependent. At least not any more than C++ does.
It looks like I didn't make the point clearly.  Here is the point: if Delphi and Lazarus (the environments) "magically" vanished, the use of Pascal would drop significantly.  That is not the case with C, FORTRAN and/or COBOL.  Programmers that use those languages don't choose those languages because there is some "cushy" environment available for them, they will probably choose a particular _implementation_ of the language because there is a more flexible/powerful environment for them but, the choice of language isn't determined by that.

For C, Fortran and/or COBOL, as long as there is a decent debugger and editor available in addition to a decent compiler, that's all it takes.  For Pascal, if you take away Delphi and or Lazarus, the result will often be "Goodbye Pascal" (very unfortunately.)

If two out of three of (LLVM,GCC,VS) die, you have probably also a significant drop. Even more so if the rumours are true that VS will change to LLVM. (which I still find a bit odd)

Cutting out the most major players always hurts. For any language.
If two out of the three major implementations of the C language were to disappear, the most likely result is that a replacement implementation would appear shortly thereafter.  That cannot be said about Pascal.

Quite a few C compilers have come and gone before we got to the current status quo but, C remained popular.

Those languages stood or fell by their 4GL database product. Lazarus/Delphi is different that it makes apps, and a much wider array.
But Pascal has the same weakness those 4GL database products have/had.  The popularity of Pascal is dependent on the RAD environments.  Only a minority choose Pascal because of the language's power, the majority choose it because of the RAD environments associated with it.

If C had lost Unix in say 1990, most of us couldn't even name it by now.
That's quite likely to be true but, the fact is, it was used to develop a successful O/S. It proved that, in the hands of a reasonably knowledgeable programmer it is powerful enough to write an O/S with it. Pascal doesn't have that and that makes a big difference to programmers that code low level routines.

Cobol is already more or less in that space (except the much regurgitated "in financial institutions", but most of that is heresay rather than actual practical knowledge).
Poor COBOL language.  Non COBOL programmers love to put it down.  I just want to point out that just because it is hearsay to you, it doesn't mean it is actually hearsay.  It is a _fact_, not hearsay, that you'll find a lot more COBOL code in financial institutions than you'll find Pascal code.

but loosing slowly to C++ libraries with scripting languages on top of them.
It's quite likely there is some of that but, I'm rather skeptical that they'll ever be able to displace FORTRAN.  You can use a shoe as a hammer but, shoes are very unlikely to displace hammers.

Fortran and Cobol are mostly already there, confined to certain institutions and much less relevant to every day programming than e.g. Pascal.
With the advent of personal computers, "everyday programming" grew significantly.  FORTRAN is still mostly used by engineers and scientists and, the number of engineers and scientists didn't grow exponentially with the availability of PCs.  The sea got bigger, the number of FORTRAN fish stayed fairly constant while the number of people who really just dabble in programming grew significantly.  The result is, the number of FORTRAN fish isn't as noticeable as it once was but, their relevance has not changed significantly.

But the delusion is that it has anything to do with features or planning. They just hit the jackpot somewhere during their existence in being tied to an application that was so big it became self-fulfilling, and which will take a long time to atrophy naturally.
Undoubtedly there is likely a good bit of that in the case of C but, very little of that in the continued use of FORTRAN and COBOL.

Linking it to properties of the language, or some grand plan is just delusional. Chance and other non technical, non-language reasons. Nothing more.
It's not as delusional as you are implying.  C is successful in system programming because it demonstrated that it can be used for that purpose _and_ no comprehensive better alternative has showed up.  C won the systems programming race in spite of its being a race horse in a wheelchair, because in spite of its wheelchair having dodecagonal wheels, the other horse's wheelchairs had square wheels.  Rather regrettably, programmers get used to dodecagonal wheels much too easily (and no matter how poorly they perform, there is always a programmer ready to point out "it works!", therefore no better way should be implemented - that should sound familiar to you.)

That's how it works with other languages too.
But you seem to have forgotten one thing, that is, MS alone cannot let C lose too much popularity simply because it has a multi-billion dollar investment in C code and, they are far from the only company with a significant financial investment in the language. 

When it comes to Pascal, Embarcadero may very well be the company with the largest investment in Pascal code and it is paltry compared to the investment other companies have in C code.

It's a lot easier and less costly to abandon Pascal than C (or COBOL or FORTRAN.)

Reality is that it is simply cowardise, and "nobody got fired for chosing X" or "1000000 lemmings can't be wrong"  mentality.
It's not cowardice and, there is some, at least at the beginning of a choice, of the "nobody got fired for chosing X" or "1000000 lemmings can't be wrong" but, once a company is heavily invested in a technology, it is often more cost effective to stick with it than adopt a new one even if better simply because it is financially sensible to get the most out of the already built infrastructure.

Making a real decision takes guts,
It sure does.  It also takes knowledge and good analytical skills to accurately evaluate the effects of the decision.  The latter is what implies the guts because it is too often missing and simply replaced by guts.  IOW, the problem is, among the many well developed mathematical fields, there is still no functional "theory of guts".

I sincerely believe that if Pascal was extended to match C feature for feature _and_ it produced code as well (or better) optimized than C's (that's not easy but, it is doable), a very significant percentage of programmers would switch.

Totally ridiculous in my opinion. C's popularity is not about C but about clout. In people minds and in toolchains. You don't solve that with a few haphazardly ported language features.
That seems to be the most common viewpoint but, there was a time when C had little to no clout yet, it grew without it.  My premise is, it grew because no really good alternative to it showed up.  It seems to be a common hobby these days for some programmers to make another C omelet (rust, D, C++, etc) and proclaim it's better because it is sprinkled with various "safe-whathaveyous" and "multi-this or that".  Tunnel vision at its best and, it somewhat works because of the common aversion to unfamiliar constructs.


The bottom line is, the reason there hasn't been a new Pascal standard for so long is simply because the language is not interesting to a sufficiently large audience.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on December 01, 2019, 04:22:27 am
All my DSP labs were in C. Fifteen years of algorithm development was in C. It's a snap once you understand pointers. C++ allows you to create classes which manage their own memory via constructors and destructors. And scoping coordinates that memory management automatically. Biggest regret? That I didn't learn C++ sooner. But it's not for everybody. I get that.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: PascalDragon on December 01, 2019, 10:13:22 am
Sorry, I know I'm not qualified to post here but I would like to see someday people could come up with kernel module written in Pascal, people used Pascal to develop their existing OS side by side with C thanks to the painless interfacing between Pascal and C, we could import C header and have it generate working Pascal unit without having to edit anything by hand... Ah, it's just dreaming!
Take a look here (https://wiki.freepascal.org/linux/kernel/module_development). Don't know if it still works though. :-[
And for Windows there is this (https://wiki.freepascal.org/Target_NativeNT#Kernelmode_Hello_World). :)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 04:31:59 pm
Having standalone compilers doesn't mean it is not RAD dependent. At least not any more than C++ does.
It looks like I didn't make the point clearly.  Here is the point: if Delphi and Lazarus (the environments) "magically" vanished, the use of Pascal would drop significantly.  That is not the case with C, FORTRAN and/or COBOL. 

Maybe. But I think if the major use case for e.g. Fortran (Math) or Cobol (Banks) would disappear, the same would happen. It is like saying Pascal is fine, if banks mass-migrated to another language. But then Cobol would be (even more) in trouble.

Quote
Programmers that use those languages don't choose those languages because there is some "cushy" environment available for them, they will probably choose a particular _implementation_ of the language because there is a more flexible/powerful environment for them but, the choice of language isn't determined by that.

As said, I don't believe that. Those languages are just there because they got lucky long ago, and it simply takes a long time to erode. There is nothing to learn there, except getting a niche for yourself.

But creating such a niche is more chance than planning, and can't be achieved by merely copying others.

Quote
For C, Fortran and/or COBOL, as long as there is a decent debugger and editor available in addition to a decent compiler, that's all it takes.  For Pascal, if you take away Delphi and or Lazarus, the result will often be "Goodbye Pascal" (very unfortunately.)

You make it to tooling centric.  It is not about tooling configuration, but about major usecase.

For Pascal RAD languages are the main use case, sure. But the main use cases of Fortran and Cobol have been eroding for decades. (I come from organic chemistry, and even in my time, +/- 2000 many computational  groups were migrating to C++ for computational work). The fact that you can still write fortran with VI doesn't really save them from that.

You are trying to make something out of nothing.

If two out of three of (LLVM,GCC,VS) die, you have probably also a significant drop. Even more so if the rumours are true that VS will change to LLVM. (which I still find a bit odd)

Cutting out the most major players always hurts. For any language.
If two out of the three major implementations of the C language were to disappear, the most likely result is that a replacement implementation would appear shortly thereafter.  That cannot be said about Pascal.

That depends. If they disappear, the related multinationals will probably ALSO migrate to something different (like Rust), severely eroding C's dominance in system programming.

Of course C's dominance and associated inertia in that space is so large that it might still remain fairly strong (on e.g. the linux business alone).   Cobol and Fortran are much more vulnerable however.

Quote
Quite a few C compilers have come and gone before we got to the current status quo but, C remained popular.

Not really. It has been eroding and retreating on its old system programming niche for decades now. Application level C has been going only down since 2000, with C++ and C#/Java picking up most of the slack. Even GNU migrated several major codebases (GCC,GDB) to C++.

Those languages stood or fell by their 4GL database product. Lazarus/Delphi is different that it makes apps, and a much wider array.
But Pascal has the same weakness those 4GL database products have/had.  The popularity of Pascal is dependent on the RAD environments.  Only a minority choose Pascal because of the language's power, the majority choose it because of the RAD environments associated with it.

I think that is a gross oversimplification.  If only because those other languages often just tied you to one or two database products.

But yes, if you are not a top 5 language, you are vulnerable. No question about that.

If C had lost Unix in say 1990, most of us couldn't even name it by now.
That's quite likely to be true but, the fact is, it was used to develop a successful O/S. It proved that, in the hands of a reasonably knowledgeable programmer it is powerful enough to write an O/S with it. Pascal doesn't have that and that makes a big difference to programmers that code low level routines.

Both Windows and Mac OS  originally had large portions in Pascal. So this is simply not true.

Cobol is already more or less in that space (except the much regurgitated "in financial institutions", but most of that is heresay rather than actual practical knowledge).
Poor COBOL language.  Non COBOL programmers love to put it down.  I just want to point out that just because it is hearsay to you, it doesn't mean it is actually hearsay.  It is a _fact_, not hearsay, that you'll find a lot more COBOL code in financial institutions than you'll find Pascal code.

IMHO most of that sentiment was (C) 2000, and back then it was already decreasing. Of course a lot of code is not touch and will run another 40 years with minimal maintenance, but does that mean anything for the status of the language Cobol *NOW*. ?

It is just the same inertia, that large bodies of code long ago don't disappear overnight. Sure some maintenance and expansion is done, but IMHO you make that to be much more than it is worth, and deflect criticism on those conclusions with simplistic "but it is still more than Pascal" jabs. Pointless.

but loosing slowly to C++ libraries with scripting languages on top of them.
It's quite likely there is some of that but, I'm rather skeptical that they'll ever be able to displace FORTRAN.  You can use a shoe as a hammer but, shoes are very unlikely to displace hammers.

Fortran is not a hammer but a rock, which is the traditional way of hammering. Relatively simple, the first tool available widely, but slowly replaced by more refined and focused tools.

And as said Fortran was already decreasing in computational maths  (at least in the chemistry sphere) in the early 2000s. I haven't kept up though.

But the delusion is that it has anything to do with features or planning. They just hit the jackpot somewhere during their existence in being tied to an application that was so big it became self-fulfilling, and which will take a long time to atrophy naturally.
Undoubtedly there is likely a good bit of that in the case of C but, very little of that in the continued use of FORTRAN and COBOL.

Linking it to properties of the language, or some grand plan is just delusional. Chance and other non technical, non-language reasons. Nothing more.
It's not as delusional as you are implying.  C is successful in system programming because it demonstrated that it can be used for that purpose _and_ no comprehensive better alternative has showed up.  C won the systems programming race in spite of its being a race horse in a wheelchair, because in spite of its wheelchair having dodecagonal wheels, the other horse's wheelchairs had square wheels.  Rather regrettably, programmers get used to dodecagonal wheels much too easily (and no matter how poorly they perform, there is always a programmer ready to point out "it works!", therefore no better way should be implemented - that should sound familiar to you.)

I totally disagree. IMHO it is just old codebases and inertia. The inertia is what kept the alternatives away, not the features. But C doesn't evolve and the gap is getting bigger and bigger.  Specially since the system part is getting bigger and bigger.

Don't get me wrong, the inertia is not over yet (contrary to cobol and fortran which are decreasing), but new contenders will start to eat.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: simone on December 01, 2019, 04:39:52 pm
My point of view is that every programmer can choose the language according to his own skills and needs.  I love the Object Pascal and I really like the philosophy of Lazarus & FPC.  I have no doubt about this.  My painful question is another.  In a software project that involves an important investment in terms of resources, the choice of the programming language and the development environment must ensure a reasonable degree of certainty about the future.  Lazarus and FPC are carried out by volunteers who generously offer their time and knowledge to the community.  But who can guarantee that this will still be possible for a reasonably long time?
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 01, 2019, 05:11:52 pm
Sorry, I know I'm not qualified to post here but I would like to see someday people could come up with kernel module written in Pascal, people used Pascal to develop their existing OS side by side with C thanks to the painless interfacing between Pascal and C, we could import C header and have it generate working Pascal unit without having to edit anything by hand... Ah, it's just dreaming!
Take a look here (https://wiki.freepascal.org/linux/kernel/module_development). Don't know if it still works though. :-[
And for Windows there is this (https://wiki.freepascal.org/Target_NativeNT#Kernelmode_Hello_World). :)

The code looks so alien, specially the Linux version. Could we bring RAD development to cover this area also? Being able to develop kernel module the easier way. Currently, it's no benefit to prefer Pascal over C for such a job, but if we could make this job become as easy as drag and drop to design a form, it'll be a real game changer  :)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: kupferstecher on December 01, 2019, 05:16:40 pm
In my point of view there are a lot of people longing for an alternative for c-style languages, and that is the real chance of Pascal and also one reason for its current success. And there is success. The community may not be the biggest, but there are also young people starting with FreePascal/Lazarus and not only such coming from Delphi or with old codebases in the cellar. Also FreePascal reaches new markets, the mobile platforms are an example.

Also the shrink of the desktop market in my eyes is a great chance for Lazarus, as there won't come up other significant tools, while Lazarus is getting better and better.
And thats how I came to Lazarus, in a elektronics forum I read: "If you want to make multiplattform GUI applications you  h a v e  to use Lazarus". This was about 5 years before.

Some concepts like the begin..end (which I consider nearly as bad as the c brakets "{}") are repelling some potential users, but perhaps it's not possible to overcome such legacies.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 05:17:51 pm
My point of view is that every programmer can choose the language according to his own skills and needs. 

Development system as a whole. Language is only a part of that.

Quote
I love the Object Pascal and I really like the philosophy of Lazarus & FPC.  I have no doubt about this.  My painful question is another.  In a software project that involves an important investment in terms of resources, the choice of the programming language and the development environment must ensure a reasonable degree of certainty about the future. 

In reality there are very few such guarantees, with any language. While languages might continue to exist, quite often frameworks do not. As soon as your specific niche dies, it can be very painful.

How painful depends on how hard you want it to succeed. At some point you might need to manage parts of your toolchain and libraries yourself.  Lazarus/Free Pascal gives you that possibility.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 01, 2019, 05:31:34 pm
I often hear people on this forum praise Pascal and bash C, e.g: C code is ugly, C code is very difficult to parse... I'm not an expert in this area but I would say C++ tooling already filled the gap. Eclipse CDT (I'm using the Cevelop version) is miles a head of Lazarus, let alone Visual Studio or CLion. QtCreator also very decent. I'm saying about their code completion ability, aka intellisense, not RAD development, which render Lazarus nothing more than a mere text editor embedded into a RAD environment. Some text editors with proper language server setup even could outpower Lazarus. Don't get me wrong, I'm saying the truth.

I didn't tried it (because I don't like anything Microsoft related) but I think people which only do command line programming would switch to VSCode immediately if TMS's Object Pascal extension's quality become somewhat as good as the C# counterpart. I know Lazarus will not care because it's mostly about GUI and RAD, not cmd programs.

Tooling is the most important thing I would consider before choosing a programming language. Despite how good a language is, without a decent IDE it's not an option. I will prefer C/C++ with it current IDE support now over Lazarus/Pascal, if I'm not doing GUI, though  >:D
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 01, 2019, 05:37:46 pm
In my point of view there are a lot of people longing for an alternative for c-style languages, and that is the real chance of Pascal and also one reason for its current success. And there is success. The community may not be the biggest, but there are also young people starting with FreePascal/Lazarus and not only such coming from Delphi or with old codebases in the cellar. Also FreePascal reaches new markets, the mobile platforms are an example.

Also the shrink of the desktop market in my eyes is a great chance for Lazarus, as there won't come up other significant tools, while Lazarus is getting better and better.
And thats how I came to Lazarus, in a elektronics forum I read: "If you want to make multiplattform GUI applications you  h a v e  to use Lazarus". This was about 5 years before.

Some concepts like the begin..end (which I consider nearly as bad as the c brakets "{}") are repelling some potential users, but perhaps it's not possible to overcome such legacies.

I would vote for FreeBasic over FreePascal if I'm choosing a C alternative with just like C but friendlier, but you will have choose for yourself a limitted subset of the FreeBasic language, though, this language has so many keywords that make me sick. Making C library binding for FreeBasic also easier than for FreePascal, you just check the language and will immediately see this, how similar to C it is!

About begin..end I'm disagree. Do you consider using identation and space like Python is better than curly braces or begin..end? If you think so, I have nothing to said.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: simone on December 01, 2019, 05:45:50 pm
Development system as a whole. Language is only a part of that.

I absolutely agree.  My reflection concerns languages ​​and IDEs because this is the subject of the thread.

In reality there are very few such guarantees, with any language. While languages might continue to exist, quite often frameworks do not. As soon as your specific niche dies, it can be very painful.

I also agree on this point, but always limiting myself to the programming language, Object Pascal is a much riskier choice, because in fact there are only two compilers / IDEs.

How painful depends on how hard you want it to succeed. At some point you might need to manage parts of your toolchain and libraries yourself.  Lazarus/Free Pascal gives you that possibility.

True in principle, but I don't know how concretely it is possible on a large scale.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on December 01, 2019, 05:59:01 pm
In my point of view there are a lot of people longing for an alternative for c-style languages, and that is the real chance of Pascal and also one reason for its current success. And there is success. The community may not be the biggest, but there are also young people starting with FreePascal/Lazarus and not only such coming from Delphi or with old codebases in the cellar.

Note that Pascal (I mean "modern" Pascal, as in Delphi) was not really positioned as an alternative to C/C++ but as a contender for the then flourishing Visual Basic (for Windows) market, and its main strengths were the two-way IDE and database access. That's in fact from where the name came: "Where does one go to consult the Oracle? To Delphi" :)

C and Pascal where, in the beginning, sister languages descending (by devious routes in the case of C) from Algol but their paths diverged relatively quickly (in 10-20 years); despite the traditional "war" of C vs. Pascal, they came to be applied to different purposes, system-level vs. applications programming.

Here Borland did a diservice to Pascal by positioning it against VB. Of course, they had no BASIC while they did have a C/C++ product so it made some kind of sense to try to lure away VB users to Delphi. The problem is that it made Delphi/Pascal look as just an alternative to VB, while C/C++ programmers could select between VC and BC (or Watcom!) and keep using their beloved language. The end result was to make Pascal a cousin of BASIC (with all it entails) instead of a contender with C, so lots of Pascal programmers ended up "updating" from Pascal to C/C++ which had the advantage of being the "API language" everywhere but on MacOS (and even there, after a while).
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 05:59:24 pm
In reality there are very few such guarantees, with any language. While languages might continue to exist, quite often frameworks do not. As soon as your specific niche dies, it can be very painful.

I also agree on this point, but always limiting myself to the programming language, Object Pascal is a much riskier choice, because in fact there are only two compilers / IDEs.

I used to think that way too, but when I saw people that migrated from Delphi to MS in the dot com boom suffer and despair in the 2005-2008 period when Microsoft lost interest in MFC and tried to force everybody to .NET, I realised that in practice it is rarely so simple.

VB6 and C++ MFC were at that point ( the years before .NET 2 was released) the most used application toolchains, at that point recommended by the most dominant vendor, and STILL both got hit really, really hard, while according to such philosophies that shouldn't be possible.

At the same time, I was using Delphi, which was universally ridiculed and said to be dying. I've had only one medium migration (the unicode change in 2009), and all other routes would have required investments and maintenance that would now have been invalidated for a large part.

I then realised that such cliche certainties are just for self-comforting purposes, and for IT-managers to avoid being held accountable if something goes wrong.

In reality there is no certain way of picking a very long term winner. You just try to make the choice for the coming few years the best you can, and then you'll just see.  And in general, most threats don't really materialize, meaning that most investments to mitigate them are in vain, or at least not worthwhile.

How painful depends on how hard you want it to succeed. At some point you might need to manage parts of your toolchain and libraries yourself.  Lazarus/Free Pascal gives you that possibility.

True in principle, but I don't know how concretely it is possible on a large scale.

So assume you now made MS MFC apps on Windows, and Microsoft declared that the next VS only would do .NET gui apps (which, in 2007 was actually pretty much what seemed to be happening). What do you do?
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 06:03:21 pm
borland did a diservice to Pascal by positioning it against VB. Of course, they had no BASIC while they did have a C/C++ product so it made some kind of sense to try to lure away VB users to Delphi. The problem is that it made Delphi/Pascal look as just an alternative to VB, while C/C++ programmers could select between VC and BC (or Watcom!) and keep using their beloved language. The end result was to make Pascal a cousin of BASIC (with all it entails) instead of a contender with C, so lots of Pascal programmers ended up "updating" from Pascal to C/C++ which had the advantage of being the "API language" everywhere but on MacOS (and even there, after a while).

The problem was that in the late nineties and early 2000s Microsoft employed predatory pricing with VS. The investments in it were huge, yet pricing was set to exactly 3/4 of Delphi.

There is no course that leads to success in such situation where one competitor pours vast sums into its IDE from its OS sales, while the other must do with the money they get of IDE sales.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on December 01, 2019, 06:22:11 pm

Honestly, I think you're in denial.  The main reason FPC is attractive to some programmers is the existence of Lazarus, not because of the features/abilities of the Pascal language.   That is supported by the _fact_ that GNU Pascal is dead.  If there had been a Lazarus like environment for GNU Pascal, it _might_ still be alive (FPC is).



Maybe. But I think if the major use case for e.g. Fortran (Math) or Cobol (Banks) would disappear, the same would happen.
The major "use case" of FORTRAN and COBOL are not about to disappear anytime soon.  Business applications are needed and so are heavy computational applications.  There is no major "use case" (as you put it) for Pascal.  The only reason it still has some life is because applications such as Delphi and Lazarus allow some people with very little programming knowledge to write simple programs.  Without that crutch Pascal would be gone (as GNU Pascal has already demonstrated.)


As said, I don't believe that. Those languages are just there because they got lucky long ago, and it simply takes a long time to erode. There is nothing to learn there, except getting a niche for yourself.
Unix wasn't written with "luck".  It was written in/with C.   Also, a language, in this case C, that has roughly 16% of the programmers' mindshare is hardly a "niche" language.  Object Pascal at roughly 2% is a niche and one it wouldn't have if it weren't because of the RAD environments that depend on it.

But creating such a niche is more chance than planning, and can't be achieved by merely copying others.
Some luck is involved but, COBOL is a good example of a language whose existence is due to planning and, it was quite effective.  As far as the copying you mention, just about every language copies from other languages.  The syntax may vary significantly but the programming concepts built into the language, don't.

You make it to tooling centric.  It is not about tooling configuration, but about major usecase.
Not for Pascal.  It's very likely that the reason Pascal still has a little bit of life is because of the tools that use it, specifically, Delphi and Lazarus.  Without them, it's quite likely that it would be shrink-wrapped in a coffin.

For Pascal RAD languages are the main use case, sure.
Pascal isn't a RAD language, not even close but, it has degraded into one which is why I compare it to Clarion and other such environment languages. Pascal's "main use case" is being a language to teach programming and, other choices, such as C are now preferred by most educational institutions.

But the main use cases of Fortran and Cobol have been eroding for decades.
There is some truth to that.  COBOL applications area has eroded because of the availability of relational database systems which include very flexible and powerful languages (PL/SQL comes to mind) but, those RDBMs do great when using the database but, far from great when it comes to providing the capabilities of a full fledged programming language. 

(I come from organic chemistry, and even in my time, +/- 2000 many computational  groups were migrating to C++ for computational work). The fact that you can still write fortran with VI doesn't really save them from that.
IMO, choosing C++ over FORTRAN for computationally intensive programs borders on insanity.  The FORTRAN code will be a lot clearer, easier to understand, easier to maintain and much less prone to contain bugs than whatever can be produced in C++ to accomplish the same goal.  That said, it is true that C++ has managed to erode some of FORTRAN's territory but, not much.

You are trying to make something out of nothing.
I'm simply trying to show that Pascal has none of the functional advantages other programming languages such as C, FORTRAN and COBOL among others have.  Pascal has no clear useful purpose anymore and that is one of the reasons there is no standards body interested in improving it.  You may call that "nothing" but without that "nothing", Pascal's future is rather uncertain.

If two out of three of (LLVM,GCC,VS) die, you have probably also a significant drop. Even more so if the rumours are true that VS will change to LLVM. (which I still find a bit odd)
That's like saying that if someone dried the Atlantic ocean there wouldn't be any water in it.   In the rather extreme example you offered above, a new C compiler would be written rather quickly.  If Pascal disappeared (both FPC and Lazarus) the implementation of a new Pascal compiler is far from certain.

Cutting out the most major players always hurts. For any language.
Cutting out all the "major players" could happen to Pascal but, rather unlikely to happen to C, COBOL and/or Fortran for instance.

If two out of the three major implementations of the C language were to disappear, the most likely result is that a replacement implementation would appear shortly thereafter.  That cannot be said about Pascal.


That depends. If they disappear, the related multinationals will probably ALSO migrate to something different (like Rust), severely eroding C's dominance in system programming.
The problem with the obvious fallacy you stated above is that, all that C code isn't going to migrate itself to Rust overnight.  Even a company with very large resources that is interested in migrating to Rust will take a very long time to get there and keep depending on C.

It has been eroding and retreating on its old system programming niche for decades now. Application level C has been going only down since 2000, with C++ and C#/Java picking up most of the slack. Even GNU migrated several major codebases (GCC,GDB) to C++.
I've never thought of C as being particularly well suited as an application's programming language.  It's about time it would start losing influence in that area.  It is losing some terrain in that area because, now there are finally some halfway decent alternatives (though Pascal was a good one but, it was eclipsed by all the shiny razzle-dazzle of RAD environments.)

I think that is a gross oversimplification.  If only because those other languages often just tied you to one or two database products.
It's not an oversimplification.  It's the same problem as 4GL language have.  Pascal got tied to RAD environments, namely Delphi and Lazarus.  It lost its self standing, just like a 4GL has no standing without the database(s) they act upon.

Both Windows and Mac OS  originally had large portions in Pascal. So this is simply not true.
The Windows version that included Pascal code couldn't be considered an O/S, it could barely show some data in tiled windows.  The Mac OS was a _joke_ until Apple finally decided to write something that could legitimately be called an O/S by using the BSD code base.  A good portion of the Lisa OS was written in Pascal and the Lisa OS was well known to have some rather significant deficiencies (though, to be fair, a great number of them were not related to its being written in Pascal but, it contributed to showing Pascal as falling short of the mark when it comes to writing an O/S.)

It is just the same inertia, that large bodies of code long ago don't disappear overnight. Sure some maintenance and expansion is done, but IMHO you make that to be much more than it is worth, and deflect criticism on those conclusions with simplistic "but it is still more than Pascal" jabs. Pointless.
Not pointless at all.  You are desperately trying to evade the fact that without Delphi and Lazarus (environments for RAD), the Pascal language would probably be dead by now.  Unlike Pascal, neither COBOL nor FORTRAN depend on an environment to keep them alive, they stand on their own merits, Pascal did at one time but, not anymore and, that is a very significant problem.

The inertia is what kept the alternatives away, not the features.
We definitely disagree.  In spite of the fact that I strongly dislike C, I still use it because there are times when the combination of features it offers makes getting the job done easier in C than in Pascal (and that is _very_ annoying because there is _no_ good reason for Pascal to be missing those features, it is because of people like _you_ who refuse to improve the language.)


The one thing all these discussions have in common is, they lead nowhere and don't produce any desirable results.  That may be another reason why there hasn't been a Pascal standard in so many years.




In a software project that involves an important investment in terms of resources, the choice of the programming language and the development environment must ensure a reasonable degree of certainty about the future. 
Quite true and, institutions which use C, COBOL or FORTRAN don't have to worry about that.  Institutions which use Pascal definitely do.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: simone on December 01, 2019, 06:25:03 pm
 
So assume you now made MS MFC apps on Windows, and Microsoft declared that the next VS only would do .NET gui apps (which, in 2007 was actually pretty much what seemed to be happening). What do you do?

If I were forced to look for an alternative to Object Pascal/FPC/Lazarus (and I hope this never happens), I would never choose proprietary technologies like those from Microsoft, just to avoid lock-in problems like the one you described.  In the desktop scenario, for example, I would choose C ++ with one of many  opensource compilers / IDEs available.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 06:44:22 pm
Honestly, I think you're in denial. 

Of what exactly?  Let's summarize:

I don't dispute the facts that Pascal is not the most popular one. I don't dispute that Fortran and Cobol have dying niches, I don't dispute that while C is slowly getting irrelevant in application space, real threats in the system space have still to emerge (maybe with Rust?).

I agree to differ on the fact that I think they have been in decline for nearly two decades (less so for C), and that you believe they are still going strong.

BUT the core disagreement is that  you really want to push the narrative that this is because of intrinsic properties of either language or its ecosystem. (because they use editors, not RADs)

I don't buy that at all, I believe that the indisputed facts are the result of inertia relating to dominant positions in the (quite distant) past, and ties with dominant vendors during that time, and thus there is not much to learn from these languages wrt strategy or by mindlessly copying features.

Neither of those will convince those users to cross-over.

Quote
The main reason FPC is attractive to some programmers is the existence of Lazarus, not because of the features/abilities of the Pascal language.   That is supported by the _fact_ that GNU Pascal is dead.  If there had been a Lazarus like environment for GNU Pascal, it _might_ still be alive (FPC is).

GPC failed to catch on long before Lazarus was even viable. They never even made TP level. See an old write-up of mine at http://www.stack.nl/~marcov/gpctxt.txt

In some ways, GPC problems (as in low non-core submissions) are still relevant, in FPC context today.

Quote
The major "use case" of FORTRAN and COBOL are not about to disappear anytime soon. 

The major use cases are totally in decline. Old systems are still maintained/expanded, but it is getting less and less and has been the case for close to two decades.

The only money/mindshare there is to keep the old junk running a bit longer.

Quote
There is no major "use case" (as you put it) for Pascal.  The only reason it still has some life is because applications such as Delphi and Lazarus allow some people with very little programming knowledge to write simple programs.  Without that crutch Pascal would be gone (as GNU Pascal has already demonstrated.)

Pascal doesn't have some dominant historic position anymore. True. So what ? As I showed in the thread with Simone, that is at most a false security.

Unix wasn't written with "luck".  It was written in/with C.   

Self furfilling argument. I say C is only important because of Unix, you say Unix is great because of C. So we together we have a circular argument here.

Quote
Also, a language, in this case C, that has roughly 16% of the programmers' mindshare is hardly a "niche" language.  Object Pascal at roughly 2% is a niche and one it wouldn't have if it weren't because of the RAD environments that
depend on it.

Neither was true at the point they are started to divergate.

I think if there is a point to be made, is that Pascal was mostly entrenched in Europe, while the emerging IT superpowers were nearly all US based (except for SAP that continued to use Pascal for a while).


Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 06:47:47 pm
If I were forced to look for an alternative to Object Pascal/FPC/Lazarus (and I hope this never happens), I would never choose proprietary technologies like those from Microsoft, just to avoid lock-in problems like the one you described.  In the desktop scenario, for example, I would choose C ++ with one of many  opensource compilers / IDEs available.

For applications with a non-trivial exposure to frameworks and OS, I think open source is even worse. The course of open source projects can change at a whim if there is some hype. Just look at the current Python hype in AI (which doesn't make sense to anybody who knows anything about either)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 01, 2019, 06:55:04 pm
Honestly, I think you're in denial.  The main reason FPC is attractive to some programmers is the existence of Lazarus, not because of the features/abilities of the Pascal language.   That is supported by the _fact_ that GNU Pascal is dead.  If there had been a Lazarus like environment for GNU Pascal, it _might_ still be alive (FPC is).

Honestly, you and Thaddy are the two members I hated most (I used to have a previous nick on this forum, but I abandoned it, I have never banned or received any moderation messages) but this time I'm pleased with this answer and I'm 100% agreed with you. I choose to come back to Pascal because of Lazarus and FPC's cross compiling ability, one codebase, I could build for all of the platforms FPC supports. Despite being my first programming language, but I admit I don't like Pascal because it took more times to write a Pascal program compared to an equivalent C/C++ program and it has too many dialects, yes, I even proposed a new dialect to help transpile program from other language to Pascal easier, but I found it's uncertain with Pascal. There is nothing as -std=c++98 to make sure even if the world switched to c++20, my old program still compiles with a modern compiler. The fact is, I have to use Java and Pascal not because I like them but because the two are portable. Java code runs everywhere. Pascal code compiles everywhere. I even have to stick to Java 8, which is a boring and wordy language just like Pascal, for compatibility reason, despite we already have Java 11 with many of the improvements ported back from C#, for example, type inference with var.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 07:08:28 pm
I would vote for FreeBasic over FreePascal if I'm choosing a C alternative with just like C but friendlier, but you will have choose for yourself a limitted subset of the FreeBasic language, though, this language has so many keywords that make me sick. Making C library binding for FreeBasic also easier than for FreePascal, you just check the language and will immediately see this, how similar to C it is!

I've been monitoring FB since 2005-2006, but didn't like exactly that, their increasing reliance on C. Both the language (many posted pieces are more macro code than actual code, and I was always though that overreliance on macro code demonstrates fallacy of the actual language), and the build environment.

In the past there was only one FB distribution (for say, windows), now there is FB-gcc8  FB-gcc7.x etc etc, all with different problems. Ugh!

We've seen  it all before, just check the GNu Pascal link I quoted to 440bx

Quote
About begin..end I'm disagree. Do you consider using identation and space like Python is better than curly braces or begin..end? If you think so, I have nothing to said.

IMHO neither. While I prefer begin..end over {} (that's because the human mind is trained to quickly read words, but slows down on symbols, just read normal text, and then math equations and you feel what I mean), I think the core fallacy of both is differentiating between single line and multi line blocks.

If you don't have single lines blocks, you can omit the opening block delimiter for all but the "function/method" block. The result is more regular, and avoids the errors that come from mismanages single vs multi statement blocks.

But backwards compatibility is important. But I still regret that this principle didn't caught on more when Pascal's successor Modula2 came out in +/- 1980

As for Python's solution: I never took that seriously.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on December 01, 2019, 07:30:54 pm
About begin..end I'm disagree. Do you consider using indentation and space like Python is better than curly braces or begin..end? If you think so, I have nothing to said.

To be fair, good practice in almost any language requires to have a proper indentation/spacing discipline. The main difference in this respect between Python and other langs is that in Python it's enforced by the sintax while in the others is kind of "social contract", but if you look into most well maintained codebases, the differences are often minimal. A proper "if ... then ..else" will look almost exactly the same (at "bird-view") in Pascal, C, Python, or almost whatever. Fact is that most (all?) languages have their own "rules" for this, albeit open ones, so in the end all of us end up doing, on our own, what Python programmers do forced by the syntax rules.

I think (JMO) that a lot of the resistance to Python's strict rules re. indentation/space came about because it was  seen as a return to the Bad Old Days where you had to write your code in exact columns of the coding-sheet: say, labels at zero, verb/keyword at 8, parameters at 15, etc. which left a lot of room for stupid errors caused by a misplacement. :)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 08:17:20 pm
I think (JMO) that a lot of the resistance to Python's strict rules re. indentation/space came about because it was  seen as a return to the Bad Old Days where you had to write your code in exact columns of the coding-sheet: say, labels at zero, verb/keyword at 8, parameters at 15, etc. which left a lot of room for stupid errors caused by a misplacement. :)

Well yes. And hard tabs, ... and if you do a bit of copy and paste you have to rearrange things, and since it mandatory it must be right.

It is not that the Python way is impossible, I just think it complicates more than it solves.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on December 01, 2019, 09:01:36 pm
[...] and if you do a bit of copy and paste you have to rearrange things, and since it mandatory it must be right.

That's one of the things where a well thought-out editor comes mightily handy. I just love the way Lazarus reindents on copy/paste ... Mind, it doesn't always get it right: it fails for some (few) border cases, but all in all it hits it right most of the time. :)

Off-topic, I know. Sorry :-X
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: kupferstecher on December 01, 2019, 09:14:26 pm
While I prefer begin..end over {}
[...]
I think the core fallacy of both is differentiating between single line and multi line blocks.
Thats the point, the requirement for single and multi line blocks prevents ideal solutions.
There is either an annoying "begin" or compact single line blocks are not possible.
Fortran knows two constructs for both cases (Is this the special feature making Fortran so suitable for number crunching?~):
Single line:
 if(true) dosomething..
Multiline:
 if(true) then
  dosomething..
  dosomemore..
 endif

Two different syntaxes are imho quite disturbing, it's definitely not an 'ideal' solution.
The c-brakets are too subtle, they are just not suitable to visibly signal the finishing of a block.

Quote
If you don't have single lines blocks, you can omit the opening block delimiter for all but the "function/method" block. The result is more regular, and avoids the errors that come from mismanages single vs multi statement blocks.
Thats my favoured concept, ideally closed by "endif"/"enddo" (but only optionally replacing "end").

To be fair, good practice in almost any language requires to have a proper indentation/spacing discipline. The main difference in this respect between Python and other langs is that in Python it's enforced by the sintax while in the others is kind of "social contract"
A compiler could enforce some indentation without using it as syntax element (by throwing errors for unalligned block indentation).
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: lucamar on December 01, 2019, 09:22:24 pm
A compiler could enforce some indentation without using it as syntax element (by throwing errors for unalligned block indentation).

But then it would make it kind of a "syntax" element, and you'd have to "correct" the source to make it compile right. It might not be a syntax element from the language p.o.v. but if nevertheless the compiler enforces it, it becomes practicaly one.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 01, 2019, 10:25:44 pm
[...] and if you do a bit of copy and paste you have to rearrange things, and since it mandatory it must be right.

That's one of the things where a well thought-out editor comes mightily handy. I just love the way Lazarus reindents on copy/paste ... Mind, it doesn't always get it right: it fails for some (few) border cases, but all in all it hits it right most of the time. :)

Off-topic, I know. Sorry :-X

Well no. It is ontopic. But the problem if it is mandatory it has to be right all the time. And I think that makes it a case of "cure worse than disease"
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: del on December 02, 2019, 12:17:51 am
Fact is that most (all?) languages have their own "rules" for this, albeit open ones, so in the end all of us end up doing, on our own, what Python programmers do forced by the syntax rules.

The problem is that Python doesn't really enforce anything beyond style. And if a loop or conditional ends too soon or too late cuz of indentation - Python couldn't care less. And it becomes debugging hell if one line gets messed up. And cuz Python moves with sloth-like speed, you may not know it's messed up for a good long time. There are better ways to enforce indentation styles than making nasty bugs the penalty for non-compliance.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: MarkMLl on December 02, 2019, 10:21:37 am
I'm no lover of Python syntax, having been bitten before by somebody's attempt to specify structure entirely by indentation. But I always find it useful to quote from an indisputable authority, in this case Ken Thompson:

Quote
As a simple, self-contained example, consider the representation of program structure. Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks.
https://talks.golang.org/2012/splash.article (https://talks.golang.org/2012/splash.article)

MarkMLl


Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: Thaddy on December 02, 2019, 10:31:23 am
For applications with a non-trivial exposure to frameworks and OS, I think open source is even worse. The course of open source projects can change at a whim if there is some hype. Just look at the current Python hype in AI (which doesn't make sense to anybody who knows anything about either)
You forgot to mention that most of the computer science advances in the past 25 years come from open source, not closed source.
This includes better algorithms, better techniques, better everything.
It is about fundamentals that have changed so much.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: PascalDragon on December 02, 2019, 11:37:25 am
Sorry, I know I'm not qualified to post here but I would like to see someday people could come up with kernel module written in Pascal, people used Pascal to develop their existing OS side by side with C thanks to the painless interfacing between Pascal and C, we could import C header and have it generate working Pascal unit without having to edit anything by hand... Ah, it's just dreaming!
Take a look here (https://wiki.freepascal.org/linux/kernel/module_development). Don't know if it still works though. :-[
And for Windows there is this (https://wiki.freepascal.org/Target_NativeNT#Kernelmode_Hello_World). :)

The code looks so alien, specially the Linux version. Could we bring RAD development to cover this area also? Being able to develop kernel module the easier way. Currently, it's no benefit to prefer Pascal over C for such a job, but if we could make this job become as easy as drag and drop to design a form, it'll be a real game changer  :)
RAD has no place in kernel environment / driver development. More often than not you need to get your hands really/ dirty to interact with hardware. I know that, cause I do that at work (though there in user space cause my company's OS is a microkernel with drivers in user space).

Some concepts like the begin..end (which I consider nearly as bad as the c brakets "{}") are repelling some potential users, but perhaps it's not possible to overcome such legacies.
This is a central part of the Pascal language. You'd be better off implementing a new language than to change that.

Honestly, I think you're in denial.  The main reason FPC is attractive to some programmers is the existence of Lazarus, not because of the features/abilities of the Pascal language.   That is supported by the _fact_ that GNU Pascal is dead.  If there had been a Lazarus like environment for GNU Pascal, it _might_ still be alive (FPC is).

Honestly, you and Thaddy are the two members I hated most (I used to have a previous nick on this forum, but I abandoned it, I have never banned or received any moderation messages) but this time I'm pleased with this answer and I'm 100% agreed with you. I choose to come back to Pascal because of Lazarus and FPC's cross compiling ability, one codebase, I could build for all of the platforms FPC supports. Despite being my first programming language, but I admit I don't like Pascal because it took more times to write a Pascal program compared to an equivalent C/C++ program and it has too many dialects, yes, I even proposed a new dialect to help transpile program from other language to Pascal easier, but I found it's uncertain with Pascal. There is nothing as -std=c++98 to make sure even if the world switched to c++20, my old program still compiles with a modern compiler. The fact is, I have to use Java and Pascal not because I like them but because the two are portable. Java code runs everywhere. Pascal code compiles everywhere. I even have to stick to Java 8, which is a boring and wordy language just like Pascal, for compatibility reason, despite we already have Java 11 with many of the improvements ported back from C#, for example, type inference with var.
We have a strong emphasis on backwards compatibility which is usually only disturbed when a bug enters the field.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: marcov on December 02, 2019, 01:15:09 pm
For applications with a non-trivial exposure to frameworks and OS, I think open source is even worse. The course of open source projects can change at a whim if there is some hype. Just look at the current Python hype in AI (which doesn't make sense to anybody who knows anything about either)
You forgot to mention that most of the computer science advances in the past 25 years come from open source, not closed source.
This includes better algorithms, better techniques, better everything.
It is about fundamentals that have changed so much.

Opinion. Most of those are done by people in paid positions with big IT. The open source ideal of a lone hacker who revolutionizes the world in an attic chamber was never really true, and is even less so today.

One could argue there is mainly dress-up how the same work is presented.  Every generation has its buzzwords, Open Source , green and AI  etc. If you think Open Source is still a buzzword, you are old :-)

OSS did change things, some things are a bit more open, but at the same time, some open source projects are a lot less open than they were 20 years ago, with most work done in non-public corporate channels
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: Thaddy on December 02, 2019, 03:48:10 pm
Opinion. Most of those are done by people in paid positions with big IT. The open source ideal of a lone hacker who revolutionizes the world in an attic chamber was never really true, and is even less so today.

One could argue there is mainly dress-up how the same work is presented.  Every generation has its buzzwords, Open Source , green and AI  etc. If you think Open Source is still a buzzword, you are old :-)

OSS did change things, some things are a bit more open, but at the same time, some open source projects are a lot less open than they were 20 years ago, with most work done in non-public corporate channels
The point is not about opinion nor is it about open source but about published research papers. I was not quite precise enough.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on December 02, 2019, 04:08:34 pm
The point is not about opinion ....
Just in case you haven't noticed it before, it is quite common for someone who doesn't like the facts to re-brand them as "opinion".  For some, the Pythagorean theorem is just an opinion from a guy named Pythagoras.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 04, 2019, 04:38:23 pm
The point is not about opinion ....
Just in case you haven't noticed it before, it is quite common for someone who doesn't like the facts to re-brand them as "opinion".  For some, the Pythagorean theorem is just an opinion from a guy named Pythagoras.

Except this time you are plain wrong and your example is not an exact synonym. Yes, the fact is most of the so called opensource were not built by volunteers but by paid developers. You could check the Linux source tree and you will find out it's often A from Redhat has commit, B from Novell has commit... but not a no-name developer has commit... Even Linus himself is employed by Redhat  8-)
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on December 04, 2019, 06:14:45 pm
Except this time you are plain wrong...
First, presuming that is the case, it wouldn't be the first time and regrettably it won't be the last either.  IOW, that statement isn't particularly revealing nor informative.

Yes, the fact is most of the so called opensource were not built by volunteers but by paid developers. You could check the Linux source tree and you will find out it's often A from Redhat has commit, B from Novell has commit... but not a no-name developer has commit... Even Linus himself is employed by Redhat  8-)
I don't know for a fact that the "so called opensource" as you call it was "built" by paid developers but, I do know for a fact that, all programmers, like everyone else have to make a living which means they are getting paid to perform some work.  Your underlying premise that because programmers are being paid to do something means that most open source software is from developers paid to produce it is simply unfounded and extremely likely to be _false_.  As a counter example to your statement, far from unique, is the work of Richard Stallman.  No one paid Stallman to start the movement which is essentially the seed of today's open source.

Other examples that are particularly appropriate are Lazarus and FPC.  While it may be the case that a few developers are paid to contribute to them, the majority of the contributions come from programmers who invest part of their free time in contributing to the projects.  This forum is filled with the contributions of many programmers in the form of software and free support that is the result of their passion for programming and the satisfaction they derive from helping others, not from being paid to do so.

Your assertion that the fact is most of the so called opensource were not built by volunteers but by paid developers is unfounded and to a great extent _false_.

Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: guest64953 on December 04, 2019, 06:25:29 pm
Except this time you are plain wrong...
First, presuming that is the case, it wouldn't be the first time and regrettably it won't be the last either.  IOW, that statement isn't particularly revealing nor informative.

Yes, the fact is most of the so called opensource were not built by volunteers but by paid developers. You could check the Linux source tree and you will find out it's often A from Redhat has commit, B from Novell has commit... but not a no-name developer has commit... Even Linus himself is employed by Redhat  8-)
I don't know for a fact that the "so called opensource" as you call it was "built" by paid developers but, I do know for a fact that, all programmers, like everyone else have to make a living which means they are getting paid to perform some work.  Your underlying premise that because programmers are being paid to do something means that most open source software is from developers paid to produce it is simply unfounded and extremely likely to be _false_.  As a counter example to your statement, far from unique, is the work of Richard Stallman.  No one paid Stallman to start the movement which is essentially the seed of today's open source.

Other examples that are particularly appropriate are Lazarus and FPC.  While it may be the case that a few developers are paid to contribute to them, the majority of the contributions come from programmers who invest part of their free time in contributing to the projects.  This forum is filled with the contributions of many programmers in the form of software and free support that is the result of their passion for programming and the satisfaction they derive from helping others, not from being paid to do so.

Your assertion that the fact is most of the so called opensource were not built by volunteers but by paid developers is unfounded and to a great extent _false_.

FPC + Lazarus can't be compared to the Linux kernel. With big open source projects or some very important ones, it's mostly paid developers contribute to them. I don't want to be rude or ungraceful, but I would say FPC + Lazarus is rather a hobbyist project. Yes, many people used it to develop paid software. But it's just that. FPC + Lazarus is not important enough, or not reached the important enough state for corporations to jump into and driven the development. Think about GCC. Doesn't it developed mostly by corporate? Because it's a very important project. It's a totally different story even though both GCC and FPC are compilers. The fact GCC is much much important because of the C language, the language of system development. Pascal is not that important as a language. You have to accept this. This is a fact.

p/s: Did you know Eclipse is from IBM and Java/Netbeans are from Sun/Oracle? They are all open source software!
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: winni on December 04, 2019, 06:48:09 pm
If Linus Torvalds is employee at Red Hat it is not okay.
If somebody is coding in his off time he is only a hobbiest.

What do you want except nagging?????

I give you a piece of a new kernel and you give me a piece of bread??

Winni
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: Handoko on December 04, 2019, 06:53:41 pm
@440bx, @giahung

It's a tie.

I've just done some search from the Internet and I found this:
https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-open-source/ (https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-open-source/)

Quote
... we find that about 50% of all open source software development has been paid work ...

So, it's a tie and you both win. :D

Volunteering doesn't mean cannot be paid. There was a time when I felt bored, had plenty of time and nothing to do. I volunteered an online job I found on the Internet. I helped them generated 3D images of their mobile banking bus' interior. I didn't think I would receive any money. But because they was happy with the result I done, they later sent me $100.

The equation is simple. If you are nice to others, others will do so to you. I spend some of my time helping newbies in the forum, some of them contacted me just to say thank you.
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: 440bx on December 04, 2019, 07:36:53 pm
FPC + Lazarus can't be compared to the Linux kernel.
I didn't compare FPC + Lazarus with the Linux kernel but, since you mention the Linux kernel, the birth of Linux was not a paid project. TTBOMK, Linus Torvald created Linux on his own free time.  Posted a copy of it on usenet, other programmers found it interesting and contributed to it.  Eventually, after many _unpaid_ contributions, it became clear that it was probably worth a financial investment to turn it into a capable platform that could sustain a business model.

Also, as far as Linux is concerned, if the many GNU programs had not existed, it is unclear what the ultimate fate of Linus' efforts would have been.  It takes a lot of time to develop a capable compiler, linker, make, editor, etc, etc which are all required to make an O/S a usable piece of software.  All that software was, at least initially, unpaid.

With big open source projects or some very important ones, it's mostly paid developers contribute to them.
That might be true but, it happens only after they get big and, before that happens, a lot of people have contributed significantly to it. 

I don't want to be rude or ungraceful, but I would say FPC + Lazarus is rather a hobbyist project.
That might also be true but, the most likely reason is because the Pascal language is not very popular.  If Pascal were more popular and large corporations depended on it, it might not be a "hobbyist project". 

The point isn't that there aren't programmers being paid to develop open source software, the point is that, likely, the bulk of open source software is, at least initially, done by unpaid programmers.  If their project manages to gather enough attention then and, more often than not, only then, are programmers eventually paid to continue developing it.

Think about GCC. Doesn't it developed mostly by corporate? Because it's a very important project.
I don't know if currently most of the development in GCC is done by paid programmers or not but, TTBOMK, Richard Stallman, who wrote GCC, wasn't paid to write it.  That can be said of most, if not all, the initial suite of GNU software.

Pascal is not that important as a language. You have to accept this. This is a fact.
Not only it's a fact, it's a fairly obvious fact but, GCC was not born because someone paid for it to be developed.  Both are the result of an individual's interest in the language, Richard Stallman's in the case of GCC and Florian Klämpfl in the case of FPC.  In most open source projects, money goes into developing the project only after the project has attracted the attention of businesses as a potentially lucrative money-making platform.

p/s: Did you know Eclipse is from IBM and Java/Netbeans are from Sun/Oracle? They are all open source software!
Yes and the main reason Eclipse is open source is to make it more likely to succeed against what it was designed to compete against (I'll let you find out what that was.)

In the case of Java, originally it wasn't open source.  It was Sun proprietary.  _Presumably_, it became open source because proprietary programming languages have a tendency not to fare well in the marketplace.

Just because there are open source projects that are maintained by paid programmers does not mean that most open source projects are maintained by paid programmers.  The majority of open source projects are fairly small and maintained by programmers that invest their free time in developing them.

Lastly, this discussion is _way_ off topic and, should be continued (if at all) in a thread dedicated to it.  That said, I've pretty much said all I cared to say on the subject. 
Title: Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
Post by: MarkMLl on December 08, 2019, 11:03:48 am
Those looking to programming as a life-time carer would do well to become at least acquainted with [COBOL] beyond the mere basics of "it has too many divisons, and sections, and subsections, and is extremely verbose" :)

In fairness, Pascal has const, type and var sections.

MarkMLl