The Ruby vs. Python Meetup
The holy war
However, I was always interested in why this happens. Why do many users prefer implementing other technologies rather than Ruby? This way, I was excited to accept the invitation to the Ruby vs. Python meetup that was sponsored by Altoros. During the meetup, I spoke on the topic “Why Ruby Is a Brilliantly Designed Language,” defining how the language differs from other technologies.
The Ruby vs. Python meetup
The event was very dynamic and intriguing. The speakers and attendees were split into two groups: one defended Python, while the other fought for Ruby. Each group prepared presentations describing the history, the communities behind, main concepts, development features, and perspectives of their language of choice.
I was part of the group presenting Ruby, appearing in public for the first time in many years. The last time I spoke publically was on the completion of the bachelor’s degree at university, which was not a big success. With some lessons learned, this time was not so bad for me.
Why is Ruby a brilliantly designed language?
In hindsight, it is obvious that I picked a very hard topic. Squeezing all my experience into a 15-minute speech was a challenge. While preparing for the session, I reinforced the belief that Ruby is the best-designed programming language ever used. However, when it was just one day left before the meetup, I realized that I could bring in only the most essential arguments to prove the idea.
- From the moment the language was created, there were no missing features to add and no design bugs to fix. With over 10 years of its history, Ruby remained mostly stable with only minor syntactic features added/tweaked.
- Ruby represents all-powerful object-oriented programming (OOP) features, which were adopted from Smalltalk. It is a pure OOP language, where everything is an object. The pureness, open classes, the
method_missingmethod, and other OOP features provide for huge semantic power. Surprisingly, nothing game-changing was introduced to the programming language design over the last 30 years.
- Another argument covered powerful features Ruby adds on top of the traditional form of OOP. For instance, mix-ins, a powerful alternative to multiple inheritance is a great invention. During the presentation, I demonstrated how it makes functional programming even more natural than in LISP. Another remarkable Ruby feature worth mentioning was the ability to extend individual objects. It makes defining static methods natural and can be useful in some other cases.
- The conclusion touched upon Ruby’s concise syntax. As part of this argument, I demonstrated the syntactical killer feature—Ruby blocks.
Revealed pros and cons
There were some other nice discussions between the presentations. For example, the Python group argued that its language is more widely used. However, I noted that one could resort to such an argument only due to the lack of other worthy pro-language arguments.
Another controversial point was that Python is good for education and is adopted by Massachusetts Institute of Technology as the primary programming language for students. I objected that Python is not the best language to start with. It is advised to begin developing your programming skills with a pure OOP language, such as Ruby, because it can build a better solid ground for object-oriented design and way of thinking.
The discussion ended up with the confessions from both sides about the disadvantages in their languages of choice. Python 2.6/3 incompatibility was the biggest issue that Pythonistas admitted. Ruby developers noted the lack of speed, the lack of support for real concurrency, and the cumbersome support of multiple encodings in Ruby 1.9. The first two negative points were well understood by Pythonistas, since they also experienced such issues. Ruby’s incompatibility of 1.9 vs. 1.8 was also mentioned, although nobody said that the difference between these versions is far less than the difference between Python 2.6 and Python 3.
I really enjoyed attending the event and delivering the presentation. However, it seems like everyone—including our team—forgot to mention that all of us do hard work that involves attention to detail, which mostly contributes to an end result. As long as the technology does not actively interfere with the programmer’s job, it affects the end result very slightly. The language is merely the tool, while the developer is the master.
- RubyGardens Graduation: Our Ruby Team Welcomes New Engineers
- The Ruby Community Is Blooming: 100+ Experts Attended a Local User Group
- A Gaming Bots Constest at a RoR Meetup