4 ms·

I was with until your unnecessary last comment, but I'll respond anyway. Macros are a pretty important feature of Elixir that helped get it wider adoption. Wi

I was with until your unnecessary last comment, but I'll respond anyway. Macros are a pretty important feature of Elixir that helped get it wider adoption. Without them, things become incredibly verbose. While I totally agree they can be hard to grok, there is absolutely nothing magical about them as they are expanded at compile-time. You can call `Macro.expand` on any AST and see the static code it generates. Otherwise, with a good, well-documented framework like Phoenix, the majority of users should be able to just use it as-is without needing to show off their intelligence by diving into the underlying implementation ;) <3 PS, I've never had a problem when there's an error in a macro. The line in my app that failed is always in the stack-trace which is all I ever need to debug (though I do wish is drew my eye to it somehow).

spapas82 4y ago
I know about the verbosity, Erlang is notorious for that. I'd still prefer it over macros. Java is also very verbose, that wasn't a problem with it's adoption :) Unfortunately for phoenix, when I started learning it I needed to rely on source code to understand some stuff. Trying to walk around the macro stuff was not a cool experience. Also I did have some macro related errors most related to ecto and its syntax. See this article to understand the problem https://www.spapas.net/2019/07/25/declarative-ecto-query-filters/ https://www.spapas.net/2019/07/25/declarative-ecto-query-fil... Ecto has its own, undocumented syntax. If people from the elixir irc (including the always helpful Jose Valim) wouldn't help me I'd be never be able to guess that thingie...
- josevalim 4y ago
  Quick feedback: 1. The blog post is great and it shows there is indeed complexity around dynamic filters. I would love to see a solution that tackles it all the way down to form rendering :) 2. All of the Ecto API/syntax used in the blog post is documented, afaik. 3. You mentioned in another comment that Ecto does not support associations in queries, but it does: `join: c in assoc(p, :comments)` and that takes care of the ON condition and anything else you configure.
  - spapas82 4y ago
    Thank you for your kind words Jose, going all the way to the form (and table/list) rendering is the ideal for me and would greatly improve my phoenix experience! Was that syntax documented 3 years ago? I don't really remember but definitely even if it was I couldn't find it. Also you should agree that it's non intuitive. Finally, you are right about assoc, I don't use it because I prefer the left_join/on syntax but that's not a correct argument .

spapas82 4y ago

I know about the verbosity, Erlang is notorious for that. I'd still prefer it over macros. Java is also very verbose, that wasn't a problem with it's adoption :) Unfortunately for phoenix, when I started learning it I needed to rely on source code to understand some stuff. Trying to walk around the macro stuff was not a cool experience. Also I did have some macro related errors most related to ecto and its syntax. See this article to understand the problem https://www.spapas.net/2019/07/25/declarative-ecto-query-filters/ https://www.spapas.net/2019/07/25/declarative-ecto-query-fil... Ecto has its own, undocumented syntax. If people from the elixir irc (including the always helpful Jose Valim) wouldn't help me I'd be never be able to guess that thingie...

josevalim 4y ago
Quick feedback: 1. The blog post is great and it shows there is indeed complexity around dynamic filters. I would love to see a solution that tackles it all the way down to form rendering :) 2. All of the Ecto API/syntax used in the blog post is documented, afaik. 3. You mentioned in another comment that Ecto does not support associations in queries, but it does: `join: c in assoc(p, :comments)` and that takes care of the ON condition and anything else you configure.
- spapas82 4y ago
  Thank you for your kind words Jose, going all the way to the form (and table/list) rendering is the ideal for me and would greatly improve my phoenix experience! Was that syntax documented 3 years ago? I don't really remember but definitely even if it was I couldn't find it. Also you should agree that it's non intuitive. Finally, you are right about assoc, I don't use it because I prefer the left_join/on syntax but that's not a correct argument .