4 ms·

This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously with

This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously without actually proposing how comprehensions could be made better one has to hope the author would say he likes the equivalent Haskell better, but there is a strong doubt that is not the case.

Areading314 7y ago
Complaining about having to cast generators to list... seems like the kind of dev that has their code randomly run out of memory until a senior dev comes and fixes it.
- nnq 7y ago
  It is annoying! And doesn't always save memory. In theory a "sufficiently smart language" should have a feature to understand that `thing[3]` can be translated to "call `next()` 3 times and gimme the last thing", not in "turn this completely to a list, that may take a ton of memory, although I only need that one third element". Generators should be treatable as lazy lists in the end, and lists should have a common interface whether they are lazy or eager. Someone should figure out a way to have us write code at a higher abstraction level and have same interface for lazy vs eager data structures. ...but it's not gonna happen in a dynamic language like Python. And I can't say I like the "solution" of having the entire language be lazy like Haskell either :| We're stuck with "casting generators" for now, I guess, but it really does suck!
  - Cpoll 7y ago
    You don't need to cast the generator, you can do: next(itertools.islice(my_generator, n, n+1)) With that said... > In theory a "sufficiently smart language" should have a feature to understand that `thing[3]` can be translated to "call `next()` 3 times This might be a newbie trap, because next() isn't the same as indexing. What happens if I perform `thing[7]` followed by `thing[5]`? Should performing `thing[7]` put 1-6 in memory and turn the object into a generator-list hybrid?
    - nnq 7y ago
      > Should performing `thing[7]` put 1-6 in memory and turn the object into a generator-list hybrid You're right here. Probably can't work like that since generators are too general, you can't expect them to be rewindable or to not have side effects... prob you'd need a more specialized concept like a "lazy list" that would be a subtype of generator with some extra restrictions that would make it possible to implement the "hybrid" structure as an implementation detail without changing semantics. Anyway... it would be too much work and probably would turn into a footgun.
- mlevental 7y ago
  that one is legit. sometimes I do something like map(int, [x,y,z]) and I always trip over that it's a generator
mattlondon 7y ago
I personally find list comprehensions in python pretty horrible. They seem to exist only to do lots of stuff in one single line of code. You end up with totally impenetrable unreadable perl-esq garbage write-once-read-never code that is too clever for its own good. And people say python is easy to learn and good for beginners...! A better approach would be something like Java Streams/.net Lync/RxX pattern IMO. Explicit, clear, no magic, logical.
- ledauphin 7y ago
  I personally find them extremely readable, and a lot clearer than for loops about the lack of side effects.
- BenFrantzDale 7y ago
  I disagree. It’s basically set-builder notation, which probably predates any programming language. It’s a concise way to express filtering.
- FpUser 7y ago
  " impenetrable unreadable perl-esq garbage write-once-read-never code " - I had about the same impression when I first saw it. I think ternary operator is as far as I am willing to go ;)
- novok 7y ago
  You can decompose any list comprehension into it's equivalent for loop fairly easily. I don't see what is so magic about them other than the language having a special compiler level optimization for them? g = [i for i in list if x == 3] -> g = []; for i in list: if x == 3: g.append(i);
  - mplanchard 7y ago
    I see people frequently say that list comprehensions are special-cased and highly optimized by the compiler, but I did a few experiments recently with `timeit` and found that using `map()` is on the order of 1.5x faster in all the cases I tested. I think that either winds up being faster than a manual for loop, though
dang 7y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html For example, instead of putting someone's article down as sophomoric, you could explain what's different and possibly better about Haskell list comprehensions.
- xcct 7y ago
  You could, but you'd lose the Socratic method and efficiency of thinking. There is a reason why many academics can be quite acerbic. All these politeness comments are a speed bump that distracts from the real issues.
  - dang 7y ago
    There's a huge difference between a classroom environment or academic symposium, and an internet forum. Here, when people attack and take swipes at each other, discussion slides downhill so fast that it becomes an existential issue for the forum. Having HN not destroy itself the way internet communities usually do has been the main goal here since pg created the site over a decade ago, and the guidelines here are written with all that experience in mind. I used to think similarly about this to what you express, because I've always enjoyed reading about the sort of discourse in which devastating wit is exchanged. But eventually I realized that it doesn't translate into this context at all. This is a case of 'the medium is the message'. When you have millions of people who don't know each other all potentially interacting at the same time, the dynamics are so different as to be incommensurable with, say, small debates, literary journals, elite social events, and other places where the groups are small and highly cohesive. Here are some previous explanations about this: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=rugby%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/item?id=15378909 https://news.ycombinator.com/item?id=15378909 https://news.ycombinator.com/item?id=9378899 https://news.ycombinator.com/item?id=9378899 https://news.ycombinator.com/item?id=7906377 https://news.ycombinator.com/item?id=7906377 https://news.ycombinator.com/item?id=7742471 https://news.ycombinator.com/item?id=7742471

