The syntax is timeless, because it is much closer to math than B/BCPL/C heritage.
It has its own issues but overall it is much better thought out than most other languages.
Here is a comment I wrote a couple of months ago with more arguments for Pascal's syntax:
"Yes, Rust does indeed and a long time before that it was Pascal. I really love Pascal's syntax, it makes a lot of sense when you approach it with a math background.
- '=' is for equality only
- assignment is ':=' which is the next best symbol you can find in math for that purpose
- numeric data types are 'integer' and 'real', no single/double nonsense
- 'functions' are for returning values, 'procedures' for side effects
- Function and procedure definitions can be nested. I can't tell you what shock it was for me to discover that's not a thing in C.
- There is a native 'set' type
- It has product types (records) and sum types (variants).
- Range Types! Love'em! You need a number between 0 and 360? You can easily express that in Pascal's type system.
- Array indexing is your choice. Start at 0? Start at 1? Start at 100? It's up to you.
- To switch between call-by-value and call-by-reference all you have to do is change your function/procedure signature. No changes at the call sites or inside the function/procedure body. Another bummer for me when I learned C.
Pascal wasn't perfect but I really wish modern languages had syntax based on Wirth's languages instead of being based on BCPL, B and C."
> numeric data types are 'integer' and 'real', no single/double nonsense
Actually in Free Pascal (and AFAIK Delphi) there are Single and Double (and Extended) that map to 32bit and 64bit floats (Extended depends on the target CPU, e.g. for 32bit x86 is 80bit floats but for 64bit x86 is 64bit floats) since you actually do need to differentiate between the two in practice.
> 'functions' are for returning values, 'procedures' for side effects
FWIW even in Turbo Pascal (i don't remember which exact version) functions could also be used as procedures (the return value was ignored). While in theory separating the two sounds nice, in practice it is often useful to be able to ignore function results.
> Array indexing is your choice. Start at 0? Start at 1? Start at 100? It's up to you.
One additional neat bit is that you don't even have to use numbers, any ordinal type will work. Enums are ordinal types so you can do "type Foo = (Bar, Baz, Bad); FooArray = array [Foo] of Integer;" and then use "Bar, Baz, Bad" to access the array. You can use ranges too.
> To switch between call-by-value and call-by-reference all you have to do is change your function/procedure signature. No changes at the call sites or inside the function/procedure body. Another bummer for me when I learned C.
FWIW i prefer the C# approach of being explicit when you pass something as a reference since it makes it obvious on the call site just by reading the code.
When it comes to real vs float I should not have called the later nonsense. I agree that both have their place depending whether you want to express things at a lower (closer to hardware or wire protocol) level or more abstractly.
It is still sad that languages like C (and even Rust) only offer the lower level types.
What you said about functions and procedures is also true. I still think that it is valuable to have a distinction syntactically, even if they are relatively similar under the hood. Maybe one day we will have a Pascal compiler that can enforce that functions are side-effect free...
> Maybe one day we will have a Pascal compiler that can enforce that functions are side-effect free...
Pure functions are actually one of the WIP functionality in Free Pascal :-). AFAIK the ultimate goal is to have the compiler evaluate them at compile time where possible.
It's only "mathematical" if you chose very specific parts of the language from a very specific version of Pascal when looked at at a very specific angle.
E.g. the argument falls apart immedately:
- there's no assignment operator in maths
- there are no procedures in maths, everything is a function
- functions cannot be nested in maths (unless I'm mistaken)
- types is maths, but Pascal uses a very narrowed down and dumbed down version of it
etc. etc.
Pascal is the way Pascal is because Wirth wanted the simplest possible language according to Wirth's own criteria that could be compiled in a single pass on a 1980s computer.
It's the go [1] of its time.
That is it. Both the syntax and Pascal's concept are severely outdated. It's a very good thing that modern languages never adopted Pascal's syntax and went for something that is actually usable. Hell, Erlang is a more mathematical and timeless syntax than Pascal, and it's a trivial langauge at it's core.
[1] Can't find the actual text now, but there was a rationale by Rob Pike that go was amed at junior engineers, and needed to be simple.
There is no assignment but in math we use := to express that two things are equal per definition. I never said it was the same thing, just that it is the closest thing. From a math perspective it makes total sense, while singular = for assignment makes no sense at all. Especially when you want express the concept of equality as well and cannot use the obvious choice = anymore because you already used it for something else.
"- there are no procedures in maths, everything is a function"
Exactly and that's why functions and procedures in Pascal are separate things, like it is meant to be. Functions have an equivalent in math, procedures don't. Mixing the two concepts up into the weird thing C calls a function is just wrong.
"- functions cannot be nested in maths (unless I'm mistaken)"
In some sense they can. In C they can't because of technical restrictions, no one ever was fond of that restriction, not even back in the day.
"- types is maths, but Pascal uses a very narrowed down and dumbed down version of it"
Pascal is a programming language, not math.
My point is solely that Pascals syntax is superior to C's because (among other reasons) the former is closer
to centuries old tried and tested and well established syntax of mathematical notation. It has some consistency and elegance and certainly flaws as well. C's syntax decisions were more driven by long gone technical restrictions than what makes sense to a human. Now we have to live with that baggage.
Edit2: Most relevant part from second link: "The syntax has been devised so that Pascal texts can be scanned by the simplest techniques of syntactic analysis". That's it.
On to other comments which are basically relevant given Wirth's own words:
> but in math we use := to express that two things are equal per definition.
Then it isn't variable assignment. It's what you pretend it is because Pascal defined variable assignment this way, and now you're trying find an angle for which "Pascal is closer to math" works.
When we write "x = f(y)" or "x = y + z where z = f(t)" in maths there's no confusion as to what this expresses. No need for "equal by definition".
Note: Interestingly enough, Wikipedia doesn't list `:=` in its glossary of mathematical symbols [1] And then there's another sign used for definitions: equality sign with delta [2]
> Especially when you want express the concept of equality as well and cannot use the obvious choice = anymore because you already used it for something else.
Math also has the same problem, because equalities are not equal :)
Hence you have:
- equal
- equal by definition
- ~ has six different definitions depending on context
- ≡ has two different definitions
etc.
> Exactly and that's why functions and procedures in Pascal are separate things, like it is meant to be.
It's not "meant to be". Programming languages are not math. The distinction between functions and procedures in Pascal exists only because Wirth decided that's how it should be.
> In some sense they can.
It means that it makes no sense to pretend that nesting functions in Pascal has anything to do with math.
> Pascal is a programming language, not math.
Precisely. And yet, just two paragraphs above you argue for a distinction between functions and procedures because math ;)
> My point is solely that Pascals syntax is superior to C's because (among other reasons) the former is closer to centuries old tried and tested and well established syntax of mathematical notation.
Modern math notation didn't become "old tried and tested" until somethig like 19th century, and even now it still remains somewhat fluid. And it's only closer if you arbitrarily twist definitions and meanings like "equal by definition" is surely "variable assignment". As I said in the very first line of my original comment: "It's only 'mathematical' if you chose very specific parts of the language from a very specific version of Pascal when looked at at a very specific angle."
It's also "better than C" only for some vague defintion of "better" where "is closer to math" has no relation to either reality or to being better.
Yeah. weinzierl has his/her syntax preference, and that's fine. As the ancients said, "There's no disputing about tastes." But the attempt to provide a rationalization for why the taste is correct is complete nonsense.
It's not about taste, really. We all learn mathematical notation in primary school. It is an universal language. Programming languages support many concepts that are either the same in math or very similar.
Using the symbols for the same concepts in both worlds is the obvious and sensible choice.
The reason why C did choose a different convention was that it preferred similarity with FORTRAN which is so old that it was punched on cards that did simply not have a : character.
Now it is 2023 and I argue that we should use the same symbols in programming that children are taught in primary school instead of ones that were chosen merely because more than 70 years ago the proper characters were not yet available.
> Using the symbols for the same concepts in both worlds is the obvious and sensible choice.
Yeah, but has already been established in this conversation, you're not using them for the same concepts. So your argument doesn't work. Repeating it over and over isn't going to make it work, either.
> The reason why C did choose a different convention was that it preferred similarity with FORTRAN which is so old that it was punched on cards that did simply not have a : character.
I'd be interested in seeing your evidence for this assertion that you make so confidently. From my understanding, the logic was this: Assignment happens twice as often as comparison, so assignment gets the shorter symbol. Perfectly reasonable from an information-theory point of view.
And, C didn't avoid := because the proper character wasn't available. They used : in the ternary operator, so they clearly expected it to be available.
So all in all, your data is suspect, and doesn't support your argument.
"Yeah, but has already been established in this conversation, you're not using them for the same concepts. So your argument doesn't work. Repeating it over and over isn't going to make it work, either."
No, we've established that math and programming languages are different things. Both share some concepts that are close enough so that using the same symbol is the obvious and sensible choice. It's not that equality in C would be such a different idea that a completely unrelated symbol was chosen. == is still similar to the = used in math, just not the same for technical reasons that are obsolete for several decades.
"And, C didn't avoid := because the proper character wasn't available."
I never said that. I said C chose to reuse the symbols from FORTRAN. To repeat part of the Wirth quote from above (but it's easy to find other sources):
"It goes back to Fortran in 1957, and has blindly been copied by armies of language designers."
FORTRAN was initially made for the IBM 704, which had a 6-bit character set that included a =, but no : character. The original FORTRAN manual from 1956[1] has the character table in appendix A on page 49.
FORTRAN could not use := for what we would now consider assignment[2]. It did not have yet developed equality testing, just subtraction and branching on the differences signum result, so there was no need for an equality operator. Under these constraints = for assignment wasn't the worst choice, the mistake was sticking to it when technology evolved.
> I never said that. I said C chose to reuse the symbols from FORTRAN. To repeat part of the Wirth quote from above (but it's easy to find other sources):
> "It goes back to Fortran in 1957, and has blindly been copied by armies of language designers."
That's a pretty broad brush that Wirth is painting with. All those other language designers were blindly following FORTRAN; I'm the only one with the wisdom to break precedent. Yeah, um... that's way too broad a statement. Each language followed precedent and broke precedent in certain areas, and they all did so for what they thought were good reasons. "What people are used to" is one reason, but far from the only one. The "number of characters" reason was one I read from (IIRC) Brian Kernighan. I trust him to have a better grasp of the design logic of C than Wirth does.
Wirth doesn't mention math as inspiration because it is obvious.
Surely he derived the syntax from ALGOL, that is no secret, but it was his choice to do so and not invent something unconventional like Thompson and Ritchie did.
In addition to that I find it quite telling that ALGOL's designers were all mathematicians while Thompson and Richie were Electrical Engineer and Physicist respectively.
I don't know why you put equals by definition into quotes as if I had invented that and also why you falsely claim that it is not listed on the Wikipedia page you referenced. It is there with := as symbol in the section about equality.
If you need another reference:
":= (the equal by definition sign) means “is equal by definition to”. This is a common alternate
form of the symbol “=Def ”, which appears in the 1894 book Logica Matematica by the logician
Cesare Burali-Forti (1861–1931). Other common alternate forms of the symbol “=Def ” include def
“=” and “≡”, the latter being especially common in applied mathematics." [1]
Sure, there are alternative forms but := is what was taught in Germany and Switzerland in schools and university when I was there and I'm pretty sure also when Niklaus Wirth was there.
"A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957, and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x."
—Niklaus Wirth, Good Ideas, Through the Looking Glass
> - '=' is for equality only - assignment is ':=' which is the next best symbol you can find in math for that purpose
That is just syntax. I am not so sure if it is better or worse or not, but there it is.
Different programming languages do have different syntax, and sometimes that can be helpful if their structure is different. However, what I think is that the syntax for types in C is confusing (when you are making types combining by e.g. function of array of integer, or whatever).
> numeric data types are 'integer' and 'real', no single/double nonsense
It is helpful to be able to specify how many bits you want. (In the case of integers, range types (as you also mention) might help, though.)
> 'functions' are for returning values, 'procedures' for side effects
It is useful in C to be able to have side effects and return values, and to be able to ignore return values sometimes. (BASIC doesn't have and that sometimes annoys me)
> Function and procedure definitions can be nested. I can't tell you what shock it was for me to discover that's not a thing in C.
In GNU C you can do that, although a function that refers to stuff in the function it is inside of is only valid before the outer function returns. (And, you are not allowed to declare the inner function as "static" to allow it to work even after it returns in case it does not access stuff that is only valid before the outer function returns.)
> Array indexing is your choice. Start at 0? Start at 1? Start at 100? It's up to you.
That is good, and it is useful. Usually I think starting at zero makes sense, but sometimes there is sense to start at any integer, including positive and negative numbers, so it is good to be able to specify any number.
> Reminds me again of GNU Guile's arrays, which also allow you to specify what index an array starts with. Very flexible.
Reminds me of the "OPTION BASE" statement in BASIC. Found in Microsoft BASICs all the way from GW-BASIC (and probably even earlier than that) through to classic Visual Basic, VBA and VBScript (but not VB.NET). Not sure when it originated, possibly it goes all the way back to some version of the original Dartmouth BASIC (they changed the array base at some point from 1 to 0, so "OPTION BASE" enabled backward compatibility). Also found in some non-Microsoft BASICs, e.g. IBM System/34 BASIC. ANSI Full BASIC (did anyone ever implement it?) supported arbitrary array bases, not just 0 or 1, e.g. "DIM A(100 TO 200)"
Which is why Alsol was "a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.” — Tony Hoare.
- probably a lot more, I'm not too familiar with the language
The quote may have been closer to the truth at some point, but certainly not today. And while begin/end syntax may be a matter of taste I don't think it's coincidence it's not very common anymore.
Gave a glimpse at the code source screenshot. No, that syntax is very much the past.