Is string length len, length, size, count, num, or # ? Is there even a global function for length? You won’t know until you try all of them.

This is Python basics, so the argument would be to optimize readability specifically for people who have zero familiarity with the language.

(The other examples have the same general direction of readability tradeoff to the benefit of beginners, this one was just simplest to pick here)

That's a valid tradeoff to discuss, if discussed as a tradeoff. Here it is not. The cost to readability for anyone with language familiarity appear to be not even understood.

The point of the article is about how IDE's can't validate certain things as you type them in this order. The example of a string length function could be replaced by any other API.

I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

sum(
    all(
        abs(x) >= 1 and abs(x) <= 3 for x in line
    ) and (
        all(x > 0 for x in line) or
        all(x < 0 for x in line)
    )
    for line in diffs
)

You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

The point of the article is about how IDE's can't validate certain things as you type them in this order. The example of a string length function could be replaced by any other API.

That sounds a lot like Functional Programming

That is one of the points, yes.

But, the reason for wanting the IDE to validate based on partially entered expressions is given as making it easier to follow the code for a person working left-to-right.

And it's not an invalid thing to want, but I expect the discussion to also include how it affects reading the code for a non-beginner.

The example of a string length function could be replaced by any other API

I don't know about that, len is a built-in -- like str, abs, bool. There are only a few of them and they're well known by people familiar to the language (which seems to exclude the article author). Their use is more about the language itself than about what to expect from a particular API.

In fact, most Python APIs that go beyond built-in usage actually look much more object-oriented with "left-to-right" object.method() calls. So this argument seems silly and goes away with some familiarity with that language.

I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

sum(
    all(
        abs(x) >= 1 and abs(x) <= 3 for x in line
    ) and (
        all(x > 0 for x in line) or
        all(x < 0 for x in line)
    )
    for line in diffs
)

You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

People don’t, in fact, read code from top to bottom, left to right

100% this.

This false premise is also why a few (objectively wrong) people defend writing long essays: functions with hundreds of lines and files with thousands; saying "then you don't have to go back and forth to read it", when in fact, no one should be reading it like a novel in the first place.

Once you get used with list and dict comprehensions, they read just fine. Much like the functional approach is not really that readable for a newcomer either.

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 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.

That was the whole point of the blog post.

The blog post wasn't about reading, but about writing. And people usually do write top-to-bottom, left-to-right.

The whole point of the blog post was to write code that the IDE can help you with when writing. It didn't go into readability even once.

The argument is not silly, it totally makes sense, and your point even proves that.

A lot of libraries use module-level globals and if you use from imports (especially from X import *) you get exactly that issue.

Yes, many more modern APIs use an object-oriented approach, which is left-to-right, and that's exactly what OOP is argueing for. If you notice, he didn't end the post with "Make good languages" but with "Make good APIs". He highlights a common problem using well-known examples and generalizes it to all APIs.

The auther knows full well that this blog post will not cause Python to drop the List comprehension syntax or built-in functions. What he's trying to do is to get people to not use non-LTR approaces when designing APIs. All the points he made are correct, and many are even more pressing in other languages.

For example, for a hobby project of mine I have to use C/C++ (microcontrollers). And this problem is huge in C libraries. Every function is just dumped into the global name space and there's no way to easily find the right function. Often I have to go to google and search for an external documentation or open up the header files of a project to find a function that does what I want, instead of being able to just follow the IDE autocomplete on an object.

And sure, if I know every library and framework I use inside out and memorized all functions, methods, objects, variables and fields, then it's easy, but unless you work 30 years in a bank where you maintain the same old cobol script for decades, that's not going to happen.

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.

the last section before the conclusion only mentions readability

from X import *

That's malpractice in most cases, and thankfully, becoming more rare to find in the wild. Any decent linter will shout at you for using star imports.

What he’s trying to do is to get people to not use non-LTR approaces when designing APIs.

Then he should have picked examples of APIs that break this, not use the built-in functions. Because as it reads now, it seems he is just against established conventions for purism.

this problem is huge in C libraries

yeah, one of my favorite things about python is that everything not in the language itself is either defined in the file, or explicitly imported. Unless, like mentioned, you have anti-patterns like star imports and scripts messing with globals().

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.