Areading314 7y ago

Complaining about having to cast generators to list... seems like the kind of dev that has their code randomly run out of memory until a senior dev comes and fixes it.

nnq 7y ago
It is annoying! And doesn't always save memory. In theory a "sufficiently smart language" should have a feature to understand that `thing[3]` can be translated to "call `next()` 3 times and gimme the last thing", not in "turn this completely to a list, that may take a ton of memory, although I only need that one third element". Generators should be treatable as lazy lists in the end, and lists should have a common interface whether they are lazy or eager. Someone should figure out a way to have us write code at a higher abstraction level and have same interface for lazy vs eager data structures. ...but it's not gonna happen in a dynamic language like Python. And I can't say I like the "solution" of having the entire language be lazy like Haskell either :| We're stuck with "casting generators" for now, I guess, but it really does suck!
- Cpoll 7y ago
  You don't need to cast the generator, you can do: next(itertools.islice(my_generator, n, n+1)) With that said... > In theory a "sufficiently smart language" should have a feature to understand that `thing[3]` can be translated to "call `next()` 3 times This might be a newbie trap, because next() isn't the same as indexing. What happens if I perform `thing[7]` followed by `thing[5]`? Should performing `thing[7]` put 1-6 in memory and turn the object into a generator-list hybrid?
  - nnq 7y ago
    > Should performing `thing[7]` put 1-6 in memory and turn the object into a generator-list hybrid You're right here. Probably can't work like that since generators are too general, you can't expect them to be rewindable or to not have side effects... prob you'd need a more specialized concept like a "lazy list" that would be a subtype of generator with some extra restrictions that would make it possible to implement the "hybrid" structure as an implementation detail without changing semantics. Anyway... it would be too much work and probably would turn into a footgun.
mlevental 7y ago
that one is legit. sometimes I do something like map(int, [x,y,z]) and I always trip over that it's a generator

mattlondon 7y ago

I personally find list comprehensions in python pretty horrible. They seem to exist only to do lots of stuff in one single line of code. You end up with totally impenetrable unreadable perl-esq garbage write-once-read-never code that is too clever for its own good. And people say python is easy to learn and good for beginners...! A better approach would be something like Java Streams/.net Lync/RxX pattern IMO. Explicit, clear, no magic, logical.

ledauphin 7y ago
I personally find them extremely readable, and a lot clearer than for loops about the lack of side effects.
BenFrantzDale 7y ago
I disagree. It’s basically set-builder notation, which probably predates any programming language. It’s a concise way to express filtering.
FpUser 7y ago
" impenetrable unreadable perl-esq garbage write-once-read-never code " - I had about the same impression when I first saw it. I think ternary operator is as far as I am willing to go ;)
novok 7y ago
You can decompose any list comprehension into it's equivalent for loop fairly easily. I don't see what is so magic about them other than the language having a special compiler level optimization for them? g = [i for i in list if x == 3] -> g = []; for i in list: if x == 3: g.append(i);
- mplanchard 7y ago
  I see people frequently say that list comprehensions are special-cased and highly optimized by the compiler, but I did a few experiments recently with `timeit` and found that using `map()` is on the order of 1.5x faster in all the cases I tested. I think that either winds up being faster than a manual for loop, though

dang 7y ago

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html For example, instead of putting someone's article down as sophomoric, you could explain what's different and possibly better about Haskell list comprehensions.

xcct 7y ago
You could, but you'd lose the Socratic method and efficiency of thinking. There is a reason why many academics can be quite acerbic. All these politeness comments are a speed bump that distracts from the real issues.
- dang 7y ago
  There's a huge difference between a classroom environment or academic symposium, and an internet forum. Here, when people attack and take swipes at each other, discussion slides downhill so fast that it becomes an existential issue for the forum. Having HN not destroy itself the way internet communities usually do has been the main goal here since pg created the site over a decade ago, and the guidelines here are written with all that experience in mind. I used to think similarly about this to what you express, because I've always enjoyed reading about the sort of discourse in which devastating wit is exchanged. But eventually I realized that it doesn't translate into this context at all. This is a case of 'the medium is the message'. When you have millions of people who don't know each other all potentially interacting at the same time, the dynamics are so different as to be incommensurable with, say, small debates, literary journals, elite social events, and other places where the groups are small and highly cohesive. Here are some previous explanations about this: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=rugby%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/item?id=15378909 https://news.ycombinator.com/item?id=15378909 https://news.ycombinator.com/item?id=9378899 https://news.ycombinator.com/item?id=9378899 https://news.ycombinator.com/item?id=7906377 https://news.ycombinator.com/item?id=7906377 https://news.ycombinator.com/item?id=7742471 https://news.ycombinator.com/item?id=7742471