VOL 2: Syntactic Sugar, Sharp Knives, and Ruby Magic
So far in my journey learning to code, Ruby on Rails has been my favorite language to dive into. Ruby on Rails is an incredibly powerful and flexible open-source programming language. As someone that loves structure, I love RoR because the documentation is so comprehensive and the language itself is pretty straightforward and human-friendly. Unlike Java Script, which I’ve found to have a lot more of a learning curve because it’s more of an “anything goes” language. The wild west of code. But not Ruby. It’s such a powerful language because in a matter of hours, you can go from a blank slate to a fully functioning multi-page application complete with login and logout capability, multiple models, and routes. It’s pretty crazy when you think about it.
In fact, many of the websites you use on a daily basis are actually powered by Rails. AirBnb, Shopify, Twitter, Kickstarter, Hulu, Github, just to name a few. As you can tell this language is most popular with companies with a social media aspect to them. Sometimes Rails get’s a bad rap for being “slow”, but honestly I think it’s more about you as the developer choosing the right tool for the job. There are definitely situations where Rails is not the right language for the job, but you could make that argument about Java Script, Python, Django, or any other programming language. They each have their own sets of strengths and weaknesses.
One of the things that most intrigued me about Rails was how I kept coming across the phrase, “Ruby magic”. I would see this phrase on StackOverflow or on forums when debugging an issue with my code. And I never quite understood what everyone was talking about. But the phrase intrigued me and made me very curious about the language’s origins. After spending the last few months really digging in and mastering the language, I get it now. And let me tell you, Ruby is magic.
What is Ruby Magic?
So to answer this question, let me give you a brief overview of the history and inception of the language. Ruby was designed and created by a Japanese computer scientist name Yukihiro Matsumoto, aka “Matz” in 1995.
His demeanor has brought about a motto in the Ruby community: “Matz is nice and so we are nice,” commonly abbreviated as MINASWAN.
Then, in 2004, along came a Danish programmer by the name of David Heinemeier Hansson. At the time, Hansson was actually working on building a project management tool with another developer which later became Basecamp. During the development of this tool, Hansson used Ruby to create a custom web development framework which he later released as the open-source language Ruby on Rails, and thus Rails was born- a happy accident. Reading the Rails doctrine is a very different experience from reading the documentation for other other languages. Hansson doctrine is full of expressive, even religious language declaring the guiding principles behind this language.
The 9 Pillars of The Rails Doctrine
- Optimize for programmer happiness
- Convention over Configuration
- The menu is omakase
- No one paradigm
- Exalt beautiful code
- Provide sharp knives
- Value integrated systems
- Progress over stability
- Push up a big tent
We won’t go into too much detail on each pillar, but I’ll hit the highlights. Rails was designed to be fun, a novel concept in programming at the time.
Hansson says, “Ruby took to not only recognize but accommodate and elevate programmer feelings. Whether they be of inadequacy, whimsy, or joy. Matz jumped implementational hurdles of astounding complexity to make the machine appear to smile at and flatter its human co-conspirator. Ruby is full of optical illusions where that which seems simple, clear, and beautiful to our mind’s eye actually is an acrobatic mess of wires under the hood.”
This is about the best summary of Rails I’ve read. These “optical illusions” are where the phrase Ruby magic comes from.
To be more specific, what he means by “optical illusions”, are really just simple and thoughtful bits of code that make your application a lot more elegant and intuitive. Let me give you can example. Rails follows the principle of convention over configuration. This isn’t just a stylistic decision. Convention over configuration means that in Rails, your app and its files and folders follow a specific naming and organizational convention. The reason for this is that there is so much going on under the hood. In order for your models, views, and controllers, to all work together as they should, they must be named appropriately for the magic to work. The conventions you follow are signaling to Rails what you want your app to do.
Like anything, this type of language definitely comes with its downsides. For one, when there is so much “rails magic” happening behind the scenes, things can get pretty abstract fast. You as the programmer have to have an in depth knowledge of what is actually going on. For this reason, Rails can be hard debug. Secondly, if you’re looking at someone else’s Rails code, it can a little unclear what that person intended that method or view to accomplish. How you name your methods, controllers, views, and routes is super critical when building Rails apps.
Syntactic Sugar
Enter syntactic sugar. This is one of those terms in programming that I thought was cute and nice but didn’t know what it meant. Syntactic sugar, as it turns out, is hugely helpful in the world of Rails, (and pretty much all programming languages.) All it really is, is some extra syntax sprinkled throughout your code to make your code “sweeter” and more human-readable. I’ll give you a very basic example. Let’s say you have the following line of code: x = x + 5
If you want to add 5 to the variable x, the ‘sweeter’ version of this code would be to just write x += 5.
Neat, huh?
The ternary operator is one of the more common and widely used examples of sugary syntax. Here’s how to use a ternary:
if apple_stock > 1:eat_appleelse:buy_appleend
These 5 lines of code can actually be expressed as just one:
apple_stock > 1 ? :eat_apple : :buy_appleWow!
The reason it’s referred to as “syntactic sugar” is because while it doesn’t directly effect the functionality of your code, it is much more aesthetically pleasing for other developers to read and understand. Additionally, the bigger and more complex your app becomes, the longer and longer your code can get. So these little shortcuts are the perfect tool to ensure your code is clean, concise, and sweet!
