Shameless plug: I just created a small library that allows to do: `4 |> & &1 * 2` and similar. You might find it occasionally useful in a local iex session but for the good reasons mentioned in this thread please don't use it in production code :)
https://github.com/wojtekmach/pipe_capture W dniu piątek, 12 maja 2017 22:30:16 UTC+2 użytkownik Josh Bourgeois napisał: > > +1. I do have to say, though, I'll be far more likely to implement the > refactor based on Rich's implementation. > One might be able to refactor it even farther, simply to "easy is hard", > but then it may lose some nuance and portability. > > > > I really like the constructs Elixir uses to encourage code simplicity. > Pattern matching and guard signatures allow functions to take on a level of > granularity where you legitimately can write functions that perform > *exactly* one action, *exactly* the same way with the same inputs. What > emerges is a coding style where, as a general rule, you can say that if > your Elixir function needs to set a variable, it can be refactored to a > simpler function body. > > My rationale for suggesting the pinpipe operator was because, within some > function bodies, the only reason you might consider introducing a variable > is so that your transformed data can be used in a specific position of your > function result. The code example of def boundary at the start of this > thread, for instance, is a self-contained, pure function as it is. The > anonymous function called at the end does not need to exist, as the SHA > sent in could just as easily be a variable: > > def boundary do > sha = :crypto.rand_bytes(8) > |> Base.encode(16) > "---------FormDataBoundary" <> sha > end > > DRY principles (at least, as far as The Rails Way was taught to me) would > say that if there were no other way you would want a > "---------FormDataBoundary" to be generated, then you would want to keep > this method body self-contained, and with as few introduced variables as > necessary. Pipe workflows keep that intent in focus by dissuading you from > making functions that work on anything but their inputs. When I'm in that > mindset, variables set within a function are an anti-pattern, but I would > still sooner catch myself moving the pipes to the place where they were > necessary: > > def boundary do > "--------FormDataBoundary" <> (:crypto.rand_bytes(8) > |> Base.encode(16)) > end # sha, you know what? uh-uh. > > Coming back to being able to overload signatures as you can in Elixir, > after half a decade of not being able to in Ruby and Javascript, the above > is still far more natural to me (even though I know inside how kludgey it > feels) compared to something like: > > def boundary, do: :crypto.rand_bytes(8) |> Base.encode(16) |> boundary > defp boundary(sha), do: "--------FormDataBoundary" <> sha > > But almost all of my hesitation around a convention like this comes from > not being used to it. Portable, reusable functions are very good things to > have central to a language design, and if Elixir has A Right Way to > implement those, it's within the maintainers' rights to foster that happy > path and discourage what would be impure solutions according to the > language philosophy. As the community grows and more code examples become > available, fewer people will wonder about how they should do these things. > > On Wednesday, May 10, 2017 at 5:39:53 AM UTC-7, Onorio Catenacci wrote: >> >> That's a great point Robert and Mr. Dijkstra certainly deserves credit. >> Thanks for reminding me about that. >> >> On Tue, May 9, 2017 at 5:44 PM, Robert Virding <[email protected]> wrote: >> >>> Actually this was said by Dijkstra long before Rich: >>> >>> “Simplicity is a great virtue but it requires hard work to achieve it >>> and education to appreciate it. And to make matters worse: complexity sells >>> better.” >>> Unfortunately all 3 points are true. He also said: >>> >>> “Simplicity is prerequisite for reliability.” >>> >>> which is also true. >>> >>> On Tuesday, 9 May 2017 14:11:46 UTC+2, Onorio Catenacci wrote: >>>> >>>> To paraphrase Rich Hickey--"Simplicity isn't easy". Figuring out those >>>> simple function signatures is not the first thing that comes to mind for >>>> most of us. But it's worth the effort. >>>> >>>> >>>> On Saturday, May 6, 2017 at 7:14:45 PM UTC-4, Josh Bourgeois wrote: >>>>> >>>>> I thought of practicing, but then I just wound up doing a lot of >>>>> thinking. Then it clicked 😬 >>>>> >>>>> defmodule Words do >>>>> def count("" <> string), do: parse(string) |> Enum.reduce(%{}, >>>>> &count/2) >>>>> >>>>> defp count("", map), do: map >>>>> defp count("" <> word, map) do >>>>> word |> String.replace("_", "-") >>>>> |> increment(map) >>>>> end >>>>> >>>>> defp increment(word, map), do: put_in(map[word], (map[word] || 0) + >>>>> 1) >>>>> defp parse(string), do: string |> String.downcase |> >>>>> String.replace("-", "&hyph;") |> String.replace("_", "-") |> >>>>> String.replace("&hyph;", "_") |> String.split(~r/\W/u) >>>>> end >>>>> >>>>> It's just a challenge to think of meaningful names sometimes. Breaking >>>>> function/method bodies into smaller discrete blocks of work is obviously >>>>> a >>>>> fundament to making code more readable, but it takes discipline and, >>>>> sometimes, a thesaurus >>>>> >>>>> Thank you for entertaining this zombie discussion once more 😶 >>>>>> >>>>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "elixir-lang-core" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/elixir-lang-core/dwbNOh_yNd4/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/59c6d90d-ded2-4794-8a73-920ab9350007%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/59c6d90d-ded2-4794-8a73-920ab9350007%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Onorio Catenacci >> >> http://onor.io >> http://www.google.com/+OnorioCatenacci >> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/7a387850-b055-4386-ac1c-7f09cc54a940%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
