4 ms·

> tradeoff between readability and compactness What do you mean by "readability" exactly? Can you provide some kind of definition for what "readability" is? Ca

> tradeoff between readability and compactness What do you mean by "readability" exactly? Can you provide some kind of definition for what "readability" is? Can you point me in a direction of any research on "readability" (in programming) and it's impact on programmers' productivity? Sorry for the OT, but this is a pet peeve of mine: we have no way of defining, let alone measuring "readability" in any meaningful way, yet people, including even experienced programmers like you, talk about "readability" as if they knew what it is, how it looks like and as if it was some universal feature of physical world like force or speed.

JackC 12y ago
> Can you provide some kind of definition for what "readability" is? Sure. In this particular case, your parent considers an algorithm "readable" if it can be readily understood by someone who is not familiar with the particular language being used, and is not experienced with Lisp-style languages, but is experienced with ALGOL-style languages. That's not a universal definition, but at this moment in this path-dependent world it's a reasonable thing to consider.
- baddox 12y ago
  I think in most cases a working programmer should be able to write code under the assumption that it will be read and maintained by people who are familiar with the programming language being used.
  - klibertp 12y ago
    I think you missed GP point, which I believe was that "you can write Fortran in any language". Or more precisely that you can know a language very well, but that won't help you much if you are confronted with unfamiliar idioms and patterns you don't know.
- klibertp 12y ago
  > who is not familiar with the particular language being used > but is experienced with ALGOL-style languages That's NOT readability, that's merely familiarity. It doesn't help anyone to confuse the two.
zwieback 12y ago
No, I don't know of any research although it may exist. My personal definition of readability is very simple: the time it takes to understand a particular piece of code. I think there's a balance between overly dense code and code that requires me to scroll through several pages or jump between files. It takes me longer to parse dense Ruby or Python code because I'm not very familiar with the languages but I'm aware that those languages give us ways to write more expressive code with less syntax overhead. The trick is to write compact code that is still easy to understand for someone other than the author.
- klibertp 12y ago
  > don't know of any research although it may exist I couldn't really find any, but I'd be very happy to learn that it exists. We'd be much better off as an industry if it existed. > the time it takes to understand a particular piece of code Can you see a problem with this definition? Do you think that any given piece of code has time_needed_to_understand property, which is at least similar - or at least in the same order of magnitude! - for all the people who could read it? Exactly the same few lines of code can take one person half a day to understand while some other person will know their meaning in less than 10 seconds. It's much worse than that, actually. You can show the same piece of code to several people, and you're almost guaranteed to hear complaints about both "too terse" and "too verbose"; both "too explicit" and "too implicit"; both "too noisy" and "without enough syntax sugar". And this happens even if we're talking about people who mainly program in the same language - adding other languages makes this far, far worse. You get holy wars on the grounds of readability and syntax, you get people who just won't ever touch X, because it's so much uglier (and less readable) than Y and so on. It's insane. Personally, I try to write "readable" code in every language I happen to use. I actually read a couple of books on the subject and looked through many pieces of code/projects which are widely considered "readable". That doesn't matter, because every now and then I still hear that the code I wrote is "too terse"/"too much syntax"/"too little syntax"/"too verbose" - the same code, just in the eyes of different people. Back to the article, so that it's not entirely off-topic, I find this: http_retry = retry(DOWNLOAD_TRIES, HttpError) harder_download = http_retry(download_image) images = map(harder_download, urls) very "readable" (by your definition of "readability"), as it takes me less than a second to comprehend what is it about. Conversely, this: images = [] for url in urls: for attempt in range(DOWNLOAD_TRIES): try: images.append(download_image(url)) break except HttpError: if attempt + 1 == DOWNLOAD_TRIES: raise I find much less readable, because I need to track a lot of irrelevant data to understand what it is about. On the other hand, if my task was to understand why the code retries one time less than it should (for example), then the latter code is much more readable, because I don't need to navigate to some other file to see a definition of retry (which takes time) and I just see the potential off-by-one error in front of my eyes. Anyway, "readability" is really a hard problems for the whole industry, I just wish people would admit that much and started to do some serious research on the topic instead of thinking it's obvious. Edit: I'd also like to know what people who downvoted my first post here think.

