3 ms·

The problem is that readability is largely a matter of naming conventions, organization, and adherence to known patterns. The language becomes more readable as

by setr 7y ago

The problem is that readability is largely a matter of naming conventions, organization, and adherence to known patterns. The language becomes more readable as you use it. Anything that isn't a C derivative is unreadable if you only know C. There are of course actual blockers to readability, like usage of similar-looking sigils and poor system library naming, but otherwise the syntax really doesn't tell you any useful information. It's the semantics that tell you how it'll all fall apart

vidarh 7y ago
I couldn't disagree more. Syntax changes whether I can look at a page of code and get an idea of structure and which elements to focus attention on, or whether I need to read everything in detail. It doesn't matter that much when I have found a piece of code that I need to read and understand every detail of, but that is a tiny proportion of the amount of code reading I do - most of the time reading code is about grasping overall structure to learn a codebase well enough to find the points you need to focus on and read. A clean syntax makes the difference between always having to read each token vs. being able to speed-read by pattern matching high level structure when you don't need the details of that specific piece of code. I've worked with dozens of languages, with wildly differing syntax, and I'll say that once you reach a certain base capability-level, syntax matters more to me than semantics. You can paper over a lot of semantic difference. I can (and have, and so have many others) build libraries to do object-oriented programming in C, for example, and I have implemented closures in C too [1]. So the reason I don't do much C any more is not semantics, but that there is no mechanism for plugging those semantic gaps that creates readable code. There are languages where the semantics paints you into a corner and makes plugging the holes too hard, so it's not that semantics doesn't matter at all. But it's usually easier to paper over semantic gaps than unreadable syntax. [1] http://hokstad.com/how-to-implement-closures http://hokstad.com/how-to-implement-closures

by setr 7y ago

vidarh 7y ago

I couldn't disagree more. Syntax changes whether I can look at a page of code and get an idea of structure and which elements to focus attention on, or whether I need to read everything in detail. It doesn't matter that much when I have found a piece of code that I need to read and understand every detail of, but that is a tiny proportion of the amount of code reading I do - most of the time reading code is about grasping overall structure to learn a codebase well enough to find the points you need to focus on and read. A clean syntax makes the difference between always having to read each token vs. being able to speed-read by pattern matching high level structure when you don't need the details of that specific piece of code. I've worked with dozens of languages, with wildly differing syntax, and I'll say that once you reach a certain base capability-level, syntax matters more to me than semantics. You can paper over a lot of semantic difference. I can (and have, and so have many others) build libraries to do object-oriented programming in C, for example, and I have implemented closures in C too [1]. So the reason I don't do much C any more is not semantics, but that there is no mechanism for plugging those semantic gaps that creates readable code. There are languages where the semantics paints you into a corner and makes plugging the holes too hard, so it's not that semantics doesn't matter at all. But it's usually easier to paper over semantic gaps than unreadable syntax. [1] http://hokstad.com/how-to-implement-closures http://hokstad.com/how-to-implement-closures