Honestly, how many times do I have to write the same piece of code?
I've been writing software for more than thirty years -- I started very young, really -- and I've noticed a pattern with various languages that I've learned: The same components need to be written over with over with each language. And, an ever-expanding universe of those languages is becoming a drain on productivity.
I started out writing code in C back in the seventies, when pretty much everything was do-it-yourself. There weren't many third-party libraries back then. The introduction of object-oriented programming with C++ was welcome; pretty much the same syntax and low-level control, but it let developers write much more elegant code.
Java fixed most of the issues with C/C++ by eliminating pointers and cleaning up memory management, but programmers were forced to learn a slightly different syntax, and all of the extraneous functions that they were used to had to be rewritten. And while Java's multiplatform capability was useful, it meant that software had to be written for the lowest common denominator of the platforms. But Java certainly hasn’t been the swan song of the new language parade.
It seems though that since the early 1990s, there has been an explosion of languages including examples such as Perl, Python, C#, and Ruby (on or off Rails), not to mention tools such as Flash and Silverlight.
This forces companies to pick and choose which languages they support. For example, if you wanted to try Google App Engine, you would need to use Python, because that is the only language the company supports.
It also leads to the need to develop and maintain multiple versions of the same software. I'm midway through converting a perfectly good Java mobile application for the iPhone, which requires me to rewrite it in Objective C. And it means that in future somebody will have to support at least two versions of the software.
With every new language comes not only the need to learn and remember the new syntax – like remembering if the concatenation operator is "+" or "." -- but also the need to either locate third -party libraries or rewrite those utility functions that you depend on every day. And the time required to do that and maintain it for every language costs us time and results in a loss of overall productivity.
While each new language may provide some previously unavailable feature, that must be measured against the impact of implementing code in that language, the dilution of effort available for the other languages, and the potential costs of switching. Before expending that effort, developers should be sure that the switch is work the risk.
After all, we often forget the lessons that history has taught us, especially in the relatively short history of computer languages. Developers who think they've found the holy grail of short time to market in a language like Ruby on Rails would be wise to look up COBOL, a simple well-used language with an English-like syntax that could easily read and update databases -- 50 ago.
Larry Borsato has been a software developer, marketer, consultant, public speaker, and entrepreneur, among other things. For more of his unpredictable, yet often entertaining thoughts you can read his blog at larryborsato.com.
More news, commentary, and predictions from The Industry Standard:
- Analysis: Thou shalt not ship software before its time
- Analysis: Vetting startup ideas at BarCamp
- Analysis: 10 reasons that start-ups 100% absolutely should outsource (almost) everything
- Special Feature: Where are they now? The Industry Standard tracks down 10 dot-coms from the Web bubble of the late 1990s
Comments
Are you serious about comparing rails with cobol or you're just trolling ?
No I'm not serious. I just recall that COBOL used a pretty simple syntax to easily read and update databases, and to do screen/print output. While Rails offers much more, at its core it does the same stuff.
All languages at their core do the same thing. In general if developers do not keep learning new languages they will also go the way of COBOL. Also when it comes to rails / ruby for me it is not just time to market but ease of maintenance.
From a pragmatic code pumping point of view, i can concur with your assesment that new languages means redoing a lot of old work. Often though, it really isnt as much work as you imply it is. In the general case, wrappers are written. In extreme cases where the difference in language warrant completely different library structure, maybe... but even then, most of those are simply wrappers.
From a PLT standpoint, rewritting old code in new languages isnt really re-inventing the wheel. Generally the new libraries are based off of the old library, not simply 're-invented' from scratch. This helps language communities come to concrete understandings of where and how said language needs improvement to interface with, and make efficient use of the libraries programmers and their bosses think (and often without any solid basis) that they cannot live without.
Does it mean more work? Sure. But its generally more work for the language community. Once the language stablizes, most of the work is already done for the would be programmer to come along and take ignorant blissful advantage of, with no exertion on their part. If you are the sort of person to start using a language before it has stablized, then this sort of work shouldnt come as a shock to you, as that is generally the type of work that pays your bills, or gets you your jollies.
I dont really see this as a massive problem, and even if it was, I think the introduction of new languages is worth the baggage. It could very well lead one day to the development of programming languages that completely automate, or make moot the idea of rewriting library interfaces. Id rather spend an eternity of toil to arrive at a solution, than an infinitely more boring eternity of using old broken tools because its 'efficient'.
In spite of all that though, I get your point, and it /is/ kind of annoying waiting for a 20 year old library to make it to your 10 minute old language of the day.
Post new comment