Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

7 programming languages we love to hate -- but can’t live without

Peter Wayner | May 24, 2016
Tools masquerading as languages, maddening syntax, dusty code that won’t die -- here's what has us shaking our fists.

We may have better tools for writing business logic to manipulate databases, but no one seems to bother because it’s easier to buy a bigger computer and keep the Cobol code running. As I type this, there are 543 jobs listed on with the word “Cobol” in them. There are Cobol jobs in insurance companies and defense contractors everywhere. The early adopters of mainframes still use Cobol -- and get the job done. Computer scientists may recoil in horror, but as long as customers are lining up, the bosses will say, “If it ain’t broke, don’t fix it. Just buy another mainframe.”

Language we love to hate: XSLT

Everyone starts off loving XSLT, a functional language for transforming XML. It’s a clever solution that works very well when you need to extract bits and pieces of large XML documents. But once the boss asks for something more complex than a simple search and replace, the development bogs down. The language is explicitly functional, and soon we discover that when the documentation says “variable,” it is using the word like an algebra teacher not a programmer. Ponder this Zen-like sentence from XSLT expert Bob DuCharme: “XSLT variables actually have a lot more in common with constants in many programming languages and are used for a similar purpose.” If you want to use a variable that behaves like a variable in other computer languages -- that is, it can change -- you better be very clever.

XML may be losing ground to more efficient data formats like JSON, but it’s still a powerful foundation for many big data processors. You don’t need to use XSLT. You can always write basic code that parses the text itself. However, writing all that code to parse the XML can be more work than grokking the XSLT structure.

Language we love to hate: Java

The virtual machine and the libraries may date from the ’90s, but the syntax is stuck in the 1970s when C was created. The automatic memory management seems like a big step forward until your code decides to take a knee while the garbage collection takes control. The Android developers exchange tips on when to politely request a garbage collection in advance to ensure that the garbage collector doesn’t start up in the middle of an important event, like a phone call to 911.

Java programmers have complained for a long time about many issues, some of which have been fixed or at least addressed by Oracle. But this creates a new problem. Some of the newer code and libraries can’t work with the old VMs. I spent a day trying to wrangle java.lang.UnsupportedClassVersionError but could not find a permanent solution. It’s almost as if each version of Java after 1.4 is a different language.


Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.