4 ms·

Great answer likewise! Some of those are really cool indeed! Deep copy/deep extend is a must in every programming language ever. I have no idea why 90% of the

by revvx 7y ago

Great answer likewise! Some of those are really cool indeed! Deep copy/deep extend is a must in every programming language ever. I have no idea why 90% of the environments I ever programmed with make it so damn hard to deep copy data. In javascript it is kind of comical. [1] Traversal utilities like closest/parentsUntil/nextAll/nextUntil is something I miss in most standard libraries. No for DOM manipulation, but for traversing lists and such. Until/while idioms are par for course in imperative contexts but I miss them in functional programming contexts. Not that they're that hard to implement with a couple lines :) Delay is further proof that the jQuery API design is nothing short of amazing. I wish more APIs were like that. The only thing that comes close to me, albeit in a completely different domain, is LINQ. I had no idea about End. That's point-free programming black magic. [2] Love it. [1]: https://stackoverflow.com/a/5344074 https://stackoverflow.com/a/5344074 [2]: https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming

peteforde 7y ago
Building on what you said, I would love to see more powerful node traversal functions make their way into every environment I work in. It's something worth making a push on. Moving around a tree can be a joy, and it unlocks many solution domains that might not cross your mind if you're not thinking about them. One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler. End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. It'd be even better if ES supported Ruby-style send syntax eg. array.map(&:to_s). And yes, I put it last because I was going for clever. You know what drives me even more crazy than ES' lack of deep copy/extend? How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.
- revvx 7y ago
  > One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler. That sounds really simple to achieve with with a (lazy) function that returns a list containing all ancestors of a tree, and then a "until" or "up to" function that returns everything from that list until a certain condition is met. Those are things that should be included alongside Map and Reduce :) > How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash. Oh, I strongly agree. And lodash should be the standard library of the language. Not only of Javascript, but most languages out there. > End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. About End (and point free style in general), I understand why people might dislike it, but then again, I think it comes down to familiarity. After ten years of exposure to LINQ, Haskell, underscore/lodash and FP in general I also find it super hard to follow code that uses for/do/while in overly clever ways (my own C code comes to mind). I think I find it easier to see code as a "graph" rather than assigning something to a temporary variable, and that's what End allows me to.
- darepublic 7y ago
  Your object equality example is neither maddening nor unique to JavaScript imo
  - peteforde 7y ago
    $ irb2.4.1 :001 > ({k: 1} === {k: 1}) => true I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and logical not be maddening? When does the maddening kick in... before or after I have to install lodash for comparing objects? Are you busting me on semantics? Do I literally have to check into a mental health care facility after not being able to natively compare simple ES objects to satisfy you?
    - darepublic 7y ago
      I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.
      - peteforde 7y ago
        You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug. And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter: a = {k: 1} b = {k: 1} a == b # true a.object_id == b.object_id # false Of course, this is a lot of typing, so Matz also gave us: a.equal? b # false Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.

by revvx 7y ago

peteforde 7y ago

Building on what you said, I would love to see more powerful node traversal functions make their way into every environment I work in. It's something worth making a push on. Moving around a tree can be a joy, and it unlocks many solution domains that might not cross your mind if you're not thinking about them. One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler. End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. It'd be even better if ES supported Ruby-style send syntax eg. array.map(&:to_s). And yes, I put it last because I was going for clever. You know what drives me even more crazy than ES' lack of deep copy/extend? How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.

revvx 7y ago
> One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler. That sounds really simple to achieve with with a (lazy) function that returns a list containing all ancestors of a tree, and then a "until" or "up to" function that returns everything from that list until a certain condition is met. Those are things that should be included alongside Map and Reduce :) > How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash. Oh, I strongly agree. And lodash should be the standard library of the language. Not only of Javascript, but most languages out there. > End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. About End (and point free style in general), I understand why people might dislike it, but then again, I think it comes down to familiarity. After ten years of exposure to LINQ, Haskell, underscore/lodash and FP in general I also find it super hard to follow code that uses for/do/while in overly clever ways (my own C code comes to mind). I think I find it easier to see code as a "graph" rather than assigning something to a temporary variable, and that's what End allows me to.
darepublic 7y ago
Your object equality example is neither maddening nor unique to JavaScript imo
- peteforde 7y ago
  $ irb2.4.1 :001 > ({k: 1} === {k: 1}) => true I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and logical not be maddening? When does the maddening kick in... before or after I have to install lodash for comparing objects? Are you busting me on semantics? Do I literally have to check into a mental health care facility after not being able to natively compare simple ES objects to satisfy you?
  - darepublic 7y ago
    I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.
    - peteforde 7y ago
      You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug. And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter: a = {k: 1} b = {k: 1} a == b # true a.object_id == b.object_id # false Of course, this is a lot of typing, so Matz also gave us: a.equal? b # false Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.