JackC 12y ago

> Can you provide some kind of definition for what "readability" is? Sure. In this particular case, your parent considers an algorithm "readable" if it can be readily understood by someone who is not familiar with the particular language being used, and is not experienced with Lisp-style languages, but is experienced with ALGOL-style languages. That's not a universal definition, but at this moment in this path-dependent world it's a reasonable thing to consider.

baddox 12y ago
I think in most cases a working programmer should be able to write code under the assumption that it will be read and maintained by people who are familiar with the programming language being used.
- klibertp 12y ago
  I think you missed GP point, which I believe was that "you can write Fortran in any language". Or more precisely that you can know a language very well, but that won't help you much if you are confronted with unfamiliar idioms and patterns you don't know.
klibertp 12y ago
> who is not familiar with the particular language being used > but is experienced with ALGOL-style languages That's NOT readability, that's merely familiarity. It doesn't help anyone to confuse the two.

zwieback 12y ago

No, I don't know of any research although it may exist. My personal definition of readability is very simple: the time it takes to understand a particular piece of code. I think there's a balance between overly dense code and code that requires me to scroll through several pages or jump between files. It takes me longer to parse dense Ruby or Python code because I'm not very familiar with the languages but I'm aware that those languages give us ways to write more expressive code with less syntax overhead. The trick is to write compact code that is still easy to understand for someone other than the author.

klibertp 12y ago
> don't know of any research although it may exist I couldn't really find any, but I'd be very happy to learn that it exists. We'd be much better off as an industry if it existed. > the time it takes to understand a particular piece of code Can you see a problem with this definition? Do you think that any given piece of code has time_needed_to_understand property, which is at least similar - or at least in the same order of magnitude! - for all the people who could read it? Exactly the same few lines of code can take one person half a day to understand while some other person will know their meaning in less than 10 seconds. It's much worse than that, actually. You can show the same piece of code to several people, and you're almost guaranteed to hear complaints about both "too terse" and "too verbose"; both "too explicit" and "too implicit"; both "too noisy" and "without enough syntax sugar". And this happens even if we're talking about people who mainly program in the same language - adding other languages makes this far, far worse. You get holy wars on the grounds of readability and syntax, you get people who just won't ever touch X, because it's so much uglier (and less readable) than Y and so on. It's insane. Personally, I try to write "readable" code in every language I happen to use. I actually read a couple of books on the subject and looked through many pieces of code/projects which are widely considered "readable". That doesn't matter, because every now and then I still hear that the code I wrote is "too terse"/"too much syntax"/"too little syntax"/"too verbose" - the same code, just in the eyes of different people. Back to the article, so that it's not entirely off-topic, I find this: http_retry = retry(DOWNLOAD_TRIES, HttpError) harder_download = http_retry(download_image) images = map(harder_download, urls) very "readable" (by your definition of "readability"), as it takes me less than a second to comprehend what is it about. Conversely, this: images = [] for url in urls: for attempt in range(DOWNLOAD_TRIES): try: images.append(download_image(url)) break except HttpError: if attempt + 1 == DOWNLOAD_TRIES: raise I find much less readable, because I need to track a lot of irrelevant data to understand what it is about. On the other hand, if my task was to understand why the code retries one time less than it should (for example), then the latter code is much more readable, because I don't need to navigate to some other file to see a definition of retry (which takes time) and I just see the potential off-by-one error in front of my eyes. Anyway, "readability" is really a hard problems for the whole industry, I just wish people would admit that much and started to do some serious research on the topic instead of thinking it's obvious. Edit: I'd also like to know what people who downvoted my first post here think.