Live data from Hacker News

Phoenix 1.3 is pure love for API development

swanros.com

41–50 of 57 posts

Re: Phoenix 1.3 is pure love for API development

#41
post #29

Earlier quoted context omitted.

Interesting. While Elixir syntax definitely requires writing more code, than for example Ruby which I use the most, I have not been struggling too much. Could you give some examples of these long, problematic snippets? Also, what are the other things you did not like about Elixir/Phoenix? I am really curious to hear about them since, here on HN they are mostly praised and I wonder myself what are the cons (my experie…

$ irb [1, 2, 3, 4]. select {|n| n % 2 == 0}. map {|n| n * n}. reduce {|sum, n| sum + n} # 20 vs $ iex [1, 2, 3, 4] \ |> Enum.filter(fn(n) -> rem(n, 2) == 0 end) \ |> Enum.map(fn(n) -> n * n end) \ |> Enum.reduce(0, fn(n, sum) -> sum + n end) That Ruby code is so compact that I split it on multiple lines only to make the comparison easier. Even Python is more compact even if it's harder to read because of the reverse…

I mean, if you want something really compact, why not APL?

      +/{(0=2|⍵)×⍵*2}⍳4
20

Edit: My point here, besides simply the joy of trolling, is that "compactness" isn't a great metric for analyzing a programming language, or a framework even. My APL example isn't very compact for APL, yet it's certainly /way/ more compact than the Python, Elixir, or Ruby versions.

Still, it's hardly comprehensible to me as a beginner APL programmer -- and I wrote it, just now. It's probably /completely/ incomprehensible to anyone who hasn't written APL before. Is APL still "better", going only by compactness?

Re: Phoenix 1.3 is pure love for API development

#42
post #35
post #29

Earlier quoted context omitted.

$ irb [1, 2, 3, 4]. select {|n| n % 2 == 0}. map {|n| n * n}. reduce {|sum, n| sum + n} # 20 vs $ iex [1, 2, 3, 4] \ |> Enum.filter(fn(n) -> rem(n, 2) == 0 end) \ |> Enum.map(fn(n) -> n * n end) \ |> Enum.reduce(0, fn(n, sum) -> sum + n end) That Ruby code is so compact that I split it on multiple lines only to make the comparison easier. Even Python is more compact even if it's harder to read because of the reverse…

I know you want to show it as parallel as possible, but: "pythonic" python (sum admittedly is a shortcut that only works for the special case +): sum(x * x for x in [1,2,3,4] if x % 2 == 0)

I was going to comment along these lines - while functools exists, where appropriate I'd say iterators and/or list comprehensions are more pythonic. Note that if one wants to work with simple reduce functions, there's the operator module to help:

  from functools import reduce
  from operator import add

  # I'd also say this makes for more readable code,
  # documenting intent - but many will probably say that
  # basic arithmetic should be clear enough:

  def is_even(n): return n % 2 == 0
  def square(n): return n*n

  # Don't do this for summing integers, just use "sum":
  reduce(add,
    (square(n) for n in
      range(1,5) if is_even(n)))
  > 20
Note the use of range() rather than literal list - if you have a list, that should probably be passed in by name.

Anyway, the point wasn't so much bikeshedding or code golfing - just expanding on what I think is "more pythonic" take on it.

And to be clear, I'd probably prefer:

  sum(x * x for x in range(1,5) if x % 2 == 0)
for this particular example. And for more complex "real world" cases, I'd probably prefer to define my "reduce" function directly ie:

  def my_sum(iterator): return reduce(add, iterator)
  int_sequence = range(1,5)

  my_sum(square(n)
    for n in int_sequence
      if is_even(n))
  > 20
Note that python has map and filter as built-ins, so it's also possible to do:

  sum(map(lambda x:x*x,filter(lambda n:n%2==0,range(1,5))))
  # Which I find rather unreadable, but gets a bit better
  # without lambdas:
  sum(map(square, filter(is_even,int_sequence)))

(Phew, please excuse my personal dive into new/old list-comprehension/functional python -- but at least now I'm more clear on why everyone keep adding "threading" macros/syntax to their functional languages :-)

[ed: And if one wants threading-like syntax along with some parallelization and lazy-ness in python, there's a module for that: https://github.com/EntilZha/PyFunctional

  from functional import seq
  (seq(range(1,5))
    .map(square)
    .filter(is_even)
    .reduce(add)
  )
Just FYI.]

Re: Phoenix 1.3 is pure love for API development

#43
post #29

Earlier quoted context omitted.

$ irb [1, 2, 3, 4]. select {|n| n % 2 == 0}. map {|n| n * n}. reduce {|sum, n| sum + n} # 20 vs $ iex [1, 2, 3, 4] \ |> Enum.filter(fn(n) -> rem(n, 2) == 0 end) \ |> Enum.map(fn(n) -> n * n end) \ |> Enum.reduce(0, fn(n, sum) -> sum + n end) That Ruby code is so compact that I split it on multiple lines only to make the comparison easier. Even Python is more compact even if it's harder to read because of the reverse…

I mean, if you want something really compact, why not APL? +/{(0=2|⍵)×⍵*2}⍳4 20 Edit: My point here, besides simply the joy of trolling, is that "compactness" isn't a great metric for analyzing a programming language, or a framework even. My APL example isn't very compact for APL, yet it's certainly /way/ more compact than the Python, Elixir, or Ruby versions. Still, it's hardly comprehensible to me as a beginner APL…

The same in J:

    +/*~((0&=&(2&|))@:[#])(1+i.4)
    20
It's longer than APL version, but still cute! :)

Re: Phoenix 1.3 is pure love for API development

#44
post #35
post #29

Earlier quoted context omitted.

$ irb [1, 2, 3, 4]. select {|n| n % 2 == 0}. map {|n| n * n}. reduce {|sum, n| sum + n} # 20 vs $ iex [1, 2, 3, 4] \ |> Enum.filter(fn(n) -> rem(n, 2) == 0 end) \ |> Enum.map(fn(n) -> n * n end) \ |> Enum.reduce(0, fn(n, sum) -> sum + n end) That Ruby code is so compact that I split it on multiple lines only to make the comparison easier. Even Python is more compact even if it's harder to read because of the reverse…

I know you want to show it as parallel as possible, but: "pythonic" python (sum admittedly is a shortcut that only works for the special case +): sum(x * x for x in [1,2,3,4] if x % 2 == 0)

Right, and then in perl5:

    sum map $_**2, grep !($_ % 2), 1, 2, 3, 4
I find the python and perl versions more aesthetically pleasing than the ruby one, tbh.

Re: Phoenix 1.3 is pure love for API development

#45
post #2

I learned about it about 20 days ago and have spent every day since then absorbing, reading and learning. I LOVE this language / framework / OTP / methodology / community

I experienced the same. Once you start, it's hard to stop. An amazing community around this awesome language is hard to let go.

Re: Phoenix 1.3 is pure love for API development

#46
post #23
post #21

While action fallback sounds pretty useful, it feels like a framework solution to a language problem. The language just doesn't handle nested if statements very well. Also writing elixir always feels like the lines of code are longer than the width of my IDE. It is so much text... My Elixir (and phoenix) experience so far, has been far from amazing contrary to all the hype on hn all the time.

My first thought when I read this was that it sounds like you're struggling against the language because you're trying to use it in an imperative fashion. I'm well aware this may not be correct but it's what I'm going to assume for the rest of this comment, so please forgive me if it's incorrect. Elixir is a functional language, and while it's not pure, nested if statements deliberately do not belong. The if statemen…

Agreed, the fact that you're saying you can't nest if statements is a sign that you still don't get the grasp of functional programming.

cases, conds, with statements, recursion, pattern matching...

Re: Phoenix 1.3 is pure love for API development

#47
post #26
post #21

While action fallback sounds pretty useful, it feels like a framework solution to a language problem. The language just doesn't handle nested if statements very well. Also writing elixir always feels like the lines of code are longer than the width of my IDE. It is so much text... My Elixir (and phoenix) experience so far, has been far from amazing contrary to all the hype on hn all the time.

Elixir is essentially just erlang, with a more convenient syntax. Being a functional language, you shouldn't be doing nested if statements in the first place. The if statement in elixir is really just a case-switch macro. Also writing elixir always feels like the lines of code are longer than the width of my IDE This just seems weird to me. The pipe operator makes the code really compact in my experience, and I wish…

Coming from an imperative language background, it certainly took some time for me to start using and understanding functional constructs. But the nice thing is that once you pass that bump, it's a hell of a freeway to go down.

Re: Phoenix 1.3 is pure love for API development

#48
post #34

Can anyone point me to a decent fully contained example of a smallish app in Phoenix on something like github? I've spent a couple of hours reading some of the Elixir docs and getting familiar with some concepts, but I still have no idea how an Elixir app or a Phoenix app would actually look.

I have worked with Elixir quite a lot, and I think I have a fair idea of how the language works in general, and how OTP apps are structured. Even so, I find myself having the exact same issue as you are having when using Phoenix and Ecto. The way I like learning something new is by looking at something someone else has made. This gives me a much better view of how things are done than just reading getting-started gui…

Hi,

Take a look at the Building Umbrella Project from elxirconf: https://github.com/poteto/elixirconf-201620 by Wojtek Mach.

The source: https://github.com/wojtekmach/acme_bank22 is a great example of an umbrella app. For example, he uses two instances of phoenix (backoffice and bank_web). It's a working app, so you can experiment with it too.

The talk is here: https://www.youtube.com/watch?v=6NTmUQClHrU18 I found it very instructive.

Re: Phoenix 1.3 is pure love for API development

#49
post #18

Best part for me is the new fallback controller plug. Really well done. That and the centralized error list. This is one of the things which is miss in Go (I think this is the same in Rust, but I am not an expert).

Be careful: that is a framework, not a language feature.

Is a language useful without useful frameworks around it?

Re: Phoenix 1.3 is pure love for API development

#50

I love elixir and phoenix, I have started learning it around a month ago and it has been a eye opener, the only thing that I struggle are the error messages, sometimes I spend more time than I should try to understand where I made a typo, I am not sure if it's just me because I am so new to this technology or many ppl have the same problem.

Raise an issue.

José pays a lot of attention to providing great error feedback. And yeah, we've all had incomprehensible messages en route when learning elixir. Things aren't perfect, but they'll only get better when folk point out the shortcomings.

Post reply on HN