3 ms·

I love Elixir (former Ruby dev) but I do find many Ruby devs will turn to macros when regular functions will do. I haven't tried LiveView but it looks very int

I love Elixir (former Ruby dev) but I do find many Ruby devs will turn to macros when regular functions will do. I haven't tried LiveView but it looks very interesting.

jolux 6y ago
In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand as a result. Here's __using__ in Phoenix.LiveView: https://github.com/phoenixframework/phoenix_live_view/blob/v0.15.3/lib/phoenix_live_view.ex#L459 https://github.com/phoenixframework/phoenix_live_view/blob/v... I think LiveView is a very compelling technology and I'm not sure we would have it if Elixir didn't exist, because Elixir brought a whole raft of different perspectives into the Erlang community. Erlang and Elixir are about as close as two languages can get, and I find complaints from either camp about the other silly. It reminds me of Python vs Ruby flame wars. Maybe it's just because I'm used to C# and F# and the way they feel in the .NET world, but Elixir and Erlang both feel like different syntaxes over the exact same underlying language concepts.
- kazinator 6y ago
  > While emacs has parts written in C, that portion really exists to enable elisp. You might not have noticed that the parts of GNU Emacs written in C exceed 250,000 lines of code.
  - jolux 6y ago
    You may be responding to the wrong comment.
- vendiddy 6y ago
  I agree that Elixir macros are far easier to understand than Ruby macros since they are defined at compile time rather than runtime. But I am against reaching for macros when the same can be accomplished using the basics: modules, functions, structs. I've seen various instances where a macro doesn't add much expressiveness over the plain old functional approach. Granted there are many areas where macros are very powerful. Ecto is a perfect example of when macros make sense. Adds a lot of expressiveness to build queries which is worth the cost of macros. Also should note that I love Elixir. We are using it in production to power all of our backend systems :)
pmontra 6y ago
To add a data point: Ruby and Elixir developer here (and Python and JS). I never wrote a macro in Elixir. All that weird quote / unquote stuff is too complicated. I get the idea (code running at compile time) but the syntax is just unwelcoming. Furthermore macros tend to make code opaque and onboarding difficult. I could wake in terror if I dream of my coworkers implementing some new functionality by adding macros instead of functions.
- 1_player 6y ago
  Agreed. My approach is to use macros written by someone smarter than me (Ecto), but refrain from writing macros myself. Regular functions very often are enough. Macros are definitely abused, but there are some cases, fewer than you think, where they make code easier to follow.

I love Elixir (former Ruby dev) but I do find many Ruby devs will turn to macros when regular functions will do. I haven't tried LiveView but it looks very interesting.

jolux 6y ago

In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand as a result. Here's __using__ in Phoenix.LiveView: https://github.com/phoenixframework/phoenix_live_view/blob/v0.15.3/lib/phoenix_live_view.ex#L459 https://github.com/phoenixframework/phoenix_live_view/blob/v... I think LiveView is a very compelling technology and I'm not sure we would have it if Elixir didn't exist, because Elixir brought a whole raft of different perspectives into the Erlang community. Erlang and Elixir are about as close as two languages can get, and I find complaints from either camp about the other silly. It reminds me of Python vs Ruby flame wars. Maybe it's just because I'm used to C# and F# and the way they feel in the .NET world, but Elixir and Erlang both feel like different syntaxes over the exact same underlying language concepts.

kazinator 6y ago
> While emacs has parts written in C, that portion really exists to enable elisp. You might not have noticed that the parts of GNU Emacs written in C exceed 250,000 lines of code.
- jolux 6y ago
  You may be responding to the wrong comment.
vendiddy 6y ago
I agree that Elixir macros are far easier to understand than Ruby macros since they are defined at compile time rather than runtime. But I am against reaching for macros when the same can be accomplished using the basics: modules, functions, structs. I've seen various instances where a macro doesn't add much expressiveness over the plain old functional approach. Granted there are many areas where macros are very powerful. Ecto is a perfect example of when macros make sense. Adds a lot of expressiveness to build queries which is worth the cost of macros. Also should note that I love Elixir. We are using it in production to power all of our backend systems :)

pmontra 6y ago

To add a data point: Ruby and Elixir developer here (and Python and JS). I never wrote a macro in Elixir. All that weird quote / unquote stuff is too complicated. I get the idea (code running at compile time) but the syntax is just unwelcoming. Furthermore macros tend to make code opaque and onboarding difficult. I could wake in terror if I dream of my coworkers implementing some new functionality by adding macros instead of functions.

1_player 6y ago
Agreed. My approach is to use macros written by someone smarter than me (Ecto), but refrain from writing macros myself. Regular functions very often are enough. Macros are definitely abused, but there are some cases, fewer than you think, where they make code easier to follow.