IMHO it's a matter of experience. When I was young I believed that programming is about writing a lot of code that "just work".

Now, after many private and commercial projects, I know that is about reading and understanding code. And about eliminating bugs. :)

Pascal is a safer language overall, which I would argue is a good thing. C eskewed many safety features for slightly (but not significantly) more power.

Having written TSR's in Pascal and C I have to disagree. C had significantly more power and was a lot simpler to get working for lower level stuff.

Only if you are comparing to standard Pascal.

Turbo Pascal had all the capabilities of C as well. I can produce a one to one table, if you wish.

Additionally after version 5.5, it also had support for OO.

I never understood the complaints about verbosity in Pascal languages and the escape to C, Perl and friends.

Why not use APL then?

Programs are to be read, not to be write-only.

Pascal verbosity does not add information, but noise. As humans, we recognize symbols and structures better than words. {} as delimiters make much more sense than BEGIN/END.

I always thought there was a use for something like RATFOR for Pascal; maybe Ratscal? It could have left most of the verbosity in place, but replaced the BEGINs and ENDs with { and }, and that would have made it an almost perfect language from my point of view.

Nimrod is a lot like a modernized Pascal with a Python-like syntax.

BEGIN BEGIN BEGIN BEGIN BEGIN END END END END END

That's MUUUUCH better!

More readable.

Now we can discuss tab vs spaces.

It's not that readable if you didn't realize I actually fixed your extra }. I expected you to nitpick about it! :P

PS: spaces obviously.

> It's not that readable if you didn't realize I actually fixed your extra }. I expected you to nitpick about it! :P

Yes, I did it on purpose.

> PS: spaces obviously.

Well there we happen to agree. :)

Verbose programs are hard to read.

"begin" isn't harder to read than "{", with each on its own line (arguably a very readable bracing/indentation style).

Later Pascal/Delphi compilers had very useful syntax highlighting built in, so this is really not an issue - unless you prefer as much code as possible crammed onto a single "page" (IMO not really helpful for reading).

{} are also somewhat harder (more strenuous) to type than begin/end, especially on german keyboards (it's Alt Gr + 7 / Alt Gr + 0) and even more so on german Apple keyboards ({} are not even printed on any keys there and they are on different key combinations than on PC keyboards).

Maybe to comic book readers

> comic book readers

You say that like reading comic books is an anti-intellectual crime.

Getting to the point, look at these examples and tell me which one is better from the readability perspective.

> for(std::vector<std::shared_ptr<MyClass> >::const_iterator it = v.begin(); it != v.end(); ++it)

or

> for(const auto &value : v)

Even in the case when the "value" variable's inferred type isn't apparent from the context, we can use

> for(const std::shared_ptr<MyClass> &value : v)

which is still much more readable than the monstrosity in the first example.

To make your comparison more useful (and on-topic), you should compare this to a Pascal or an Ada program. You won't find such a syntax massacre there. In fact some verbosity is a design feature that actually helps programers maintaining large, long-living sytems.

> In fact some verbosity is a design feature that actually helps programers maintaining large, long-living sytems.

I completely agree with that. For example, static typing adds verbosity, but it also documents the program and makes figuring out a large codebase a lot easier. The "noise" can even be reduced in languages with type inference like D, Haskell or C++11.

The thing is, unnecessary verbosity only crowds the code and doesn't add any value. Most of the keywords in "if ... then begin ... end else begin ... end" serve no real purpose and could be replaced with a symbol, like a curly brace.

I have pretty much the exact opposite view: I find type signatures add noise I don't want, while I find {} to be suboptimal for large blocks. I prefer the Ruby approach, where what you described would usually be:

    if
       ...
    else
       ...
    end

So it cuts down on the clutter vs. Pascal, but sticks to words rather than single character symbols

What you call "noise" is the compiler catching a type-mismatch bug before it goes out into production.

Type errors are typically trivially caught with units tests that are necessary to verify functionality anyway.

I used to be a strong believer in static typing and insist that dynamic typing would be extremely error prone, but when I actually tried it, I found that the additional testing required is pretty much non-existent - if you test properly, you tend to cover types as a side effect.

I'd still prefer static typing, but only if it doesn't get in the way. And that means minimal annotations, and minimal restrictions.

Working in the enterprise, with off-shored project modules, will restore your faith in static typing. :)