4 ms·

The article closes with this thought: > While both languages are much easier to read than say, PHP or Java, [...blah blah blah...] Which leads me to wonder: H

by nimih 4y ago

The article closes with this thought: > While both languages are much easier to read than say, PHP or Java, [...blah blah blah...] Which leads me to wonder: Have there been any serious studies of the readability of programming language syntactic and semantic conventions? For instance, a good friend of mine (whose day job is working as a software consultant, and whom I imagine would disagree with the author's assertion) finds it extremely difficult to understand python code in particular due to his dyslexia, and I wonder how common such problems are, both as a % of people and % of programming languages.

remram 4y ago
PHP has a bunch of hacks that are here for technical reasons. Function names are inconsistent and terse because they were inherited from C, and there is the historical name-resolution quirk. The prefixed variable names don't bring anything and are not here for any good reason (compared to shell where "naked" identifiers are interpreted as strings). A lot of the object-oriented features had to settle for unusual tokens like backslashes. You might find that the PHP syntax is objectively problematic. For Java, Rust, etc it's a bit different. I would say that's up to taste. Using "public static" is very verbose but more obvious than @ or _ prefixes.
- nimih 4y ago
  I agree with your specific assessments here, but I was trying to get at the question of whether there are meaningful and measurable differences in the broad-scale accessibility of e.g. whitespace-centric syntax vs lispy syntax vs curly-brace syntax. Admittedly, it's hard to tease this apart from the standard library and communal conventions of any given language: Java occasionally devolving into an endless sequence of ProducerFactoryFactory.newProducerFactory().initializeProducerBuilder(new ProducerBuilder())... certainly impacts its readability in a practical sense, just as the Haskell community's perhaps ill-advised love of point-free programming and highest-order polymorphism doesn't always do it favors on the readability front. Those sort of details seem like they'd really complicate a rigorous and systematic study, but on the other hand, lacking a good methodology has never stopped _other_ supposed quantitative studies of programming languages as they relate to e.g. "developer productivity" and "defect rates," so who's to say...
- orf 4y ago
  What’s the historical name resolution quirk?

by nimih 4y ago

remram 4y ago

PHP has a bunch of hacks that are here for technical reasons. Function names are inconsistent and terse because they were inherited from C, and there is the historical name-resolution quirk. The prefixed variable names don't bring anything and are not here for any good reason (compared to shell where "naked" identifiers are interpreted as strings). A lot of the object-oriented features had to settle for unusual tokens like backslashes. You might find that the PHP syntax is objectively problematic. For Java, Rust, etc it's a bit different. I would say that's up to taste. Using "public static" is very verbose but more obvious than @ or _ prefixes.

nimih 4y ago
I agree with your specific assessments here, but I was trying to get at the question of whether there are meaningful and measurable differences in the broad-scale accessibility of e.g. whitespace-centric syntax vs lispy syntax vs curly-brace syntax. Admittedly, it's hard to tease this apart from the standard library and communal conventions of any given language: Java occasionally devolving into an endless sequence of ProducerFactoryFactory.newProducerFactory().initializeProducerBuilder(new ProducerBuilder())... certainly impacts its readability in a practical sense, just as the Haskell community's perhaps ill-advised love of point-free programming and highest-order polymorphism doesn't always do it favors on the readability front. Those sort of details seem like they'd really complicate a rigorous and systematic study, but on the other hand, lacking a good methodology has never stopped _other_ supposed quantitative studies of programming languages as they relate to e.g. "developer productivity" and "defect rates," so who's to say...
orf 4y ago
What’s the historical name resolution quirk?