Recent

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

marcov

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

guest64953

  • Guest
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #46 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.

marcov

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

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #48 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. :)
« Last Edit: December 01, 2019, 07:33:02 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 #49 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.

lucamar

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

kupferstecher

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

lucamar

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

del

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

MarkMLl

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

MarkMLl


MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #56 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.
Specialize a type, not a var.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #57 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. Don't know if it still works though. :-[
And for Windows there is this. :)

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.

marcov

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

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Standard Pascal ISO 7185:1990 and Extended Pascal ISO/IEC 10206:1991
« Reply #59 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.
Specialize a type, not a var.

 

TinyPortal © 2005-2018