The fact that I prefer to stick to basic syntax and data types (e.g., no OOP, tuples, pattern matching) doesn’t mean that this basic syntax suits me. And it doesn’t suit me, for example, when it comes to unions, bit fields, arrays, etc.—these are basic data types whose syntax is overly complicated.
Regarding unions (variant records) and bit fields, I agree. Pascal has limitations in this regard. A solution to this issue would be useful. Although not necessarily by copying C syntax verbatim. I believe 440bx's comments on this matter are entirely valid and should be taken into account.
Besides, how can you recognize archaic or (its opposite) modern syntax? Because it is different from other languages?
Mainly because it hasn't changed in decades, it's clunky and deviates from the norm. If a particular syntax can be improved, it should be improved, and I'm glad that work is underway on these aspects (at least some of them).
You must be joking. The syntax of C and C++ has also remained unchanged for decades. Is it also clunky and deviates from the norm? If that's your opinion, I completely agree with you. And should the syntax of these languages be improved? If that's what you think, then I agree on that point too. Unfortunately, no one intends to correct it. On the contrary, C and C++ enthusiasts insist it's great (which is a lie).
Furthermore, what does it mean that Pascal's syntax deviates from the norm? So, from what? What constitutes a programming language norm? There is no standardization document that describes what the syntax of programming languages should look like. Because it would mean that such a document is a description of one specific language! Such a hypothesis (i.e., this "deviation from the norm") cannot be proven mathematically or experimentally (as in physics). This is purely a subjective feeling. The only thing that can be proven is whether, for a given group of people, a given syntax is:
- easier to learn,
- clearer to use,
- more or less error-prone.
And there can be many such groups. And there are many, as evidenced by the number of programming languages in use.
When declaring arrays, you specify a number in square brackets, and when specifying the element index, you also specify a number in square brackets. This is error-prone.
Why exactly would that be error-prone? An array declaration is a separate and unambiguous context, so it’s impossible to confuse specifying the number of array elements with accessing a specific element. It is not without reason that other languages have a syntax completely different from Pascal’s, because it is simpler, shorter, and still unambiguous.
When I declare an array, I do so for a specific number of elements, and I almost always use zero-based indexing. And since the indexing is the same in 99.9% cases, requiring the index range to be specified in 99.9% of declared arrays is a waste of time and unnecessarily lengthens the code.
Other languages, meaning which ones? Because there are many syntaxes for declaring arrays. Not just the "one right C" one that you apparently like - which is fine, because everyone has the right to prefer a certain syntax. The fact that some languages have C-like array declaration syntax in the past stemmed from a desire to attract people to the new language (C++, Java, C#, etc.), not from any advantages of that syntax. Furthermore, what does it mean that the syntax is unambiguous? That the C syntax is unambiguous and the Pascal syntax isn't? How can this be proven? This is purely subjective. Pascal's array syntax is unambiguous. And the fact that an array declaration doesn't use the number of elements, but the index range is an advantage. And in C you can't. An arbitrary index range allows for greater coding flexibility for certain algorithms when using arrays. I've used it many times and continue to use it. So, for me, declaring an index range isn't a waste of time! And there are many more such people.
Secondly, the idea of "tinkering" with the counter of a "for" loop within that loop is absurd. These two ideas should not be implemented under any circumstances, as they will cause various problems in the future.
It is absurd to prohibit the use of the alter iterator in for loops and force users to use other loops. Not only does this fail to prevent incorrect implementations (since exactly the same problems exist with while or repeat loops), but it also forces a longer implementation and annoys the user by treating them like an underdeveloped child.
Are you suggesting replacing the current Pascal "for" loop syntax with the C syntax? The Pascal version has automatic loop counter changing, while the C one is essentially quarter-automatic. This is a radically different approach to the for loop. I don't think it's a good idea to implement C language quirks into Pascal. I understand that someone prefers a different syntax. Fine. But then you could simply use the other language, since it has so many advantages. This is a simpler and more reliable solution.
As for "longer syntax"—how much longer? A few characters? If it provides additional information for the compiler or the person reading the code, then that is an advantage.
A programming language is a tool that is meant to serve the user. Programming isn’t kindergarten—either you know how to program or you don’t, and if you don’t, the language’s features don’t matter, because you won’t be able to use them correctly anyway, regardless of what’s allowed and what isn’t. If you can't implement the algorithm using a for with altering its iterator, you won't be able to implement it using a while loop either.
Yes, I agree with the statement that "A programming language is a tool meant to serve the user." But to be truly useful, it can't be confusing, cumbersome, or have any quirks.
The statement, "Programming isn't kindergarten—either you can program or you can't..." is pure nonsense and demonstrates a lack of substantive arguments. Guido von Rossum was once criticized for the lack of encapsulation in Python's "classes." The response was, "But why would you want to hide that? We're all adults." Another objection concerned the lack of constants. The response was, "Just don't change it." This demonstrates that this man had insufficient programming experience (he's probably learned a thing or two since then). He did not understand that in the case of complex software, some solutions that seem strange, cumbersome, and redundant are not so at all. They simply allow you to offload some of the work involved in checking for errors in the code to the software. But software isn't a miracle worker or a wizard; there's no magic bullet, so the programmer must include certain information in the code. The less ambiguity there is in the code, the less likely it is to make errors. The following statement: "Programming is not kindergarten - either you can program or you can't..." may indicate: (1) too little programming experience, or (2) a sloppy and reckless approach to programming (excessive convenience at the expense of code quality).
This idea is redundant, error-prone, and difficult to read compared to the current one.
Absolutely not, and that is precisely why most modern programming languages use exactly this syntax, whereas the one found in Pascal is redundant and rarely found anywhere. In contrast, the Pascal syntax is error-prone because it requires specifying the upper index, which makes it much easier to make a mistake by forgetting the -1 for 0-based indexing.
But which languages? All of them? This is definitely not the case. As I mentioned earlier, some of them simply copied the syntax from C, but not necessarily because of its usefulness.
As for the redundancy of Pascal syntax for array indexing – how can this be proven? Again, this is just a subjective opinion. Moreover, in C you can also forget about correcting indexes. It depends on the algorithm and what the code is processing.
A typical C-ism.
No, it's just a simplification of what is redundant. In contrary, yours is a typical case of C-phobia (or even modern-phobia as such syntax is commonly used in nearly all modern programming languages).
The “ad persom” argument is nonsensical. Neither of us knows the other. We never met, and we likely never will. I suggest focusing on evaluating the solutions and opinions presented.
My critical opinion of the C language stems from its shortcomings and flaws. This is understandable, as people have different assessments of the suitability of tools for their work. Secondly, C syntax is not some "divine standard." It is just one of many. It has its flaws, which stem from the decisions of people working with computers in the early 1970s. They made certain design decisions without thinking about the future. Today, these decisions are romanticized as the "extraordinary insight and wisdom" of the designers of C (and C++) at the time. But this is an illusion (cognitive error) resulting from temporal distance.
How can we tell if C syntax is widely used in almost all modern programming languages? Is there a reliable and authoritative comparison published somewhere? So, definitely not all imperative languages. What about functional languages? What about declarative languages? I've already explained why some imperative languages have a syntax similar to C. Another factor could be that their designers only knew C or C++.
Another terrible idea. Especially the one with two or three variables in the loop header. If someone thinks they need this language construct, they should probably rethink their code, because something is flawed.
What are you talking about? You write as if you've never written a loop in your life where the iterator needs to be modified dynamically and on which the final number of iterations depends. Of course such algorithms exist (and I even gave an example of one I recently implemented), and of course it would be easier and simpler to implement it using a for loop rather than a while loop.
And the funniest part is that you can easily implement loops in C or C++ this way, dynamically modifying not only the for loop iterator but also its termination condition. This gives you full control over how the loop behaves and reduces the amount of code you need to write, and this is exactly what my proposal is about. But C/C++ is a tool that supports the programmer, while Pascal is an overprotective mom, unjustifiably forbidding her child from doing this and that so the poor thing doesn’t hurt itself. 
If C or C++ are more useful to you, why don't you just use them? It's easier because they already exist. And it's a completely rational approach.
Why port C or C++ syntax to Pascal? To create another oddity like C#, only much more niche? What's the point? Unless it's about divisions among Pascal users. Oh, that makes perfect sense
But not for Pascal programmers
As for the statement: "Pascal is an overprotective mom, unjustifiably forbidding her child from doing this and that so the poor thing doesn’t hurt itself." - such a meaningless platitude could have been written by some fanatic teenager who is just learning to program. Roughly speaking, people who create software can be divided into two groups:
- those who want to use various bizarre tricks or excessively shortened syntax (e.g., to impress others with their apparent wisdom),
- those who want to create robust software so that in the future they won't have to constantly patch it due to bugs and vulnerabilities.
Both of these approaches use different syntaxes in programming languages. There are more people in the first group. This applies not only to programmers. In every technical industry there are those who want to take shortcuts, or rather believe that it can be done. Those who want robustness are, unfortunately, fewer. And on top of that, greedy company managements who do not understand technical issues and put pressure on programmers. And this approach is transferring to the open source world.
Recent
