Not a single time did OOP talk about readability. That was not a point at all, so I don’t know why you are all about readability.
It was all about having a language that the IDE can help you write in because it knows what you are talking about from the beginning of the line.
The issue with the horrible one-liner (and with your nicely split-up version) is that the IDE has no idea what object you are talking about until the second-to-last non-whitespace character. The only thing it can autocomplete is “diffs”. Up until you typed the word, it has no idea whether sum(), all(), abs(), <, >, or for-in actually exist for the data type you are using.
If you did the same in Java, you’d start with diffs and from then on the IDE knows what you are talking about, can help you with suggesting functions/methods, can highlight typos and so on.
I think rust’s iterator chains are nice, and IDE auto-complete is part of that niceness. But comprehension expressions read very naturally to me, more so than iterator chains.
I mean, how many python programmers don’t even type hint their code, and so won’t get (accurate) auto-complete anyway? Auto-completion is nice but just not the be-all and end-all.
Fair, I missed one word. You missed the whole blog post.
It’s a big difference between writing code and writin APIs, tbh. If you write crap code that’s your problem. If you write crap APIs it’s the problem of anyone using your API.
The blog post is really about language design, because you definitely should not write a filter method for your custom iterable class in python; you should make it use the language’s interface’s for “being an iterable”. Language design involves APIs offered by the language, but isn’t really the purview of most people who write APIs.
If a suggestion on language design would gain something at the cost of readability, anyone should be very skeptical of that.
Those things together explain why I am evaluating the post mostly in terms of readability.
Did we read the same blog post?
Not a single time did OOP talk about readability. That was not a point at all, so I don’t know why you are all about readability.
It was all about having a language that the IDE can help you write in because it knows what you are talking about from the beginning of the line.
The issue with the horrible one-liner (and with your nicely split-up version) is that the IDE has no idea what object you are talking about until the second-to-last non-whitespace character. The only thing it can autocomplete is “diffs”. Up until you typed the word, it has no idea whether sum(), all(), abs(), <, >, or for-in actually exist for the data type you are using.
If you did the same in Java, you’d start with
diffsand from then on the IDE knows what you are talking about, can help you with suggesting functions/methods, can highlight typos and so on.That was the whole point of the blog post.
I dunno, did we?
I think rust’s iterator chains are nice, and IDE auto-complete is part of that niceness. But comprehension expressions read very naturally to me, more so than iterator chains.
I mean, how many python programmers don’t even type hint their code, and so won’t get (accurate) auto-complete anyway? Auto-completion is nice but just not the be-all and end-all.
Fair, I missed one word. You missed the whole blog post.
It’s a big difference between writing code and writin APIs, tbh. If you write crap code that’s your problem. If you write crap APIs it’s the problem of anyone using your API.
The blog post is really about language design, because you definitely should not write a
filtermethod for your custom iterable class in python; you should make it use the language’s interface’s for “being an iterable”. Language design involves APIs offered by the language, but isn’t really the purview of most people who write APIs.If a suggestion on language design would gain something at the cost of readability, anyone should be very skeptical of that.
Those things together explain why I am evaluating the post mostly in terms of readability.