101–110 of 239 posts
The point about "Inadequate data modelling facilities" is why I wrote Maps: https://github.com/pcattori/maps . Specifically, the "Named Maps" variants provide the same interface as `namedtuple` but for different levels of immutability/mutability. Feedback/suggestions welcome!
The point about "Inadequate data modelling facilities" is why I wrote Maps: https://github.com/pcattori/maps . Specifically, the "Named Maps" variants provide the same interface as `namedtuple` but for different levels of immutability/mutability. Feedback/suggestions welcome!
The point about "Inadequate data modelling facilities" is why I wrote Maps: https://github.com/pcattori/maps . Specifically, the "Named Maps" variants provide the same interface as `namedtuple` but for different levels of immutability/mutability. Feedback/suggestions welcome!
Earlier quoted context omitted.
>lambda is fine, if you're writing in functional style you're using expressions for everything anyway. No, I /really would/ like to be able to write: foo.on_click(lambda: x += 1) The language not supporting this (when most others do) is just silly.
> foo.on_click(lambda: x += 1) Mutation in lambdas is not compatible with your complaint about "inadequate support for high-level functional programming", as it goes against the principles of FP. You can't do that in Haskell either, and any FP purist would blanch at a statement like that.
Obviously you've never met State and/or lens then.
Yes, you can do it -- and no, I never said it should follow pure FP principles.
Clojure:
is compiled to JVM byte-code and is fast.
has a good parallelism story (parallel map, parallel fold, channels)
is almost completely backwards compatible.
has a sequence abstraction that leverages the same operations over many different types (string, vecctor, list, set, map, etc.).
has a standard compose function.
has reduce, map and filter in the standard library. Transducers (also first class) further extend their usefulness.
's closures allow statements and there's even sugar for annonymous functions.
has macros to reduce boilerpate.
has a conditional macro.
I'm sure this list isn't unique to Clojure but I'm most familiar with it.
I realize that after reading the article, most people (including me, unfortunately) read the article as 'Problems WE have with Python'. Maybe a line by author at the top or bottom of the article, reiterating that it's the problem 'he' has with Python -- I know nobody would think such a second clarification would be necessary, but hey, we're humans! -- would help.
For flatten, use: flattened = sum(list_of_lists, ())
Why cant the author submit some of these changes ? Its easy to rant
could someone explain to me why >>> ranges = [range(i) for i in range(5)] >>> [*item for item in ranges] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] would be better than: >>> ranges = [range(i) for i in range(5)] >>> [item for subrange in ranges for item in subrange] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
I would expect that ranges is on the end, but it is somewhere in the middle.
[item for item in subrange for subrange in ranges]
Now I need to start in the middle (ranges), scan to the left (for subrange), then to to the end (for item in subrange) and then back to the beginning (item). Or something like that, it is hard to follow your own eye movements. :)
Note that I seldom use python and the * pattern is something I recognize from another language, so I am biased. I imagine a seasoned python dev has no problems with the second case.
Btw, does python let you overload those comprehensions? That would be nice.
This is a tired, trolling post. Most of these issues have long been addressed as non-problems or personal preferences; when the author says "Incompetence? Politics?" what I hear is "people don't listen to me, probably because I don't know what I'm talking about". The attitude is confirmed by his/her conflating of stdlib gripes and language gripes - two very different sets of problems - and mixing requests for speed w…