3 ms·
I think it's not so clear a lot of times which function is called. Say you write a function that accepts your type as an argument. Cool, you compile it everythi
by thumbuddy 3y ago
I think it's not so clear a lot of times which function is called. Say you write a function that accepts your type as an argument. Cool, you compile it everything is good. Now you import a library, just so happens it also has a function that has the same name, and accepts an argument of the same parent type. Which function gets called? If you're reading the code and not intimately familiar with how imports work, all the imports in scope, and the function your coworker defined on like 5,000 in a random file you might not be sure unless you start debugging.
Pipes are fine, but methods and traits with a strong type system reduce any ambiguity there.
Doesn't mean you can't use pipes reasonably! But in Julia that seems like it could be harder to unpack.
- StackOverlord 3y ago> Say you write a function that accepts your type as an argument. Cool, you compile it everything is good. Now you import a library, just so happens it also has a function that has the same name, This has nothing to do with pipes, this is a matter of namespacing.
- thumbuddy 3y agoWell when methods by definition associate a type instance to a function the name spacing is obvious...
- sodapopcan 3y agoThis is why I generally dislike imports. It's common practice in Elixir (and I believe some other functional languages) to generally fully qualify function calls. " hello world " |> String.trim() |> String.split() |> Enum.map(fn char -> String.uppercase(char) end) |> Enum.join() #=> "HELLO WORLD" I'm sure some will think that is too verbose but I love it. Otherwise pipes are far more flexible than method chaining just because you aren't constrained to one "type". You don't always want to do this, but as per the example above, it's pretty handy. You also don't have to rely on a method you don't own returning an instance of itself.
- em-bee 3y agowell, it depends on how import works. in python you can't use a module unless you import it, (though you can import it in a way that the full path to the function is still needed) but for example in pike import is only useful as a shortcut, and not needed if you use fully qualified function calls. and like you i never saw the point of import. using the fully qualified function calls makes the code more readable because i can quickly recognize library functions from custom code.
- sodapopcan 3y agoTrue 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 agoi 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
- deleted 3y ago[deleted]
- troupo 3y agoAh. I see what you mean. I think this is the issue with the language and/or tooling. Most languages will not let you import a function from two different libraries under the same name, and most languages will warn you if you use a function with the wrong arity. > methods and traits with a strong type system reduce any ambiguity there. Strong type system does not preclude pipes.
- thumbuddy 3y agoIn Julia, that's the name of the game. It's called multidispatch.