Then why did this confuse you? And why on earth would you want to weaken Pascal's rules which happen to be its strengths? There is no reason why a developer shouldn't know the language they are using. Pascal is a well-established language. Most of the reason I've always used Pascal is because of it's strict adherance to certain rules and philosophies, and it's Wirthian nature. Pascal is the philosophy, not the syntax.

IMO, there are things that are pertinent to the core of the philosphy, and there are other things.

Let's begin with Wirth and 'Wirthian nature'...

Well, I respect him a lot, but that does not mean I have to worship him. And, I daresay that applies to a lot of Pascal lovers...

Let's now briefly touch the statement that 'Pascal is a well-established language'...

The Pascal I used first did not know a thing about objects, dynamic arrays; operator overloading, nor did it know how to treat strings, among a number of other things..

And, on the topic of 'adherance to certain rules and philosophies'..

Luckily, people then were not so adamanat about --so called--- Wirthian nature of Pascal... including Wirth himself; just look at the things Wirth altered in Modula/Oberon series.

So... Not only the 'strict adherance to certain rules' thing is not cast in stone, but also --it seems-- can change from one version of the same compiler to the other...

Finally, about 'Pascal is the philosophy, not the syntax'..

As far as I gather, the only philosophy behind Pascal was to remove ambiguity in written code. And, that's it.

If there is no ambiguity, why worry about whether it conforms to some mystical/celestial strictness..

|
| IMO, there are things that are pertinent to the core of the | philosphy, and there are other things.
|
| Let's begin with Wirth and 'Wirthian nature'...
|
| Well, I respect him a lot, but that does not mean I have to | worship him. And, I daresay that applies to a lot of Pascal | lovers...
|
| Let's now briefly touch the statement that 'Pascal is a | well-established language'...
|
| The Pascal I used first did not know a thing about objects, | dynamic arrays; operator overloading, nor did it know how to | treat strings, among a number of other things..
|
| And, on the topic of 'adherance to certain rules and philosophies'.. |
| Luckily, people then were not so adamanat about --so called--- | Wirthian nature of Pascal... including Wirth himself; just look | at the things Wirth altered in Modula/Oberon series. |
| So... Not only the 'strict adherance to certain rules' thing | is not cast in stone, but also --it seems-- can change from | one version of the same compiler to the other... |
| Finally, about 'Pascal is the philosophy, not the syntax'.. |
| As far as I gather, the only philosophy behind Pascal was | to remove ambiguity in written code. And, that's it. |
| If there is no ambiguity, why worry about whether it | conforms to some mystical/celestial strictness..

I agree that basic idea is that if you -aim- for some strictness and structure, you are least have those strong aims and goals. No one would be able to read English if we all had sets of our own dictionaries without any rules. You have to have some strong aims or goals... but there is nothing wrong with modifying things to make them better. Adding words to the dictionary is not a sin if we need them.. but half the people in the world cannot be calling cats catolas, and the other half calling cats catties.

Sometimes, things need to be significantly modified. (i.e. when classes and objects were introduced obviously this was an improvement), but new rules should come along with this new improvement. There is room for improvisation.

I particularly like how Pascal happens to be more "blockish" and "vertical" on the screen. It reads like paragraphs do, instead of sticks and stones all over the place. It's not just the syntax or the rules, it's also the way it reads on the screen, and the words people use to describe things. If it's a procedure, I want to know that it's a procedure.. I don't want it to be a proc.. because that could be a process, or a proclaim. But there are times for short-forms, i.e. regexes. But when programming the majority of the time (string processing with regexes is not the majority of the time) I want to know for sure what I am doing.. is this a procedure, or is this a process, or a proclaim, or a procrastination? Is *&^ a procedure, or a swear word? Is this a function or a procedure? I don't want to be fooled with void or "nil resulting function", I just want to know that it's a procedure. It's not that much effort to just type procedure out, so why call it a "nil resulting function" or a "function that doesn't return something".

Mark Emerson wrote:

[...]

Mark, I'd like thank you for this not because it falls inline with what I believe, but for something completely different too.

And, here is what I think it is:

Although quite young compared to Wirth (or me :-) ), Florian is [ see http://www.freepascal.org/aboutus.html for Florian Klämpfl] an important figure in the Free Pascal world. [See http://en.wikipedia.org/wiki/Free_Pascal ]

And, since FPC is on the verge of being hugely more successful, he too will be placed on a pedestal be worshipped whether Florian wants it or not --just like Wirth and other well-meaning, practical-problem-solvers cum prophets are.

I would not want him to say yes to everything, especially if they would undermine important foundations of Pascal, but, at the same time, he should be most careful when saying no too; for [the fear of/that] he will be intepreted in ways he would never have imagined so much so that might hinder the improvement of [Free] Pascal in years to come.

Cheers,
Ray