If my memory serves me well, there’s no such thing as O(2n) It’s still linear complexity. Moreover, vaguely speaking, the amount of operations is the same in both cases. In filter_map, you need to filter each element, and map all elements which are not rejected. You perform the same amount of operations if you filter all elements first, and then map the result.
However, the difference is that with Enum.filter |> Enum.map an extra intermediate list is generated (compared to filter_map). If that intermediate list is big, you might experience a significant performance penalty and increased memory usage. A simple fix would be to use Stream.filter |> Enum.map instead, or to use the comprehension, as you mentioned.
No idea why filter_map is removed, but FWIW I never used it myself. I prefer piping to filter and then to map, or comprehensions.
Yes you are indeed correct about the complexity. I was simply trying to highlight that with a filter |> map solution, you would have to iterate over the list twice (in the worst case), although it would be the same amount of function invocations which would make up the bulk of the computations anyway. With a comprehension style solution (like filter_map) the list would only have to be iterated over once. However, I agree with your other points and I think that what I’m saying about the additional iteration is very similar to what you are saying about the intermediate list having some possible negative performance implications.
We can’t update Precompiled.zip because it needs to be built with an OTP version that is compatible with largest number of users and this means using the oldest supported version. The fix needs to be in asdf that either needs to compile Elixir itself on the user machine or use precompiled versions that have been compiled against specific OTP versions. An issue has been opened for this: Consider always building from source · Issue #27 · asdf-vm/asdf-elixir · GitHub.
Thank you @josevalim and Elixir team. Elixir makes me happy during work, and that’s what I value most from a language. You guys actually care about dev UX.
@svarlet: hmm, I think that I will add this to my library that I’m working on
It will be called ExUtils. I already have some interesting functions implemented, but I still need more time for it.
hmm, I think that I will add this to my library that I’m working on. It will be called ExUtils. I already have some interesting functions implemented, but I still need more time for it.
I wonder if what the elm community does is not a better approach: when someone needs an extra function for a module of the standard library, a separate library with the name of the module and the -extras suffix is created.
For example: Enum → EnumExtras (or we could do Enum.Extras).
Perhaps it would help to have a different git repo for each “Extras” module too. Since you seem to lack the time to get it done, you would most likely become a community bottleneck . So if you personally create lots of extras for the List module, you don’t become a bottleneck for those who want to create extras for the Map module.
@svarlet: It’s exactly what I want to do. Whole library will be called ExUtils and module for Enum extras will be called ExUtils.EnumUtils. Currently I have some useful String utils. I’m working on some RFC regular expressions and extended String pattern matching. I will also look for other modules and I will compare them to other languages/frameworks looking for ideas.
@bbense: Looks good, but my library will have much more functions and I will have my own separate i18n library that will have much more features. Anyway it’s good to see source code to don’t do some things again and I found some interesting ideas there too. Thanks!
It’s still linear complexity. Moreover, vaguely speaking, the amount of operations is the same in both cases. In 
. So if you personally create lots of extras for the List module, you don’t become a bottleneck for those who want to create extras for the Map module.
