Syntax Matters

It is claimed herein that the syntax of a programming language matters a great deal; for several reasons. (Here, syntax refers to all textual elements of the language, including both lexemes and grammar; no distinction is made between the "lex stuff" and the "yacc stuff".)


What about languages that are effectively "SyntaxFree?"?

Forth comes to mind: arg parsing in any conventional sense simply doesn't occur. Arguments are typically left on the ParameterStack?, as are results.

Although there is a convention for argument passing, there is no grammar to speak of beyond that imposed by the developer.

I'd say it proves the point. It's effectively impossible for anyone but the most forthified hacker to read Forth (or Postscript or any other StackBasedLanguage) without "playing computer" to try to figure out what the program does.

There is no such thing as a 'SyntaxFree?' language. Even Forth must parse words from whitespace and commands from definitions.


This point comes up several times in PythonVsRuby and other LanguagePissingMatches.


Proof that syntax matters: the cumulative number of extra seconds wasted by all programmers of all C-like languages typing the C "for" syntax (when 99.99999999% of all "for" loops count from A to B by 1 and therefore don't need such a generalized syntax) probably adds up to thousands of years.

You mean you never created a macro for that?

Is the ability to create a macro supposed to be an excuse for not putting it into the language?

Certainly! There are a lot of folks who like minimalist feature sets in their languages; and view adding features that can be trivially implemented on top of other features (i.e. non-orthogonal features) to be clutter. That said, the C++ while loop is trivially implemented as a for loop yet has its own syntax. OTOH, the do/while loop is not trivially implemented as a for loop.

If this were C's only "flaw", the world would be a better place. At any rate, "for (foo=0; foo < limit; foo++)" is so common among the CeeIdioms that claims of "thousands of years of lost productivity" stink to high heaven. Other than rank beginners, C programmers don't have any problem with this.

Untrue... if you have to type it at all... even if no mistakes are made, it's costing you time. Typing for(0,limit) is easier and faster than typing for (foo=0; foo < limit; foo++), no matter how much you know about C. [And the number of C, Java, JavaScript, etc. programs ever written is an astronomical multiplier]

Of course, C is terse compared to many languages, so probably it all comes out in the wash. :) Number of keystrokes needed to implement a particular function in the language strikes me as a dubious metric. To repeat the above--C has far more serious issues than this; being indignant over the for loop strikes me as nit-picking. Probably many more programmer-hours have been lost to memory leaks, WildPointers, and other strange and wondrous behavior made possible by C's low-level programming model, then by C's lack of a proper for-next loop. (Or better yet, a foreach loop)

Your reasoning strikes me as odd: "You shouldn't mention this particular bit of overly-baroque syntax because there are worse things in C." Anyway, for one thing I was talking about all languages with that syntax, and for another I thought it made a particularly clear example of "human factors" in language syntax. I guess YMMV.

    for(int run = 0; run < runs; runs++) do_some_stuff();

Raise a hand if you spotted the bug immediately... Coming from Ruby back to C# is a most painful experience.
    for i in runs..runs   
       puts "Value of local variable is #{i}"
    end
The output might not be what you were after either.
The trick is to pay attention to what you type. I'd say the syntax matters argument comes down to consistency. 99% of functions are called the same way in c and java.. method(). Oh the brace :) Can a user create an object by accident? Python/Ruby Yep. For a dyslexic/canadian colour is a constant issue for me.. color = Color.Red; I'd also say if(TEXT = test = tEst = tEST) is a bit a personal issue. IMHO, case matters. As a delphi dig.. adding an else should not mean my if is now bad code.
    if(test) then diaplay("test is true"); 
    else display("test is false");
    if(test) then diaplay("test is true"); 
    //else display("test is false");


See also: LispLacksVisualCues
CategorySyntax

EditText of this page (last edited November 13, 2011) or FindPage with title or text search