Magic is exactly why I stayed away from Ruby. You have to learn some for every environment but Ruby was too much for me. Perhaps because I first saw it with RoR - which adds even more magic.

Both above and above one's parent comment is about rails, not about ruby. It's understandable that most people got familiarized with ruby because of the popularity of rails, but confusing between the two?

I've written Ruby, not Rails. In fact, most of my Ruby work hasn't had anything to do with the technologies associated with the web, they've been desktop GUI applications and server applications (like dealing with ActiveDirectory). I'm not confusing anything, I'm speaking from experience.

The Ruby community likes things that think for you, and insert methods unexpectedly, change the meaning of semantics, and all sorts of other magic designed to think for the programmer.

Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails and the gems related to it. But most Rubyists are such because of Rails so that's understandable. Examples of the magic like features of Rails are ActiveRecord's auto discovery of db schema and auto creation of queries, or callbacks on the changes of status of db records. It's where programming in Rails becomes somewhat declarative.

But macros? A language with macros I'm working with is Elixir. Even the seldom used if then else is a macro there. Do people dislike Elixir because macros change the code at compile time? I don't think so.

> Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails

Then what would you call the method_missing method?

> a b c

> = Name Error

> def method_missing(*args); args.join(" "); end

> a b c

> = "a b c"

That looks exactly like a macro to me.

---

> But macros?

Not macros as such, we all like having them. But Ruby likes using them constantly, and that culture is hardly restricted to Rails.

I see your point but Matz was clear about adding macros to Ruby:

> Macro is a great power, but at the same time, it makes the languagesyntax different for each application. You will have hard time to read the program without knowledge of the application/framework macros.

> So I am not going to add macro to Ruby.

> matz.

https://www.ruby-forum.com/topic/215212

The funny thing is that this is what happens when we use method_missing or other Ruby features to create DLSes: unless you know the application/framework DLS you can't understand the program. They must be used wisely.

But to be fair: how can one understand a program without the knowledge of the non standard libraries it uses? This applies to every program and language, macros or not.

Macros and meta-programming aren't necessarily the same.

Contrast with Lua: equally possible to do monkey-patching, but it's considered unclean and confusing to do it in Lua, at least among the community. Generally, there is a thing we could call the 'magic budget' and it's important not to blow it too quickly.

I think this quote from Metalua's frontpage, an extended Lua for better metaprogramming, sums up that feeling perfectly:

> Don't bother developers with macros when they aren't writing one: the language's syntax and semantics should be best suited for those 95% of the time when we aren't writing macros.

An extended language to add more magic, says we don't need it most of the time.

And to be honest, it's one of the things about the Lua community I find really attractive.

Does that scare off a lot of programmers from Lisp as well? It's interesting, because Elixir, Julia and Crystal, all newish languages, include macros.