I'm truly baffled by how insane the `map/reduce/filter` iterator API for #Python is. Most languages, even JavaScript, have some sort of "other_list = the_list.map().filter()" API. Except Python (and PHP?).
Now, I can imagine that a language that primarily deals with string manipulation or DOM management or so, to have a crappy API for handling large lists of data. But python's entire success comes from "handleing large lists of data", yet the tools to do so are infuriating.
🇳🇱
@berkes I'm fairly certain Python has this, but before i go figure out the exact syntax I want to understand your ask a bit better. Are you saying the functionality doesnt exist at all, or simply that you cant chain them together and they need to be on seperate lines, or something else I'm missing?
Python does have the functions though:
filter(other_func, map(the_func, the_list))
That should be roughly the same as what you asked for... Are you just complaining about the syntax, seems functionally pretty interchangable.
@freemo I was referring to that. The insanity being that they are global functions and not something you call on a iterator like every other language has.
@berkes @freemo In Python they are functions, not methods, because they work with any iterable (strings, lists, tuples, bytes, literraly any containers, even the ones you create). It's easier than having to implement a map and a reduce function on every container.
But in Python we don't even use map and filter, comprehensions are (very often) more readable:
>>> sum(map(abs, filter(lambda x: x > 10, the_iterable)))
vs
>>> sum(abs(x) for x in the_iterable if x > 10)
To be fair IMO all collections should have a common parent class, this would have all the common stuff like map, filter, getting the iterator, etc. I do agree with berkes that doing it as a method would look nicer and feel nicer.
That said, I cant think of any situation where it makes any sort of functional difference.
aesthetics != ergonomics.
The use of the global function has exactly the same number of key presses to represent it. It may look ugly, but beyond that there is no down side. Ergonomics implies it makes the problem physically straining, it does not.
Ugly vs pretty isnt really important, not in a utilitarian sense. For me I weigh aesthetics higher than most and it will effect my desire (or rather lack thereof) to use python. But I recognize that is really just a silly quirk of mine and not a functional black mark against the language.
@freemo @mdk You have a completely different (wrong?) definition of ergonomics in software. Aesthetics is *part of* ergonomics.
As is a **readable and expressive syntax, an effective standard library**, good tooling, and so on.
having to read backwards from deeply nested function calls is neither of these. And, indeed, it also looks ugly, but that's the least of the concerns.
> You have a completely different (wrong?) definition of ergonomics in software. Aesthetics is *part of* ergonomics.
No it isnt. How pretty something looks, when it has no effect on usability itself, does **not** fall under ergonomics. Ergonomics is defined as the following:
"Ergonomics is a body of knowledge about human abilities, human limitations and other human characteristics that are relevant to design. Ergonomic design is the application of this body of knowledge to the design of tools, machines, systems, tasks, jobs and environments for safe, comfortable and effective human use"
Therefore things like "this can be done in less lines of code" would be ergonomics, but "this looks pretty but has no other advantages" is not. Ergonomics is always about usability, not how pretty something is.
> As is a **readable and expressive syntax, an effective standard library**, good tooling, and so on.
If that described what we are talking about then yes, I'd agree it is an ergonomics issue. However the two syntaxes have absolutely no different in their readability or expressiveness. Which is why I say this has nothing to do with ergonomics. If one syntax actually was easier to read or write then I might agree, but as pointed out both are equal and even have the smae number of key presses. Actually if you want to get technical the python version needs one less key pres (the dot) and thus would be the more ergonomic of the two.
> having to read backwards from deeply nested function calls is neither of these. And, indeed, it also looks ugly, but that's the least of the concerns.
You dont have to "read backwards", you are reading forwards with that syntax. It is only "backwards" if you consider your preferred syntax as forward, which is arbitrary.
Its like saying "Joe rides the horse" is a bad sentence because its backwards and "The horse is ridden by joe" is the correct one because its forwards. When in reality they are just reverse order of eachother and neither is the privileged "forward" version.
@freemo like I said. A very different (wrong?) definition of ergonomics in *programming languages*.
No the definition is the same, just more specific in software.
Here is the definition of software ergonomics (soft ergonomics) which is clearly in line with the general definition:
Soft ergonomics is the study of designing virtual interfaces that cater towards the wellness of the human body, its emotional and cognitive abilities.
Soft ergonomics is a subset of ergonomics and human factors engineering, a larger body of the study of human abilities for designing equipment and devices that fit the human body. Soft ergonomics can be thus defined as the ability of any virtual interface(computer application, website, ATM options, parking meter etc.) to make it comfortable for the user to use the interface while working on the user's request.
@freemo @mdk it hardly makes theoretical difference.
But the ergonomics and the communication are very different.
Ergonomics: Many other methods in python act 'on the thing' (str.capitalize() etc). So it's inconsistent.
Chaining isn't possible: thelist.map().filter().sort().reduce() vs reduce(sort(filter(map(thelist))). Gets worse with multiline lambdas.
Comms: custom classes can have iterator methods implemented (ie a custom .sort()) But they cannot introduce global methods.