[lmm]

Syntax limits everything, it only becomes more important as you're doing hard things. Being able to fit 10% more code on screen is a lot like being 10% smarter, which is the kind of thing you need to make the hard problems even possible.

[arethuza]

"Being able to fit 10% more code on screen is a lot like being 10% smarter"

Makes me wonder how I ever wrote anything on a 80x24 serial terminal in the 1980s....

[spacecowboy_lon]

i used to switch our Vt100's to 132 line mode

[copsarebastards]

> Syntax limits everything, it only becomes more important as you're doing hard things. Being able to fit 10% more code on screen is a lot like being 10% smarter, which is the kind of thing you need to make the hard problems even possible.

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.

[mathgladiator]

What is a hard thing that requires better syntax?

I would argue that hard things require clarity, and syntax can often reduce clarity.

[jacquesm]

I think this is all somewhat related to how much you can keep in your head at once. More code -> less expression -> less that you can keep in your head -> you can solve smaller problems.

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.

[sacado2]

It's a double-edged sword, though : your compact, clever solution is great when your write it but becomes unreadable when you (or worse, someone else) tries to maintain it. And then you have to understand both the hard problem and the way it was solved in the first time.

[lmm]

The main way to make code genuinely shorter is to actually make it simpler; replacing logic with a higher-order function call (e.g. map rather than a loop) makes it more readable and maintainable, not less. Or if we're talking about meaningless syntactic clutter like the extra lines of begin/end, they don't make the code any clearer.

[lmm]

> What is a hard thing that requires better syntax?

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.

[mojuba]

To be fair Pascal is more "wider" than longer compared to C, but still it takes more time to read.

[jacquesm]

By that reasoning APL should rule, so there may be some kind of optimum.

[kbenson]

t may just be that the learning curve for APL is so steep and so long to become truly proficient that most don't get there. I've long held the opinion that much of the criticism of Perl as "line noise" is more to do with people that aren't really proficient in it thinking they are because a subset of the language is very C-like and familiar, and it can be used for quite a while before encountering anything too foreign to someone that knows C. Once that happens though, it leaves those people scratching their heads wondering what they are seeing.

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.

[musername]

With regards to complexity theory, I'm inclined to assume that syntax is a constant factor in the equation. You only have to extend the language by writing a macroprocessor once, if you count that to the power of the language. That's why C is still very powerful, although other langs have half an STD-Lib toolbox hidden in syntactic sugar.