facepalm Except Ruby, OCaml, Erlang, Lua, etc.
Frankly, if verbosity is a significant limiting factor on your creativity, a) C is not the solution to your problem, and b) you weren't trying to solve any hard problems anyway.
Seriously, if you're doing anything really hard, stuff like thread management and algorithmic complexity is a way bigger limiting factor than minor syntactic differences.
Makes me wonder how I ever wrote anything on a 80x24 serial terminal in the 1980s....
Yes, syntax limits everything, and being able to fit 10% more on the screen is a lot like being 10% smarter. But libraries, available techniques, and built-in features limit everything a lot more. Being able to do 500% more with the same amount of code is a lot like being 500% smarter. If you're piddling around with 10% increases like a switch from Pascal to C, you're wasting everyone's time. Switch to a higher-level language that's more closely suited to the problem you're trying to solve and you'll trivially be writing a fifth of the code you'd be writing in C[1]. So like I said: C is not the solution to your problem.
And that's being generous to your assumption that Pascal -> C actually even does give you a 10% boost: I think given that you'll be writing the same bounds-checking incantation everywhere in C which you wouldn't be writing in Pascal, the semantics probably negate the syntax very easily.
[1] There's one exception: where C is the language most closely suited to your problem. However, this exception is much more rare than most people think.
I would argue that hard things require clarity, and syntax can often reduce clarity.
If a problem requires that you keep all of it in your head then being able to express that problem concisely will aid in solving it.
The poor mans solution is to reduce the scope: chop the problem into sub-problems that you can solve individually.
Divide and conquer is the most powerful tool in a programmers arsenal because it allows you to use the worst languages to solve some of the most complicated problems.
But there may be a subset of problems where that strategy no longer works and for those problems the more compact languages may have a very strong advantage.
Any thing where, for the implementation you can come up with, those extra lines are the difference between fitting a function on a single screen or not. There's a huge difference in readability between a function or class that can fit on a single screen and one that can't.
Compare and contrast to APL and Lisp, which are obviously different, and Python, which avoids the problem by having a fairly different syntax and a guide for exactly how to do things.
I've seen some pretty amazing things in APL, but I can't really understand them. I don't count that against the language, I just haven't spent the time to actually learn APL.
As for there being an optimum, I think there is, but I think it has a lot to do with how long and for how complex of things you plan to use the language. Front-loading learning time for a more expressive language may pay dividends later.
By the time the equals sign was invented, it was commonplace to use the abbreviation "aeq." for equality, for "all equivalent (or equal) to".
But the equals sign turned out to be a really important development in mathematics, because it helped to visually distill mathematics down into just their number and equation components, without the visual noise of written words.
So I wouldn't be too quick to discount the value of good syntax. I've never personally cared much about it in the past, but looking at it from the point of view of the equals sign, it's probably fair to guess that syntax does a lot more for code clarity and readability than we think.
a ∧ (a → ¬b) → ¬b
is easier to reason with than
Socrates is a man, no man is immortal, therefore Socrate is not immortal.
