|
- `if value in my_map` is a one off special case - ugly, nasty, hard to figure out how to extend it (what if I invented my_map to have special logic for `in` ...I need to search the docs for a magic method called for that operator ...if I even know for what keywords to search, ugh) - `if my_map.contains(value)` is nice and consistent, easy to search for the code of the .contains method and figure out what it does - `[x * 2 for x in my_list]` another ugly special case syntax, instead of general purpose higher order functions, even in Python while a `.map` method could've been easily added to dictionaries too, we had to wait years (decades?) for dictionary comprehensions to land in the language, and it's another damn special syntax one has to remember. ugh! - a sane solution not involving higher order functions usage would've been to make everything in the language an expression and have `for ...` expressions return lists or dictionaries or sets, still better than the fugly "list comprehension", I really can't comprehend why people like them - `my_list.map(x -> x * 2)` nice, clean, and general. If I work with a weirder list like thingy and want to see the logic of mapping, I can easily jump to the definition of it's `.map` method Most pseudocode is ugly and ambiguous and actually hard to read without special context from the text around it because you're never sure what something actually means, can't easily "jump to its implementation code and read it". Same like natural language, hard to non-ambiguously understand and ugly as hell in technical context where math and diagrams work 1000x times better. I can't understand why people who are trained in math, physics and/or other sciences would ever choose something just because it "looks more like pseudocode"... To me pseudocode rhymes with... pseudoscience! It's never what you want when you can choose something better. |