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.
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.
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 fromX 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.
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().
He’s using simple examples that everyone knows and understands instantly. It’s like using a minimal test case to report a bug. In most cases a minimal test case is also nonsensical on its own, but it’s used to show an issue that occurred in a more complex context without overloading the reader with useless garbage info that doesn’t contribute to the point at hand.
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.
It’s got nothing to do with being a beginner. I’ve been working as a professional software developer for ~15 years now and still I have to use new libraries/frameworks/in-house dependencies quite frequently. I know how to get the length of a string, and so does the author of the article.
But that’s why it’s a simple example and nothing more, and it applies to everything else. We write left to right, and IDEs autocomplete left to right, so it makes sense for languages to be designed to work that way.
There’s a lot of reasons why Java works much better with IDEs than python, and this is one of them.
Besides that, it is best practice to show problems on simple, easy to follow use cases that highlight exactly the problem in question without further fluff. It’s expected that a non-beginner can abstract that problem into more difficult use cases, so I don’t think OOP did anything wrong with choosing string length as an example.
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 don’t know about that,
lenis a built-in – likestr,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.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.
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.
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.
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().
He’s using simple examples that everyone knows and understands instantly. It’s like using a minimal test case to report a bug. In most cases a minimal test case is also nonsensical on its own, but it’s used to show an issue that occurred in a more complex context without overloading the reader with useless garbage info that doesn’t contribute to the point at hand.
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.
It’s got nothing to do with being a beginner. I’ve been working as a professional software developer for ~15 years now and still I have to use new libraries/frameworks/in-house dependencies quite frequently. I know how to get the length of a string, and so does the author of the article.
But that’s why it’s a simple example and nothing more, and it applies to everything else. We write left to right, and IDEs autocomplete left to right, so it makes sense for languages to be designed to work that way.
There’s a lot of reasons why Java works much better with IDEs than python, and this is one of them.
Besides that, it is best practice to show problems on simple, easy to follow use cases that highlight exactly the problem in question without further fluff. It’s expected that a non-beginner can abstract that problem into more difficult use cases, so I don’t think OOP did anything wrong with choosing string length as an example.