3 ms·
The point is not that we're idiots who don't know the language, but that functional-style ordering does not align with human cognitive cues. The problem is tha
by pierrebai 5y ago
The point is not that we're idiots who don't know the language, but that functional-style ordering does not align with human cognitive cues.
The problem is that functional-style fails to separate essential bits and fails to give strong visual clues where each bits begins and ends.
That is why the old imperative style is clearer. Compare:
for i in container:
do something with i
and
[do something with i for i in container]
One has a clear separation of loop and action, the other requires scanning for the "for i" in the middle. This generalize to other similar construct, and the Python ternary operator has the same flaw. The imperative if / else version clearly separate alternatives on separate lines.
IMO, syntax design should always try to learn from the imperative style and always strive to produce a syntax that clearly separate each logical item in a compound statement, and using different lines is one of the best for us human to visually grok.
(That's why even Lisper will often format their code to separate bits on different lines!)
- inanutshellus 5y agoDon't be a jerk. OP clearly stated he didn't understand it: > When it's just "if" it goes after the "for", when it's "if/else" it goes, all of it, before. I still don't understand why it's this way and discussing it here on HN shouldn't be punished. ... Back to the topic at hand ... List comprehensions save you enough syntax to be worth it, IMHO: mylist=[] for i in container: if i > 10: mylist.append(i*2) vs mylist = [x*2 for x in container if x > 10] ... That's a very terse, clean request for work and arguably it's easier to read than "for(int i=0; i<10; i++)", which we've all acclimated to by the end of CS101. I think they're quite worth the trade-off.