That's definitely fair to say, Ben, though I will have to say that as far as other functional languages go, Elixir *looks* pretty imperative. :)
On Friday, September 30, 2016 at 5:35:16 PM UTC-4, Ben Wilson wrote: > > When I think of imperative programming I think of programs with lots of > statements that mutate state. When I think of functional programming I > think of programs which model computation as inputs and outputs. > > Elixir does have some impurity, but it has no statements, and pure > functions constitute an enormous portion of what you write. I'm not sure > "imperative functional language" is a thing. > > This however is diverging heavily from the original topic. > > On Friday, September 30, 2016 at 10:21:01 AM UTC-4, Eric Entin wrote: >> >> I think that unit tests such as they exist in Elixir, which is an >> imperative functional language, IMO, are inherently imperative. Property >> tests would be a nice example of a more declarative testing style. >> >> On Friday, September 30, 2016 at 1:01:30 AM UTC-4, Jaap Frolich wrote: >>> >>> Thanks, >>> >>> It seems that opinions differ about the incremental improvement of >>> putting this in. After thinking about it I also think it is probably better >>> to keep it simple in the core language, and no reason for it not to be a >>> library for functional programming aficionados, and syntax nitpicks :). If >>> you do not worry how your code looks indeed the same can be accomplished >>> using: >>> >>> |> Kernel.==(expected_result) >>> |> assert >>> >>> >>> with match? we have to create a function to swap the arguments, and you >>> can do the same. >>> >>> I published it as assert_functional ( >>> https://hex.pm/packages/assert_functional), and I used it in the tests >>> of another package (if you are interested how to apply it) if_ok ( >>> https://hex.pm/packages/if_ok). >>> >>> Thanks for your feedback. Always interesting to build up a body of >>> knowledge about how the community thinks about a particular subject. >>> >>> @eric: Why do you think they are both imperative, and how would you make >>> them more declarative? Very interested! >>> >>> Cheers, >>> >>> Jaap >>> >>> >>> On Friday, September 30, 2016 at 1:51:14 AM UTC+8, Ben Wilson wrote: >>>> >>>> I also disagree that it's more declarative. >>>> >>>> In the standard ExUnit case, you have some setup code, and then the >>>> assertion is a clear and easily distinct line. It's clear what is the >>>> pattern, and what its being matched against. >>>> >>>> both = and the existing match? function take the pattern on the LHS so >>>> assert_match in particular is a bit odd because it's now on the RHS. >>>> >>>> On Thursday, September 29, 2016 at 12:39:47 PM UTC-4, Eric Entin wrote: >>>>> >>>>> I disagree that the latter is more declarative than the former. They >>>>> are just two different ways of writing the same thing. In fact, they're >>>>> both fairly imperative. :) >>>>> >>>>> Pipes are awesome, but IMO they are a tool for convenience, and not >>>>> the only way that clean, idiomatic Elixir code can be structured. I think >>>>> the number of asserts that you will eventually have to implement here is >>>>> another good argument against this, as people reading your code will now >>>>> have to know both the standard Elixir operators as well as the names of >>>>> the >>>>> special matchers you create. >>>>> >>>>> I can definitely see your reasons for wanting this, so I think a >>>>> library would be welcome, but I'm not in support of this being added to >>>>> core at this time. >>>>> >>>>> On Thursday, September 29, 2016 at 6:23:45 AM UTC-4, Jaap Frolich >>>>> wrote: >>>>>> >>>>>> Probably you have run into this: if you have slightly more complex >>>>>> tests than testing the output of a single function, you need assignment >>>>>> and >>>>>> then assert that assignment with an operator. Consider this controller >>>>>> test >>>>>> in phoenix: >>>>>> >>>>>> conn = >>>>>> build_conn() >>>>>> |> post("/upload_content_cover", params) >>>>>> >>>>>> >>>>>> assert %{"success" => true} = json_response(conn, 200) >>>>>> >>>>>> >>>>>> with an `assert_match` function this translates to the following: >>>>>> >>>>>> build_conn() >>>>>> |> post("/upload_content_cover", params) >>>>>> |> json_response(conn, 200) >>>>>> |> assert_match(%{"success" => true}) >>>>>> >>>>>> >>>>>> I prefer the latter, because it is more declarative. >>>>>> >>>>>> My issue with using operators in assertions, is that while improving >>>>>> readability in some cases, they are not very functional constructs, and >>>>>> thus do not compose well. Having a functional equivalent for the >>>>>> assertions, makes sense in a functional language in my opinion. >>>>>> >>>>>> I can also see why this should be a library, keeping the assertion >>>>>> library less complex. Just would like to share my thinking. I'm also >>>>>> interested in feedback, and how I might be wrong :). >>>>>> >>>>>> See the following pull request for an implementation: >>>>>> https://github.com/elixir-lang/elixir/pull/5259. >>>>>> >>>>> -- 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/eae4dad8-973c-48fd-a51c-75a958e46cd6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
