While I certainly understand the sentiment, I wasn’t referring to it for learning how to write macros but to underline that “macros that generate code during compilation” are of central importance in Elixir - and people coming from languages where that capability isn’t a core feature need to be made aware of it as soon as possible.

In my mind some macros express code that “hangs in the sky in much the same way that bricks don’t” - as a result from a novice’s point of view it isn’t at all clear how that code can have any run-time effect and/or how the code connects to the “rest-of-the-world” until they are made fully aware of Elixir’s meta-programming facilities (I’m surprised this hasn’t made it into Elixir’s biggest gotchas).

One good example is the plug router:

defmodule MyRouter do
  use Plug.Router

  plug :match
  plug :dispatch

One has no hope of understanding what is happening here until the realization comes that a whole bunch of code is “hydrated” here, in place, during compilation. The faster any novice realizes that the better. So while writing macros can wait, reading them and understanding their implications on the language as a whole cannot - at least in my opinion.

Hear hear, that is why I am a huge proponent of people learning a low-level assembler (old Motorola or so, not necessarily a nasty one like x86), as well as LISP. Both of those prepare you for both understanding how the CPU works and high level concepts (every high level concept if you learn LISP well).

I’m afraid I have been spoiled. I will not name by which language.
But Peer’s quote reminds me of Edsger Dijkstra:
“It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits. This circumstance makes the choice of first programming language so important.” (E.W.Dijkstra Archive: To the Budget Council (concerning Haskell))