4 ms·

True enough about Python but I was responding more about pipes in general which Python doesn't have. I'm more confused about the original assertion that pipes

True enough about Python but I was responding more about pipes in general which Python doesn't have. I'm more confused about the original assertion that pipes give you lower confidence as to what is happening. But then I looked up how they work in Julia and saw there are two different ways they are implemented so I agree that that is maybe a little bit unfortunate, though I can't really say for sure as I've never written a line of Julia.

em-bee 3y ago
i saw pipes and import as two unrelated topics, and i was just responding to import topic. with pipes i have no experience at all. but they certainly look useful. a()|>b()|>c() looks better than c(b(a())) but i can see the confusion because there are now two ways to pass an argument. but even then a(i,j)|>b(x,y)|>c(z) is still more readable than c(b(a(i,j),x,y),z). now i want this feature in all my favorite languages
- thumbuddy 3y ago
  Not sure why I got down oted so hard but I personally like, x.a().b().c(). Because the functions are bound to the type. When they aren't sure pipes, but that's rare when a type is well defined. Super zen for me
  - em-bee 3y ago
    if course x.a().b().c() is just fine, but it only works in object oriented languages where these functions return the right object for the next step. the pipe method works with any other function as long as the output type matches the type of the first argument of the next function.
    - thumbuddy 3y ago
      ML languages aren't really OOP similarly neither is Rust really. There's a beautiful middle ground between piles of functions and types with purpose that doesn't suffer from the swamp nor the over abstracted mess that a lot of paradigms offer. Okay I'll get off my high horse but I recommend trying one of these paradigms someday if you haven't already. Traits are wonderful.
      - sodapopcan 3y ago
        I can't explain the downvotes other than that in OO method chaining does not bind you to a specific type. I don't really know Python but in Ruby, for example, you can do `"string".split.map { |s| s.upcase }`. IE, a method doesn't have to return a reference to `self`, so I'm not really seeing your argument other than choosing to use the style of only chaining when the object types match, which you can still do with pipes if you want. The only ML language I have any experience with is OCaml which is statically typed and has pipes. EDIT: re-reading your last comment it looks like I totally ignored the first part of what you said, but I guess I'm confused. This thread is also probably nested enough, lol.
- sodapopcan 3y ago
  Ya, pipes are really nice. Of course people do tend to get obsessed with them and try and make everything a pipeline. I find pipes fit the functional paradigm really well as they are clearest when they don't result in any kind of side-effects or mutation. Method chaining, on the other hand, is all about side-effects (mutating the object). I really like pipelines but know people who try and make everything a pipeline.
sundarurfriend 3y ago
> saw there are two different ways they are implemented What do you mean by that?
- sodapopcan 3y ago
  Just that you can do `|> foo()` implicitly into the first argument or, via another package mentioned in the official docs, `|> foo(_)`. This isn't necessarily a bad thing, I was just trying to understand the comment way up this thread that said: "Writing them, you feel insecure of what is happening" as that makes no sense to me.
  - sundarurfriend 3y ago
    Ah, okay. The use of the second form requires a `@chain` macro annotation in the beginning of that expression, so I've never found this to be ambiguous.

em-bee 3y ago

i saw pipes and import as two unrelated topics, and i was just responding to import topic. with pipes i have no experience at all. but they certainly look useful. a()|>b()|>c() looks better than c(b(a())) but i can see the confusion because there are now two ways to pass an argument. but even then a(i,j)|>b(x,y)|>c(z) is still more readable than c(b(a(i,j),x,y),z). now i want this feature in all my favorite languages

thumbuddy 3y ago
Not sure why I got down oted so hard but I personally like, x.a().b().c(). Because the functions are bound to the type. When they aren't sure pipes, but that's rare when a type is well defined. Super zen for me
- em-bee 3y ago
  if course x.a().b().c() is just fine, but it only works in object oriented languages where these functions return the right object for the next step. the pipe method works with any other function as long as the output type matches the type of the first argument of the next function.
  - thumbuddy 3y ago
    ML languages aren't really OOP similarly neither is Rust really. There's a beautiful middle ground between piles of functions and types with purpose that doesn't suffer from the swamp nor the over abstracted mess that a lot of paradigms offer. Okay I'll get off my high horse but I recommend trying one of these paradigms someday if you haven't already. Traits are wonderful.
    - sodapopcan 3y ago
      I can't explain the downvotes other than that in OO method chaining does not bind you to a specific type. I don't really know Python but in Ruby, for example, you can do `"string".split.map { |s| s.upcase }`. IE, a method doesn't have to return a reference to `self`, so I'm not really seeing your argument other than choosing to use the style of only chaining when the object types match, which you can still do with pipes if you want. The only ML language I have any experience with is OCaml which is statically typed and has pipes. EDIT: re-reading your last comment it looks like I totally ignored the first part of what you said, but I guess I'm confused. This thread is also probably nested enough, lol.
sodapopcan 3y ago
Ya, pipes are really nice. Of course people do tend to get obsessed with them and try and make everything a pipeline. I find pipes fit the functional paradigm really well as they are clearest when they don't result in any kind of side-effects or mutation. Method chaining, on the other hand, is all about side-effects (mutating the object). I really like pipelines but know people who try and make everything a pipeline.

sundarurfriend 3y ago

> saw there are two different ways they are implemented What do you mean by that?

sodapopcan 3y ago
Just that you can do `|> foo()` implicitly into the first argument or, via another package mentioned in the official docs, `|> foo(_)`. This isn't necessarily a bad thing, I was just trying to understand the comment way up this thread that said: "Writing them, you feel insecure of what is happening" as that makes no sense to me.
- sundarurfriend 3y ago
  Ah, okay. The use of the second form requires a `@chain` macro annotation in the beginning of that expression, so I've never found this to be ambiguous.