4 ms·

I agree with all your points, except list comprehensions. I used to like them, but now refer the callback style from Javascript much better. Cannot auto comple

by pnt12 2y ago

I agree with all your points, except list comprehensions. I used to like them, but now refer the callback style from Javascript much better. Cannot auto complete at start: My auto complete doesn't work at the start of a list expression. In [for obj.abcdef...], what is obj? It cannot know. In a callback, using typescript , it knows: list.forEach((obj) => obj.acdef...): obj is an element of list, which, if typed, we can infer its value. It's minor but it's not optimal. confusing multi line comprehensions I don't know how to format this in HN, but this is pretty weird in multi lines: [obj.y \n for obj in my_list \n if obj.x >3 ]. Something like this reads much better: my List.\nforEach((obj).\nfilter((obj) =>obj.x >3).\nmap((obj) => obj.y)) I'm comparing with Javascript which I don't enjoy much either. But I liked using this style in C#, with the LINQ nodule.

m_mueller 2y ago
in a strange coincidence, SQL suffers from exactly the same issue due to select being before the from statement. I nevertheless still prefer list comprehensions over doing trivial things with map/reduce simply because it reads like math.
pansa2 2y ago
> this is pretty weird in multi lines: [obj.y for obj in my_list if obj.x >3 ] Yeah, it's a shame that Python doesn't allow us to write this as `[for obj in my_list: if obj.x > 3: obj.y]`
deleted 2y ago
[deleted]
itishappy 2y ago
> I don't know how to format this in HN 4 spaces at the beginning of the line make a code block. result = [obj.y for obj in my_list if obj.x > 3] result = myList .filter((obj) => obj.x > 3) .map((obj) => obj.y)) IEnumerable<float> result = from obj in myList where obj.x > 3 select obj.x;
xelamonster 2y ago
Yeah that makes sense, and I find the map chaining for complex cases much clearer too. I always have to look up how to do a nested list comprehension and I always end up mad about how dumb the syntax for it is when I figure it out. I do very much prefer Rust's use of || instead of the parentheses for arguments though just to differentiate things. And the inconsistency in structure between function declarations and types and function literals in whether you need a colon or a fat arrow or nothing drive me insane in Javascript. I don't hate Python's solution here either, why bother with weird syntax just literally label it lambda.

by pnt12 2y ago

m_mueller 2y ago

in a strange coincidence, SQL suffers from exactly the same issue due to select being before the from statement. I nevertheless still prefer list comprehensions over doing trivial things with map/reduce simply because it reads like math.

pansa2 2y ago

> this is pretty weird in multi lines: [obj.y for obj in my_list if obj.x >3 ] Yeah, it's a shame that Python doesn't allow us to write this as `[for obj in my_list: if obj.x > 3: obj.y]`

deleted 2y ago

[deleted]

itishappy 2y ago

> I don't know how to format this in HN 4 spaces at the beginning of the line make a code block. result = [obj.y for obj in my_list if obj.x > 3] result = myList .filter((obj) => obj.x > 3) .map((obj) => obj.y)) IEnumerable<float> result = from obj in myList where obj.x > 3 select obj.x;

xelamonster 2y ago

Yeah that makes sense, and I find the map chaining for complex cases much clearer too. I always have to look up how to do a nested list comprehension and I always end up mad about how dumb the syntax for it is when I figure it out. I do very much prefer Rust's use of || instead of the parentheses for arguments though just to differentiate things. And the inconsistency in structure between function declarations and types and function literals in whether you need a colon or a fat arrow or nothing drive me insane in Javascript. I don't hate Python's solution here either, why bother with weird syntax just literally label it lambda.