As an undergraduate at Notre Dame, one of my first programming jobs came in the form of building and maintaining a website for an initiative run by the Electrical Engineering department. In many ways it was a great gig, in that the hours were flexible and it gave me a chance to learn things I wanted to know anyway. However, the one downside I discovered stemmed from the fact that the EE lab manager overseeing the job had a deeply embedded love of Perl. I must admit, I shared none of his love for Perl as a language, but found it tolerable for the occasional shell scripting task. To my mind, the syntax was idiosyncratic, adding unnecessary cognitive overhead to understanding the intent of code.
Around the same time, I was introduced to PHP and used it for several
personal projects. Though often derided for its security (or lack thereof),
PHP's greatest virtue was the simplicity of its model - a page maps to
a file, and the syntax largely HTML with blocks of logic sprinkled in.
The productivity of the model was extremely liberating compared to the
line after line of sprintf statements necessary to build a page
in Perl. However, for a variety of reasons, my boss was something less
than enthusiastic at the possibility of unlocking this productivity.
"It's not secure" was the the first objection raised. While there was
likely some validity to the argument, looking back, it was true of
virtually every web framework of the time. Another favorite line of
attack came in the argument "It's not a mature language". Certainly,
it did not have the history of Perl, but is that alone a meaningful
criteria for selecting a language? In the end, having failed to
persuade my bosss, I spent the next semester writing what may still be
some of the least visually appealing code I have ever written in a
language that I have never since heard used for serving web traffic.
So what can we take from this story, aside from the fact that I will not be returning calls from any recruiter who mentions Perl in the job description? Parallels of this problem abound throughout software development. Tools that serve one purpose well are thrust onto problem spaces that really have a fairly different set of requirements. Sometimes that is due to the personal preferences of an influential member of the team or an artifact of Hype Driven Development. One example that comes to mind in the web space are Single Page Apps (SPAs), which levarage JavaScript frameworks to perform client-side rendering of all content, including intercepting navigation events and re-rendering the new "page" without performing a traditional page load lifecycle. While the technique has some very valid use cases, the vast majority of sites implementing SPAs would be just as well served by a traditional server-side rendered page and, as a result of the complexity of implementing a SPA, often provide a worse experience due to bugs. At the opposite end of the spectrum, on a fairly regular basis, I see C++ used to implement high level code that likely is not overly performance critical.
In both cases, it is relatively easy to argue for the extra complexity up-front on the basis that the code may need more performance optimization or the web site may grow to need the features a SPA provides. As developers, how do we balance the unknown but potential benefits against the very real productivity gains that can come from using simpler tools. Martin Fowler proposed the notion of a sacrificial architecture - an initial version built with the full knowledge that it would be imperfect and need to be re-written. In practice, my observation has been that such efforts are difficult to sell to senior leadership, and often forced into an evolutionary path. Interops represent another potential solution to the language selection variation of the issue. If better options existed for seamlessly moving between high-level and low-level languages, perhaps more projects would leverage safer, modern languages while calling out to unsafe code only where truly required. On this front, I will be eagerly watching the developments around Carbon, a new language that aims to introduce cleaner syntax and support for features such as real generics, while maintaining compatibility with C++. It's approach is somewhat different than Rust's, but I certainly view any increase in the pace of evolution in the low-level space as a positive.
Disclosure: Carbon was developed by Google, my employer, although I am not affiliated with the team directly working on the product.