Our dependence on technology is not a modern development, innovation has always been one of the ways we’ve expressed our abilities of higher cognition. Whether looking at elementary hunting tools, the complex mechanics of the Antikythera or any of our modern technological advancements —it becomes clear that as humans we’re willing to apply an extensive amount of energy into adapting our environment to better suit our desiderata.
What is a modern development —and now a heavily dependent upon technology, is the programmable electronic device. Once we realized it’s potential, and the wide array of applications we had for this innovation, we got to work with such extreme ferocity that in a matter of decades we have near completely woven these devices into every aspect of our contemporary life. They assist with our travels, our communication, our jobs and education, our health and safety, our leisure and finances —you name it.
Programmable electronic devices —computers, are able to perform sets of instructions, but defining these instructions in computer native language is difficult for us, so —as is in our nature, we got to work on coming up with programming languages that made it easier for us to express our intent.
Programming languages came into existence at the intersection of creativity and practical application, being a new innovation, there was limited guidance on matters of architecture and design, hardware and infrastructure constraints limited the scope and size of projects, and much of what was taking place was experimental. The explosion that went off over the next few decades (and is still in full swing) has left us all addled, computers have become more powerful and more can be done with them than ever before, networking has become ubiquitous with the advent of the Internet, and things are becoming increasingly smaller and more portable. New challenges keep rolling in, new patterns are discovered and others revised, and all this leaves an increasing amount of us in a mindset of experimentation.
Experimenting with programming is great, like playing music, or painting or solving a puzzle, we walk away from the experience with satisfaction and pride. It is oftentimes referred to as the Art of Programming, and we as Software Craftsmen —and it is this, and we are this, but the use of computers in carrying out vital tasks is on the rise, and an increasing number of processes are being automated. When this is what we’re working with, the task of programming should be approached as a discipline of engineering more than a craft or art.
A slip-up could unlock the doors of a client’s home, lead a courier into a dangerous neighborhood, injure an operator, malfunction when a loved one is in need of assistance or leak private information putting the lives of our kids in danger. To mitigate such risks our industry is in dire need of more disciplined programming practices and an overall better quality of code.
As you might have deduced from the title, I think Ruby —the programming language, has a lot to offer the programmer who is concerned about the quality of their code, which I feel should be every programmer (a term with which I encompass all individuals who are involved with code creation) today.
Please do not misunderstand me, in my saying that Ruby has a lot to offer I am not saying that other languages do not, nor am I saying that Ruby is in some way superior to any of the other amazing works being done in the field. What I am saying, is that all the energy that has gone into Ruby and the Ruby ecosystem has created value that is not immediately apparent to many programmers —and I’d like to highlight some of what I think matters.
What are the main qualities that make a certain expression of code good? In the context of mitigating the risks stated above, these would have to be:
- Code that is easy to digest and reason about —the intent must be clear so that there is no ambiguity for any developer tasked with working on it at a future time. Would you feel safe flying on a plane serviced by a mechanic who was only partly certain that he got it right?
- Code that is arranged to be expanded upon at a future time —things can get tangled up pretty quick as ad-hoc features get bolted on in creative ways, ideally, taking the time to restructure code is better for incorporating changes, but seldom possible in our capital driven society where deadlines loom. Code arranged with flexibility in mind is the best way we currently have of minimizing the time required in adapting to change.
- Code that is easy to test and easy to review —I have yet to meet a human who has not made mistakes, code that is easy to test and easy to review raises the possibility of catching issues that would have otherwise slipped through.
Now what is the contemporary programmer? Is it someone with an MSc on the subject, or an expert in some other domain who learnt how to code? Is it the high school dropout with an affinity for code, or the designer who scratched around in some and fell in love? Is it the hobbyist who decided to make a career of it, or the entrepreneur who decided to roll their sleeves up and get to it? Is it the physicist who has something to express, or the mathematician who switched fields? —The contemporary programmer is all of these amongst many other origin stories, all with different entry points, motivations and ambitions.
As contemporary programmers (newcomers and regulars alike) seeking to improve the quality of our code, what do we really need in an ecosystem?
- A programming language that does not get in the way —it is after all the concepts that we’d like to focus on.
- A strong supporting knowledge base on the subject —how does one go about familiarizing oneself with concepts without suitable subject matter.
- An adaptable ecosystem that keeps up with the times —we’re not interested in the stale and outdated.
I think the Ruby ecosystem fits the bill and I’m hard-pressed to find a better fit, let’s take a closer look at why..
This is not a post about Ruby’s history, so I am not going to delve into its past (look it up though, it’s interesting) —but instead focus on its present and future value. Some of you might already be familiar with the language and others might just be hearing of it now. It’s been a favorite of start-ups for over a decade, but has in recent years lost some of its luster to hype and newer trends.
Hype has labeled the language slow, criticized it for lacking concurrency and identified it inferior to newer or alternative languages amongst other things. Now contemporary hype has become a melting pot of sorts where all flavors of subjective claim seem to congregate and reach consensus, blanket statements are formed and like mantras become repeated —cultivating a following of which many subscriptions are solely based on the mesmerizing effect of these mantras.
Mantras however, do not reveal the essence of the underlying displeasure experienced that was severe enough to justify a move to an entirely different ecosystem. Having observed this trend for a while, I suspect that much of the real reasoning is rooted in emotions that are in no way reflected by said mantras. Common reasons (if they could be expressed honestly) might include —but would not be limited to;
- Our innate attraction to novel experiences —it is far easier convincing a company to adopt something that is better, than to adopt something because we find it sexy.
- Our difficulty with accepting our shortcomings —our egos are quite adept at protecting us from emotional discomfort, they make it easy to blame our tools when taking the blame for a code mess after we’ve worked so hard at getting it right would be so much more painful.
- Our difficulty with exposing our shortcomings —we make it past our egos, accept that we messed the implementation up and are intent on learning better practices. Few companies would be understanding enough to give us another crack at it, then there is our reputation and a family that depends on us. We let the tools take the heat this time and silently swear to do better on the next round.
- We have an invested interest in the new thing —we might be feeling particularly righteous about some work we’ve done on a tool in a different ecosystem, that we know is superior in some or other way to this tool, but it frustrates us that nobody else is aware of it and we know how much noise we’ll have to make to get people to take notice, quite a task, but it’s for the greater good and somebody’s got to do it, right?
- Payback’s a &^%$# —there was that one time we contributed something of great value to that community and they said it wasn’t in line with what they were trying to do, this’ll show them.
- We love our ecosystem, let’s become more —who are we going to bash on today?
..I’m sure you get the picture. Now I don’t expect this trend to slow down any time soon, but in examining the implications of this behavior, one invariably wonders how much less efficient these nomadic migratory habits are, and with the growing number of nomads that move on from this, to that and to the next thing —can we be certain that we’ll settle on a superior philosophy when we reach critical mass and stop?
Programming languages are aplenty and all have their ideologies, at a fundamental level most ascribe primarily to one of three paradigms; Procedural, Functional or Object-oriented, and these paradigms lay the groundwork of the language’s philosophy. Atop of this, language developers are free to blend aspects of the other paradigms and their own principles in bringing their unique expression to life. A community then forms around the language and its evolution from this point on is subject to a great many factors.
In choosing a language, I much prefer evaluating it against its merits and philosophy than by what the hype machine is generating. I look at things like what problems it aims to solve and how it goes about solving them, how its community responds to newcomers and how members respond to one another, how actively developed it is, what it’s known for and finally how the language makes me feel —a pretty important factor when considering the extensive number of hours one spends working with code, if the experience is not going to be enjoyable, then why do it at all?
Ruby’s creator reveals some of what influenced his design..
Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines.
This speaks to me, it tells me that with Ruby I should be able to express myself in a way that is more natural for me than for the machine, it makes sense that —since we’re putting in the effort to create programming languages for our convenience, we should be making it as natural for ourselves as possible. Ruby does a good job of this, but don’t take my word for it, fire an editor up and hammer out a few lines of Ruby code —read a file or map through an array, its concise eloquence will be immediately evident.
A language needs an ecosystem, and the vibrancy and character of that ecosystem is a direct reflection of its community’s personality. Ruby’s ecosystem has been around for a while, making it easier to identify dominant traits and main factors of influence with a fair amount of confidence.
Rubyists gravitate towards being supportive, they tend to rally around efforts, helping to improve on something instead of duplicating or cloning work. They frequently post and share ideas and thoughts, helping to enrich everyone’s experiences —and it’s easy to see that they feel a great deal of excitement and pride from their efforts.
These efforts extend beyond a sharing and supportive community, there is an extensive number of articles, books, courses, podcasts and conference videos available online —and even though we won’t be getting into the details of writing better quality code in this post (we’ll do so in another), you can easily find sterling material on the subject from industry veterans and professionals such as Avdi Grimm, Dave Thomas, Kent Beck, Martin Fowler, Robert Martin, Russ Olsen and Sandi Metz to name a few. Current, actively developed, and in Ruby.
The Ruby ecosystem’s biggest celebrity is Ruby On Rails, —Rails henceforth. Rails, a web framework, can be credited for most of Ruby’s initial adoption and prominence in the sphere of web development. Rails was the gateway into the industry for many, attracted by the convenience of Rails’ emphasis of convention over configuration. However Ruby is not only Rails, and even though many cite indexes such as those of TIOBE and RedMonk as evidence of Ruby’s waning market share and an indicator of doom, I can only see it as the fear-mongering aspect of contemporary hype that it is.
Aspects of technology that have made an impact and continue to appeal in our everyday lives tend to follow the Hype Cycle, there’s the peak that comes with the hype attracting many, then the dip while many a nomad moves on. Then comes the interesting part..
..the Slope of Enlightenment —and Ruby’s current stage in the cycle. Ruby, Rails and the rest of the ecosystem is alive and thriving, I assure you. But once more, do not take my word for it, look for the work being done on Ruby 3 (aptly tagged 3x3 for it aims to be three times faster) and guilds, seek out the very much under-appreciated work being done on the alternative implementations; JRuby, mRuby, Rubinius and TruffleRuby, then follow up on the activity around a few of Ruby’s prominent gems.
Some of the defining characteristics of the Slope of Enlightenment phase are identified as;
More instances of how the technology can benefit the enterprise start to crystallize and become more widely understood. Second- and third-generation products appear from technology providers.
This is being expressed in the increasing amount of content exploring different ways of conveying intent with Ruby as-well as with the fine work being done on newer gems such as those that make up the dry-rb collection, Rom-rb, Trailblazer and Hanami. There’s quite a bit going on, isn’t there?
In To the Neophyte Coder; Plotting a course we touch on the difficulties of cultivating Beginner’s Mind and here we’ve looked at the importance of learning about concepts that improve one’s quality of code.
The Ruby ecosystem —at least for me, provides ample material and live discussion on the matter while simultaneously making it less arduous for me to internalize valuable concepts, and quicker to apply my newfound wisdom productively. Suffice to say that through Ruby I am becoming a better programmer quicker, and I think a lot of it has to do with how enjoyable the world of Ruby makes the experience.