Having been in the field of software development for over 11 years, which is not much but should be enough to start gathering some understanding of the field, I’ve had the chance to see different trends come and go.
Agile and back again
The Agile Manifesto from 2001 started a document-free revolution in software development, which stuck until just a few years ago. It was a huge change, as it offered a way out of the heavily enterprisey world that forced you to spend hours behind documents that could have been totally skipped. From "Flaws in Scrum and Agile", emphasis mine:
When the Agile Manifesto was written, waterfall development was king. Agile deposed waterfall from its status as the dominant software development paradigm. Waterfall revolved around writing tedious documents, and face-to-face conversation was indeed superior to that. In 2001, Subversion was still new, Git did not exist, Skype didn't exist either, and the closest contemporary equivalent to GitHub was SourceForge. "Face-to-face conversation," in the Agile Manifesto, was "the most efficient and effective method of conveying information" because the other methods were terrible.
But when you're reviewing a pull request, a GitHub diff usually beats face-to-face conversation. And this is not a fluke. Remote work requires a ton of writing, and that's one of the best things about it. [...] Waterfall used too much written communication, but Agile doesn't use enough.
I won’t reproduce here the entirety of the article, or the many more that come up as soon as you Google for Agile is Dead, but you get the idea. Having a written support to be able to work offline, where you can settle down your thoughts, and where you can return months later to find out what the heck were you thinking when you decided to implement that, is invaluable.
Whether the successor to Agile is Remote, Continuous Delivery or Devops (or we just rethink it), the point I’m trying to make here is that the brilliant (no irony here) folks behind the Agile Manifesto did not want to eradicate Comprehensive Documentation by burying it with Working Software. They wanted to make a break from the suffocating world that Waterfall and other document-heavy processes had become.
Back to programming
This endless introduction brings me to the subject matter of this article: the same is happening in the field of programming languages.
After nearly a decade of having Java-like type systems get in the way of *actually* getting things done, and having to deal with AbstractSingletonProxyFactoryBeans, we as programmers welcomed dynamic languages as a breeze of fresh air. Personally, I remember working on my first Ruby and Python programs after years of C# and Java, and become amazed at the increase in productivity, as well as the true happiness that came from coding in them. Things were now [simple](https://xkcd.com/353/) (or should I say [easy](https://www.infoq.com/presentations/Simple-Made-Easy)?) as they should have always been.
We no longer had to work bounded by the crutches of an overly zealous type system, and could finally be free to code at will.
Fast forward quite a few years, to the point where we have massive codebases written in Ruby and Python, and we are starting to have second thoughts. We are now seeing a backlash, where the mainstream dynamic programming languages are having or considering additions to ensure type safety. From Are static typing and functional programming winning?, though I want to focus on static only:
Some of the most popular dynamic languages are considering some form of static typing:
- Ruby: Matz announced that Ruby 3.0 may have type annotations.
- Python: Guido van Rossum sent out a proposal to add type annotations to Python.
- PHP: Facebook has released Hack, which supports type annotations on top of the PHP syntax. Moreover, PHP itself already has Type Hinting and may add return type declarations.
- JavaScript: Facebook has released Flow, Microsoft has released TypeScript, Google has released Dart and AtScript, and there are many statically typed languages that compile to JavaScript, including GWT (Java to JavaScript), Scala.js (Scala to JavaScript), Haste (Haskell to JavaScript), and purescript (Haskell-ish to JavaScript).
Again, if you Google for static typing, you will find a large number of articles stating its benefits in terms of performance, tooling, refactoring, mistake prevention, and even in the fact that they actually help you while coding by reducing the cognitive load of requiring the programmer to keep in his/her head which-type-is-going-where. I particularly recommend this recent article, especially because it ends with a great list of other articles on the subject. Unsurprisingly, if you look for older articles on static typing, when the feeling about it was quite different, you might stumble upon slightly opinionated gems such as this one.
And again, we did not jump into dynamic languages because we thought that types were the root of all evil (well, maybe some folks did), we jumped because we needed a clean break from the bureaucratic nightmare that had surrounded Enterprise-Edition languages. And just as with document-oriented methodologies, after we have spent enough time away from them, we begin to recognise their good parts once again, and bring them into our worklife in a saner way.
Where we stand
Seeing this re-valuation of statically-typed languages in the very recent years, I can’t help but think that at Manas the correct decisions were made when we1 started developing a new language, choosing to bring together the syntax and friendliness of Ruby, with static types powered by global type inference. This yields a programming environment where types do provide useful help and information, yet they do not clutter the code and get in the way.
After going through the two mentioned opposing tendencies in programming languages, Crystal truly feels like the natural next-step in this chain. Having a static type system that is helpful yet not overwhelming requires a very delicate balance, one that we have managed to attain only after years of being on both sides of the fence.