Hacker News new | ask | show | jobs
by yeetaway1111 1201 days ago
There was so much mystery and magic that I felt was happening behind all things generated in Phoenix that I just felt lost.
3 comments

That's interesting! When I started out I maybe felt the same but most of that was just not understanding it, and now to me it feels like one of the more explicit frameworks I've used, which I actually enjoy.

I could recommend reading http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoe... which was posted on HN as well some years ago.

It might feel like that way to start with when you're new to the framework, but if you spend a bit of time in it you'll find a lot less magic going on then you expect. I know where you're coming from however, I felt the same way when I started.
Is this in regard to 'mix phx' gen commands or something else ?
I guess he is talking about macros and perhaps the syntax which I also didn't like and is one of the reasons why I consider PHP better (even though the naming and parameters inconsistency could be better). Check for yourself:

``` iex> length([1, 2, 3]) == length [1, 2, 3] true ```

or (taken from the Elixir docs):

---

Take the following code:

``` if variable? do Call.this() else Call.that() end ```

Now let’s remove the conveniences one by one:

do-end blocks are equivalent to keywords:

`if variable?, do: Call.this(), else: Call.that()` Keyword lists as last argument do not require square brackets, but let’s add them:

`if variable?, [do: Call.this(), else: Call.that()]` Keyword lists are the same as lists of two-element tuples:

`if variable?, [{:do, Call.this()}, {:else, Call.that()}]` Finally, parentheses are optional, but let’s add them:

`if(variable?, [{:do, Call.this()}, {:else, Call.that()}])` That’s it! Those four rules outline the optional syntax available in Elixir. Those rules apply everywhere consistently, regardless of the construct you are invoking. Whenever you have any questions, this quick walk-through has you covered.

---

I don't like this possiblity to use so many syntaxes good, especially if you deal with mulitple parameters in functions. Elixir doesn't have C-like semicolons or braces like in Lisp so multiple parameters are hard to parse sometimes.

The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict and he mentions the optional () e.g. IO.puts "Hello" vs IO.puts("Hello").

> I don't like this possiblity to use so many syntaxes good

There other side of the coin is having specialized syntax for each construct. For example, PHP currently lists [56 keywords][0], and each keyword generally comes with their own grammar rules (I picked PHP because it was an example you mentioned above).

Elixir, on the other hand, has [15 keywords][1]. Defining modules, functions, conditionals, and so on, all use the same syntax rules. At the end, you end-up with less syntax because the whole language is built on the few affordances above. The other benefit is that developers can also extend the language consistently, since the constructs for designing and extending the language are the same.

> The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict

If I could go back in time, I would have made it strict since the beginning, but we have already made it strict over time through deprecation warnings in the last 7-8 years. Given a time machine, I'd probably not have changed the notes you mentioned above. :)

0: https://www.php.net/manual/en/reserved.keywords.php 1: https://hexdocs.pm/elixir/syntax-reference.html#reserved-wor...