4 ms·

Maybe you'd like str |> x->parse(Int,x) |> abs ? >I like when the code reads like a sentece, it's just less mental overhead. But the OOP version is further fr

Maybe you'd like str |> x->parse(Int,x) |> abs ? >I like when the code reads like a sentece, it's just less mental overhead. But the OOP version is further from a real sentence here. You're taking the absolute value of the string parsed as an integer, not "for the string grabbing the parser to apply the change to an integer to take the absolute value".

gavinray 6y ago
I think they're both equally correct, though the UFCS/pipe syntax is mentally easier to follow. Let's say someone told you (making up random stuff): "The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y." Try to think about that in your head. By the time you've reached the end of the sentence, there have been so many steps and no context values that you can't even follow. If you take the opposite though: "Take the product of X and Y, map them over two vectors, square it, sum that, and then return the absolute value." (Again, can't guarantee these are semantically equal to each other, but you get the idea) Then you know "Okay, starting from these things, first I do this, then I do this.." whereas the opposite way, you're given a ton of directions with zero context, and then have to try to apply them all in reverse once you're finally given the starting value. You don't give directions to someone starting from the destination and working backwards.
- ChrisRackauckas 6y ago
  >"The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y." abs(sum(mean(abs2,x .* y)))?
johnhartigun 6y ago
(Using a different account because I got a "you're posting too fast" error.) It's probably even less readable to be honest. And it would mean there are now 2 ways of doing something which makes the language irregular (unless everyone switches to this syntax). I would just read it as: "Take str, convert it to an int and take the absolute value." It also corresponds to the order of steps as it actually happens. Another example where the readability difference is clearer: `images.first.resize(100, 100).crop(25, 25, 75, 75)` versus `crop(resize(first(images), 100, 100), 25, 25, 75, 75)` The former one isn't just more readable, it's also easier to write.

gavinray 6y ago

I think they're both equally correct, though the UFCS/pipe syntax is mentally easier to follow. Let's say someone told you (making up random stuff): "The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y." Try to think about that in your head. By the time you've reached the end of the sentence, there have been so many steps and no context values that you can't even follow. If you take the opposite though: "Take the product of X and Y, map them over two vectors, square it, sum that, and then return the absolute value." (Again, can't guarantee these are semantically equal to each other, but you get the idea) Then you know "Okay, starting from these things, first I do this, then I do this.." whereas the opposite way, you're given a ton of directions with zero context, and then have to try to apply them all in reverse once you're finally given the starting value. You don't give directions to someone starting from the destination and working backwards.

ChrisRackauckas 6y ago
>"The absolute value of the sum of the mean of the square of two vectors mapped over the product of X and Y." abs(sum(mean(abs2,x .* y)))?

johnhartigun 6y ago

(Using a different account because I got a "you're posting too fast" error.) It's probably even less readable to be honest. And it would mean there are now 2 ways of doing something which makes the language irregular (unless everyone switches to this syntax). I would just read it as: "Take str, convert it to an int and take the absolute value." It also corresponds to the order of steps as it actually happens. Another example where the readability difference is clearer: `images.first.resize(100, 100).crop(25, 25, 75, 75)` versus `crop(resize(first(images), 100, 100), 25, 25, 75, 75)` The former one isn't just more readable, it's also easier to write.