Recent

Author Topic: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991  (Read 12843 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #15 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.

del

  • Sr. Member
  • ****
  • Posts: 258
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #16 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.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #17 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.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #18 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" :)
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #19 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.


lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #20 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. :(
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

julkas

  • Guest
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #21 on: November 30, 2019, 06:01:54 pm »
@lucamar Why GNU Pascal is dead?

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #22 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)
« Last Edit: November 30, 2019, 06:46:46 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #23 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.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #24 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.


« Last Edit: November 30, 2019, 07:26:57 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

del

  • Sr. Member
  • ****
  • Posts: 258
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #25 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.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #26 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

Winni
« Last Edit: November 30, 2019, 07:45:49 pm by winni »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #27 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.


440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #28 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.

« Last Edit: December 01, 2019, 04:02:42 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

del

  • Sr. Member
  • ****
  • Posts: 258
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #29 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.

 

TinyPortal © 2005-2018