[foldr]

These were real limitations of several real Pascal compilers back in the day. As a child, I remember them being explained in a book introducing Pascal to Basic programmers. C has never required compiler-specific language extensions to make arrays and strings practically usable (however error prone they may be).

You also have to think of the effect of this on pedagogy in the pre-Google era. Any book on C would teach you how to handle arrays and strings of arbitrary lengths. Meanwhile, a book introducing Pascal would have to either restrict itself to the ISO standard's hobbled implementation of strings and arrays, or direct the student to cross their fingers and look at their compiler's documentation. That's a significant barrier.

[pjmlp]

C required tons of extensions to be usable outside big iron UNIX where it was born.

I never saw a pure ISO Pascal compiler outside UNIX, and the only Pascal book I have, from several, that constrains itself to ISO Pascal is Niklaus Wirth book.

Additionally, Pascal naysayers keep forgeting that exactly because of ISO Pascal inadequacies as systems language, Modula-2 was born in 1978.

Quite a long time to keep comparing K&R C (with extensions) with ISO Pascal.

Specially given how many systems Apple shipped with Object Pascal in the box, or the sucess of Apollo Computers on its time.

[foldr]

C didn’t require extensions to write a function that takes as its parameters an array of integers and the length of the array. Looking into this again (after ~30 years!) I see that ISO Pascal did have an optional 'conformant arrays' feature that could handle this kind of basic case, but it was far less flexible (albeit safer) than C's array handling, and wasn't implemented by all compilers.

I’m not sure where you are seeing 'Pascal naysayers'. I’m just pointing out an issue with the language that may have affected adoption. Neither Pascal nor C really got arrays 'right', but C never got in your way.

[pjmlp]

Pascal naysayers are those stuck in Pascal 1.0 for anything related to C vs Pascal.

That optional extension became part of the ISO Extended Pascal revision, for example.

To make it clear should we compare Go's ability to write generic code versus other languages, using 1.21 or 1.0 version?

[jstimpfle]

I believe those versions of Pascal that required you to also define PFoo for every type Foo you define are not so long ago (e.g. to receive a pointer to a type as a function parameter, you had to declare the type "pointer to foo" first and give it a name, and use that in the function signature). I don't follow Pascal, but it may still be required in some cases in modern versions of the language.

There is also the problem of not being able to define local variables (e.g. to hold the result of intermediate computations) right there and then. Even in Delphi until very recently, you have / had to declare each single local variable above the function body, below the function signature, _before assignment_. That is worse than C89 declaration style like used in Linux until recently (may be ongoing. I've dealt enough with that code to say that it's often a pain to have a lot of variables around that don't hold valid values.

So we already have two significant defects that produce friction in basic use. It feels like Duplo, not Lego, because important basic usecases require so much verbosity that it becomes cumbersomse to read and write. And I assume that is a big reason why the language has seen less adoption / has even lost adoption where it had already gotten some.

Some aspects of the Borland compilers (like performance) are genuinely nice though. And that it is in no small part due to the language structure enabling them.

[_ph_]

Sorry, but those "defects" are perhaps a minor inconvenience as they require a bit more of typing, but don't prevent you to write code. While I agree that one would prefer to have less inconveniences - and part of the design of Go tries to eleminate especially those - I strongly prefer them for the overall better safety of Pascal and its sucessors to the C language family. Unfortunately, too many programmers saw this like you and we ended up at todays mess.