Some people say that technological progress will inevitably do away with religious and esoteric practices. Once science and technology are available to everyone, the idea goes, people will realize that the mechanics of the world are not dictated by invisible causes and abandon their magical beliefs. Beliefs that would be long gone when the age of computers arrive. And yet, the presence of magic in the realm of programming is undeniable. Take, for example, a classic introductory book to programming such as Structure and Interpretation of Computer Programs. In its second paragraph, it says:
People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells. A computational process is indeed much like a sorcerer's idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, is is very real. It can perform intelectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory.
Programming as the craft of conjuring the spirits of the machine. Wizards, you say?
Cringiness aside, why and when does programming feel like magic?
To Victor, a fellow ruby dev, magic in programming is ambiguous, to say the least. "When I found Perl, it felt like magic" was how he described his first encounter with a scripting language. After working with low-level languages, Perl felt like he was "expressing much more than you could understand." He was amazed at how a Perl script could digest a huge chunk of badly formatted HTML: in just one line of code, he could open a file, filter the lines he needed, drop the buggy lines without failing, and process the rest.
Perl is a language that is famous for such "one-liners". The line `perl i.tiny -pe 's/(+̣)/ 1 + $1 /ge' file1 file2`, for instance, will increment all numbers in the given files. Like the wizard in the UNIX poster, such is the magic of scripting languages. But if Perl one-liners are powerful and compact, they are also quite unreadable, which is why some say Perl could be classified as an "esoteric language" - languages that are purposefully designed to be difficult to program with.
The power of scripting languages made his head start spinning, Victor told me, and he started to look at what else was out there. He looked into Python, read the book about it, but "didn't understand how it could be fun to write on it, and then I just closed the book". Fair enough Victor, we've all done that.
But then, there was this strange man in a web forum who built weird things with a language called Ruby. It looked like something worth exploring, so he started building a few experimental things with it. Nothing major, just a few small programs. Definitely nothing related to Rails. He avoided Rails for many years even when using Ruby professionally, but eventually started to work with it anyway. Ruby felt, well, interesting.
In the context of Ruby, though, Victor doesn't really like when people talk about magic. Victor even wrote a blog post saying rubyists should stop calling it magic.
I actually dislike the word magic when it is applied to Ruby… because inside the community, and when Rails was hyping outside the community, a lot of stuff that we do, and lot of not-so-common idioms - like Active Support ideas - had a reputation of being magic.
In his post, he lists the things he believes shouldn't be called magic: monkey-patching, metaprogramming, and also "what juniors don't know." Ouch.
Victor feels that the problem is that certain characteristics of the Ruby language and certain features of the Ruby on Rails framework were treated as the same thing and were called magical. To him, that's not right. On the one hand, Rails is in fact magical, Rails behaves in a way that is not intuitive. If you write "`def index; end` in `FooController`", Victor told me, it "magically knows to look for `app/views/foo/index.html.slim`, and make a response with proper headers and body, despite the fact that nothing in code the developer wrote implies it".
Rails magic allows you to build things quickly, but it doesn't invite you to explore further. The magic is hidden - it is, well, "under the hood", as the expression goes. If Perl programs are so dense and packed with tightly knit code to the point of being unreadable, Rails applications tend to be the opposite, with many lines of clear and expressive code. But, Rails magic is an illusion. It hides things behind an easy-to-use implementation that gives you the sense of performing magical tricks. Rails code is, in a sense, a composite of readable short phrases and small actions that are the visual opposite of Perl's code density.
While Perl will give you…
…Rails might reply with:
Perl's dense code and Rails' magic lightness are two quite opposite ways of expressing oneself as a programmer. For some rubyists, none of them are quite right. Like Goldilocks and the three bears, the taste of Perl might be too salty for some while Rails' syntactic sugar might indeed be too sweet.
You know there's a saying that very advanced technology is indistinguishable from magic. It's advanced technology, but you can deconstruct it and understand that and understand how it works. While magic, you only can read your rulebook and follow your own book, and you can’t do much more. You can’t understand, or investigate it more […] But in Ruby, I believe that it's vice-versa, it’s a lot of stuff, a lot of effort put into the language to say something so clear, so shortly, so briefly, so clearly, so expressively that it felt like something supernatural, but completely de-constructible, understandable, ownnable. That's why I love Ruby.
Ruby's magical blocks, methods, and scripts are the right measure. They are not too criptic, neither too explicit. They are not too dense nor too light. They are not too big nor too small. Not too salty, not too sweet. There are many types of magic in programming, but Ruby magic is just right.
:: post written by Gui Heurich - @anthrolanguage