12 ms·
I'm not a huge fan of flexible syntaxes, which might be just a bunch of language engineers revolting against periods, semicolons and parentheses. I happen to li
by martingordon 17y ago
I'm not a huge fan of flexible syntaxes, which might be just a bunch of language engineers revolting against periods, semicolons and parentheses. I happen to like my code to be easily readable and I'm willing to give up the time lost in typing a few extra keystrokes for that benefit.
- jeremymcanally 17y agoI think you're doing something wrong if you need glyphs and punctuation for your code to be readable. I get dots and all that, but semicolons and friends are just noise.
- martingordon 17y agoA flexible syntax introduces ambiguity, which forces me to think even more. Consider this simple example (which may be wrong for all I know): x = foo bar, baz Is it x = foo(bar, baz), x = {foo(bar), baz} or something else? I could probably derive the true meaning by looking at surrounding code, but I shouldn't have to.
- jeremymcanally 17y agoWell, sure. You can write code like that, but that doesn't mean you should. I'm not arguing for so-called "poetic mode" code (I hate it actually), but I think languages like Ruby and Python strike a really solid balance between lack of line noise and clarity if you follow what one might call normal coding conventions established by the community. Of course, these aren't canonized for the most part, so it's hard to know exactly what they mean, but I think everyone can agree that "x = foo bar, baz" should be clarified to "x = foo(bar, baz)," if nothing else because it will eliminate any parser confusion if you add a predicate conditional or something like that. Anyhow, my point is that I can write C or Java or whatever else that's just as unreadable due to its lack of clarity, but that doesn't mean I will. It's a skill issue more than a language issue. ;)