7 ms·

> In fact, if my calculations are correct, out of 65,745 lines in the original nsprpub, 36,046 are present unchanged in the current version of nsprpub, i.e. 54.

by hu3 7y ago

> In fact, if my calculations are correct, out of 65,745 lines in the original nsprpub, 36,046 are present unchanged in the current version of nsprpub, i.e. 54.8%. This supports the statement that code is read many times more than written. So think about that when trying to be clever.

lmilcin 7y ago
I play a mind game in which the smartest code is the one that looks dumbest and is easiest to understand (of course while still working best).
jodrellblank 7y ago
How do you know anyone has ever read that code? Surely they read the lines they changed - that's where the problems were - did they necessarily read the lines they left alone? Even if it is true that code is read many times more than it is written, isn't that an argument for writing shorter, more dense code, so there's less of it to read? And an argument for more clever code so it's more interesting to read? If you're going to spend the next six months reading, that doesn't make you want all books to turn into Spot the Dog, does it? To the contrary the more you do something, the better you get at doing it; reading more code is often suggested as a way to make yourself better at programming. In fact, isn't it equally an argument for "if people have to read the code, there aren't enough comments, and/or there wasn't enough code verification"? Comments are for people to read, code is for computers to execute. The refrain "code is for people to read and only incidentally for machines to execute" is like saying "engines are for people to watch and only incidentally to move vehicles" - it would lead to engines made of perspex, taking up the size of a room so there's plenty of open spaces to stick your head in for a look around, interrupting the combustion cycles for cleaning and washing cycles, moving at 10 rpm so it's not too fast to see...
- rovr138 7y ago
  > How do you know anyone has ever read that code? Surely they read the lines they changed - that's where the problems were Of course. To fix an issue on a line, you need to know the context it’s used on and what happens with the line before and after. You also know what calls it or under what context. > did they necessarily read the lines they left alone? We can’t say for all of them, but they must have read lines that directly interact with it.
- saagarjha 7y ago
  > Even if it is true that code is read many times more than it is written, isn't that an argument for writing shorter, more dense code, so there's less of it to read? This sounds like the rationale behind the APLs.
irrational 7y ago
Clear is better than clever. Unfortunately there is no agreement on what is clear and what is clever. I think arrow functions in JS are more clever than clear, but I’ve had people tell me that my opinion is mistaken.
- anonymoushn 7y ago
  is this because you think having one dynamically scoped variable is clearer than having 0?
  - austincheney 7y ago
    I think arrow functions are less clear because they are always anonymous functions. Anonymous functions complicate stack traces and performance profiles.
    - DonHopkins 7y ago
      Guido wrote a fascinating article about why Python lambdas are expressions and not functions, so if you want multiple statements, you have to def a function and refer to it by name. https://www.artima.com/weblogs/viewpost.jsp?thread=147358 https://www.artima.com/weblogs/viewpost.jsp?thread=147358 >All Things Pythonic: Language Design Is Not Just Solving Puzzles. By Guido van van Rossum, February 10, 2006. >Summary: >An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design. [...] http://lambda-the-ultimate.org/node/1298 http://lambda-the-ultimate.org/node/1298 >Guido: Language Design Is Not Just Solving Puzzles >And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. >The discussion is about multi-statement lambdas, but I don't want to discuss this specific issue. What's more interesting is the discussion of language as a user interface (an interface to what, you might ask), the underlying assumption that languages have character (e.g., Pythonicity), and the integrated view of semantics and syntax of language constructs when thinking about language usability. [...]

by hu3 7y ago

lmilcin 7y ago

I play a mind game in which the smartest code is the one that looks dumbest and is easiest to understand (of course while still working best).

jodrellblank 7y ago

How do you know anyone has ever read that code? Surely they read the lines they changed - that's where the problems were - did they necessarily read the lines they left alone? Even if it is true that code is read many times more than it is written, isn't that an argument for writing shorter, more dense code, so there's less of it to read? And an argument for more clever code so it's more interesting to read? If you're going to spend the next six months reading, that doesn't make you want all books to turn into Spot the Dog, does it? To the contrary the more you do something, the better you get at doing it; reading more code is often suggested as a way to make yourself better at programming. In fact, isn't it equally an argument for "if people have to read the code, there aren't enough comments, and/or there wasn't enough code verification"? Comments are for people to read, code is for computers to execute. The refrain "code is for people to read and only incidentally for machines to execute" is like saying "engines are for people to watch and only incidentally to move vehicles" - it would lead to engines made of perspex, taking up the size of a room so there's plenty of open spaces to stick your head in for a look around, interrupting the combustion cycles for cleaning and washing cycles, moving at 10 rpm so it's not too fast to see...

rovr138 7y ago
> How do you know anyone has ever read that code? Surely they read the lines they changed - that's where the problems were Of course. To fix an issue on a line, you need to know the context it’s used on and what happens with the line before and after. You also know what calls it or under what context. > did they necessarily read the lines they left alone? We can’t say for all of them, but they must have read lines that directly interact with it.
saagarjha 7y ago
> Even if it is true that code is read many times more than it is written, isn't that an argument for writing shorter, more dense code, so there's less of it to read? This sounds like the rationale behind the APLs.

irrational 7y ago

Clear is better than clever. Unfortunately there is no agreement on what is clear and what is clever. I think arrow functions in JS are more clever than clear, but I’ve had people tell me that my opinion is mistaken.

anonymoushn 7y ago
is this because you think having one dynamically scoped variable is clearer than having 0?
- austincheney 7y ago
  I think arrow functions are less clear because they are always anonymous functions. Anonymous functions complicate stack traces and performance profiles.
  - DonHopkins 7y ago
    Guido wrote a fascinating article about why Python lambdas are expressions and not functions, so if you want multiple statements, you have to def a function and refer to it by name. https://www.artima.com/weblogs/viewpost.jsp?thread=147358 https://www.artima.com/weblogs/viewpost.jsp?thread=147358 >All Things Pythonic: Language Design Is Not Just Solving Puzzles. By Guido van van Rossum, February 10, 2006. >Summary: >An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design. [...] http://lambda-the-ultimate.org/node/1298 http://lambda-the-ultimate.org/node/1298 >Guido: Language Design Is Not Just Solving Puzzles >And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. >The discussion is about multi-statement lambdas, but I don't want to discuss this specific issue. What's more interesting is the discussion of language as a user interface (an interface to what, you might ask), the underlying assumption that languages have character (e.g., Pythonicity), and the integrated view of semantics and syntax of language constructs when thinking about language usability. [...]