2 ms·

>Which is a good thing, you don't want to cognitively overload the users with too many similar building blocks. On the other hand if you've spent some time in

>Which is a good thing, you don't want to cognitively overload the users with too many similar building blocks. On the other hand if you've spent some time in a different high level language doing stuff like this in python feels too pedestrian.

js8 10y ago
Not sure what your point is - it may feel pedestrian, but consider the alternative. Let's say, to "save users time" you decide to include all the meaningful combinations of some basic functions into your standard library. Then selecting from all those functions is about as time consuming than combining the two basic functions, unless you have memorized all of them by heart. And then, what can also happen, if you haven't got them all memorized, you actually look up for a certain combination, only to find that particular one is for whatever reason missing from the library and you still have to compose it with the other functions you have. The point is, there is a trade-off between time saved by having functions in standard library and time spent looking those functions up. So you don't want to have functions that are obvious combinations of 2-3 function, unless it's something very very common (e.g. a map function as a combination of monadic bind and return).
- rubber_duck 10y ago
  >there is a trade-off between time saved by having functions in standard library and time spent looking those functions up. Meh, difficulty of writing such code is irrelevant in comparison to how these higher level functions read and compose, consider : next(x for x in seq if x > y, None) vs. first(seq, lambda x: x > y, None) seq.first(lambda x: x > y, None) the intent is very clear in the second example, it just has useless implementation details in the first. I haven't done python in a while but every time I go back to it I find such edge cases where the code ends up being obfuscated or you write one-off functions that you need in random places and should be in std. Contrast with Clojure for eg. with it's rich collection manipulation standard library - data manipulation is high level and expressive

js8 10y ago

Not sure what your point is - it may feel pedestrian, but consider the alternative. Let's say, to "save users time" you decide to include all the meaningful combinations of some basic functions into your standard library. Then selecting from all those functions is about as time consuming than combining the two basic functions, unless you have memorized all of them by heart. And then, what can also happen, if you haven't got them all memorized, you actually look up for a certain combination, only to find that particular one is for whatever reason missing from the library and you still have to compose it with the other functions you have. The point is, there is a trade-off between time saved by having functions in standard library and time spent looking those functions up. So you don't want to have functions that are obvious combinations of 2-3 function, unless it's something very very common (e.g. a map function as a combination of monadic bind and return).

rubber_duck 10y ago
>there is a trade-off between time saved by having functions in standard library and time spent looking those functions up. Meh, difficulty of writing such code is irrelevant in comparison to how these higher level functions read and compose, consider : next(x for x in seq if x > y, None) vs. first(seq, lambda x: x > y, None) seq.first(lambda x: x > y, None) the intent is very clear in the second example, it just has useless implementation details in the first. I haven't done python in a while but every time I go back to it I find such edge cases where the code ends up being obfuscated or you write one-off functions that you need in random places and should be in std. Contrast with Clojure for eg. with it's rich collection manipulation standard library - data manipulation is high level and expressive