Understanding the Context: Why Programming Language Superiority Is Misleading
Written on
Chapter 1: The Debate on Language Superiority
In the past, I often found myself drawn into discussions about programming languages. While I can't claim to dislike these exchanges, I must admit that they can be quite entertaining, especially when shared over coffee. Topics like “What’s wrong with this language?” or “My preferred language is simply superior” can spark lively debates. However, I believe that such discussions may not be appropriate for someone in the engineering field.
The reason for my stance is straightforward: discussing a language’s superiority or inferiority without considering the context of its application seems futile. Broadly speaking, languages like scripting and dynamically typed languages are crafted for a select number of skilled teams aiming for maximum efficiency.
Consider Perl's module for manipulating symbol tables or Ruby’s library that leverages open classes for ease of use; both rely on the trust placed in the engineers who adopt those languages. The creators, Lary and Matz, designed these tools with the assumption that responsible adults would use them judiciously. (I must apologize for not delving into Python, another well-known scripting language, due to my limited expertise.)
These programming languages can significantly boost productivity for small, elite teams, perhaps 10 members or fewer, or even moderately sized teams of up to 20. But what transpires when the team expands to over 100 members? While it’s conceivable that if all 100 are highly skilled, productivity would soar, the reality is that only a handful will truly shine. In a team of 100, you might find just 3 or 4 exceptional engineers, 10 competent ones, and the remainder may not contribute effectively.
Of course, organizations can enhance their talent pool through strategic hiring. Yet, even then, a considerable portion may harbor the mindset that allowing others too much freedom could jeopardize the project.
Now, let’s talk about Java. Often seen as a nostalgic relic, I've previously thought it was time for Java to phase out. With a plethora of languages operating on the JVM, it seems no one truly considers Java to be outstanding anymore. Yet, Java has merits! Its limited features can frustrate those accustomed to dynamically typed or modern languages (whatever those may be).
For instance, closures were only introduced in Java 7 after much debate, and implementing them through standard class-based abstractions can be cumbersome. Completing a project in Eclipse might yield less than optimal results; the code is often anything but elegant. Matsuo Basho once captured the essence of simplicity in his famous haiku: “An old pond, the sound of water as a frog jumps in.” Yet, if we were to rewrite it in a convoluted manner, would it still hold the same beauty?
Java may lack robust language specifications, yet it remains effective. The humor lies in the paradox of its limitations—many seek more freedom, yearning for a language that allows them to do more.
However, in a scenario where 100 engineers are tasked with coding, the presence of numerous less-skilled individuals necessitates a structured approach. When 60 inexperienced programmers contribute, having fewer freedoms can yield better outcomes. If two senior engineers and ten talented developers design an interface, even less skilled coders can achieve satisfactory results.
Certainly, even the best-laid plans can result in poor code. Nonetheless, poorly written code cannot dismantle a well-structured design and interface. In Java, practices like reflection are often viewed as problematic. If unrestricted, it could undermine the very essence of what Java represents.
Consequently, it’s reasonable to assert that the language used for projects by small teams of elite developers differs from that which is suited for large teams of 100 or even 10,000. If one believes that their chosen language is the ultimate solution for all scales of development, perhaps it's time to reconsider their perspective.
While I recognize Scala as a worthwhile language, I doubt it will replace Java in enterprise settings. The reason is simple: Scala offers greater flexibility than Java.
To put it in extreme terms, programming languages exist on a spectrum, from those that grant extensive privileges to individual users to those that impose strict limitations. Lisp, with its macros, embodies the former, capable of extending the language itself. However, the downside is that even one errant individual in a group of 20 can wreak havoc. On the other end lies Java, which may offer less freedom but minimizes the risk of chaos among its users.
This illustrates why discussing the superiority or inferiority of programming languages without considering context is largely pointless. While some observations can be made devoid of context, I no longer feel inclined to engage in such pedantic debates.
Subscribe to DDIntel Here.
DDIntel captures the more notable pieces from our main site and our popular DDI Medium publication. Check us out for more insightful work from our community.
Register on AItoolverse (alpha) to get 50 DDINs
Follow us on LinkedIn, Twitter, YouTube, and Facebook.
Chapter 2: The Impact of Programming Languages on Code Quality
This section delves into the nuances of how different programming languages affect the quality of code produced by teams.
In the video titled "On the Impact of Programming Languages on Code Quality," the speaker explores the intricacies of how language choice influences the overall quality of software development.