@Aristotle Pagaltzis said:
But I don’t think that really negates what I’m saying. What I’m asserting is that expressing a complex algorithm in code inherently introduces a layer of concreteness that shrouds the intent of the code. I’m not sure I can explain this adequately. By way of an example, take an algorithm such as “go from home to the bus station” – for a computer, you have to express this as a series of concrete instructions, so you end up with something like “starting at the location home, while your location is not the bus station, determine all adjacent locations, select the one which is closer to the bus station, move there, and repeat.”
Or you write a function that does that goFromHomeToBusStation() you'd probably make it more abstracted though, something like. somePerson.go(places.busStation) (assuming where he goes from isn't really of importance)
The function may be a bit less readable, but it's intent should be more or less described in the function name with any complex part within it refactored in the same way. Now I see that you'd want to complement with docstrings for those cases where the intent and result of the function isn't obvius, but I don't think that's the same as having inline comments in the middle of a function. Code can be just as terse as the description of it is, if it isn't, make it so.
But maybe I have misunderstood your opinion and we actually agree. :)
@Aristotle Pagaltzis said:
Wrong argument, really. Even with a broken-down codebase, you need to keep enough in your head at once to understand the interactions. And my assertion that a non-trivial unit of code comes to about 150-200 LoC even in a dense language is, I think, hard to deny.
But my point is that all the info you can concentrate in comments, you can concentrate in code.
# Do thing one
someStatement1
someStatement2
someStatement3
someStatement4
...
# Do thing two
someStatement1
someStatement2
someStatement3
someStatement4
...
Could also be written as:
def ThingOne(*args):
someStatement1
someStatement2
someStatement3
someStatement4
def ThingTwo(*args):
someStatement1
someStatement2
someStatement3
someStatement4
ThingOne(args)
ThingTwo(args)
@Aristotle Pagaltzis said:
Well, like Cyresse, if you actually read the thread through from top to bottom, you would find that I have been arguing precisely this all the time.
I don't get it then, do you think code is inheritely hard to read or, as I do, that only [i]bad[/i] code is inheritely hard to read and that it's practically always possible to make it easy to read with some effort. Except when you are locked into a language that won't lend itself to make the code easily readable.
I'm not really arguing against you, I'm just arguing agaist what you say. When you say code is hard to read, I disagree on that point, even if we agree on the usage of comments in real code.
@Aristotle Pagaltzis said:
I’m coming at this from the Perl programmer perspective.Yes, really. :-) The same syntactic freedom that is frequently abused for clever-looking or obfuscated code can also be used as an effective tool to improve the clarity of code. It just takes discipline. (And I resent tools that presume that I lack discipline; hence Perl, and not Python. If you really want to torture me, make me write Java. But Perl is not without flaws, I just like it better, warts and all. To each his own.)
It isn't the required discipline that makes me dislike languages like Perl. It's the fact that I always get lots of choices. I'm good at logic and very ba at choices, so every time I get a hard choice I lose concentration and coding speed. Therefore I really don't like useless choices, choices that really doesn't matter and that can not easliy be solved by logic. That's probably why I dislike comments too, I don't know a logic method of knowing where to use them, doc-strings are much simpler in that manner.
But as you said, to each his own. Python got it's flaws too, I'm not very fond of the __'s usage nor the inconsisteny between mutable and unmutable types.