Is there an actual reason for shortening everything to "phx"? I would guess the same rules as naming variables would apply here.
Phoenix 1.3 is pure love for API development
51–57 of 57 posts
Re: Phoenix 1.3 is pure love for API development
#52Earlier quoted context omitted.
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…
FYI, your links all have numbers appended to them. The working links seem to be:
https://github.com/poteto/elixirconf-2016
Re: Phoenix 1.3 is pure love for API development
#53Re: Phoenix 1.3 is pure love for API development
#54Earlier 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)
You can omit == 0 in Python because 0 is falsy like in C and add a not after the if. That gains another character
sum(x * x for x in [1,2,3,4] if not x % 2)
[1,2,3,4].map{|x| x.even? ? x * x : 0}.sum
So the pythonic way is be
reduce_function(map_function(x) for x in input if filter_condition)
Re: Phoenix 1.3 is pure love for API development
#55Earlier 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…
Why not `import Enum` to get rid of the redundant `Enum.` part? As imports are lexically scoped there is no need to worry about name clashes (e.g. Enum vs. Stream): import Enum [1, 2, 3, 4] |> filter(fn(n) -> rem(n, 2) == 0 end) |> map(fn(n) -> n * n end) |> reduce(0, fn(n, sum) -> sum + n end) While we're at it, why not use a `&` operator to shorten the lambdas: import Enum [1, 2, 3, 4] |> filter( &(rem(&1, 2) == 0)…
Yeah, you have a point with the separation between client and server process. I guess the client must crash nearly every time. Still... I can't help feeling that there is something to improve in the syntax, to make it clear the context those functions run in.
Re: Phoenix 1.3 is pure love for API development
#56While 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.
> The language just doesn't handle nested if statements very well
One of the advantages of this language I've found is that I specifically DO NOT need to nest "if" statements anymore! Hie thee to pattern-matching and private functions that take different states (which are normally handled by nested ifs).
Also, nested ifs are REALLY hard to test well, and breaking them out into separate functions with the same name but different clauses makes it MUCH easier to unit-test.
Re: Phoenix 1.3 is pure love for API development
#57Earlier quoted context omitted.
Be careful: that is a framework, not a language feature.
Is a language useful without useful frameworks around it?
I believe at least most of those lisp dialects are useful without any frameworks. You get view template with s-expr for free instead of erb/ejs/eex. And you are basically composing everything like plug in elixir very easily.
However, the down side of not having a major framework is community does not have same context to discuss and share, which keeps almost every lisp dialect remains out of mainstream.