My colleagues don't like becuase it's so different to what they are used to but I am putting out code faster and with less bugs so I'm not going to stop.
I also do use some functional concepts in my Python work, but do not use a library for it. Only procedures or functions. No additional dependencies.
https://toolz.readthedocs.io/en/latest/control.html#other-pa...
> Most programmers have written code exactly like this over and over again, just like they may have repeated the map control pattern. When we identify code as a groupby operation we mentally collapse the detailed manipulation into a single concept.
If you don't use a library, then you have to re-write something like groupby many times, I would expect. Or WORSE, you don't even use the pattern, writing "code exactly like this over and over again".
Often one only needs one of the partitions though, which is when filter is sufficient. Otherwise I guess one can easily write partition oneself and then use that function over and over again, without resorting to a library.
But perhaps it is a good example, so that you do not have to write partition in every project and if the additional dependency is OK to have, why not, if it is indeed a good one.
But…this is exactly what a database GROUP BY does. (You’ll always have aggregations in the SELECT clause which work on the data in the groupings, but the GROUP BY itself just specifies splitting the dataset up into this kind of groupings.)
> Otherwise I guess one can easily write partition oneself and then use that function over and over again, without resorting to a library.
Yeah, literally all a library is avoiding having to rewrite code that someone has already written once.
The downside of a library is often, that it comes with its own dependencies and a lot of things you might not need. In general you should not buy into using a library whenever one is available, that among other things offers one procedure, which you need. The decision to use a library should be thought about a little more.
https://docs.python.org/3/library/itertools.html#itertools.g...
Don't forget that python is batteries included -- and you can avoid 3rd party dependencies a lot of times.
The function: https://toolz.readthedocs.io/en/latest/_modules/toolz/iterto...
One shouldn't even do that. groupby is supposed to assume that the input is already sorted by the given key, so it can be implemented as a generator. What's more, it should be implemented as a generator (that's the way the Python stlib's itertools.groupby does it), to avoid having to realize the entire iterable at once.
> Not to be confused with ``itertools.groupby``
The idea is that referencing the `append` method in the for grouping loop, i.e. doing
d[key(item)].append(item)
[1]: https://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avo......
We have started using types too I've noticed some of the types in @types/ramda are wrong where they only show arrays but it works with strings too like R.startsWith.
I might do a PR and update a few when I have time.
Yet people want to stick with a "style".
Crazy.
I use classes to but that doesn't mean I can't be functional inside them.
It is annoying when devs religiously stuck to a style even if that makes to code base worse
Is it worth being faster if it makes everyone else slower?
I find classes much hard to follow then functional code should they change their styles becuase it makes me slower?
I think we all need to play to our strengths and as a team make it so it's as easy as possible to follow code even if it's in a style you don't fully understand.