Java programmers have complained for a long time about many issues with the language, 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.
The Java release cycle spins out new versions with new features at a faster pace than ever, which sometimes looks like the salami is sliced thinner but they’ve sped up the assembly line. This is great if you need the new features, but it just means even more complexity in keeping your code stable and running.
None of these issues matter. Java is a foundation for the web and mobile phones. It’s still the first language taught in many high schools. The collection of libraries is deeper and more valuable than almost any other language. Not only that, but many of the clever new languages secretly rely on Java’s foundation because they’re compiled to Java byte code. Java will always have a place in the stack. Just accept it.
Python
Python is a modern language that appeals to younger developers. The punctuation is sparse, and the code looks a bit cleaner. What’s not to love? Instead of counting and balancing curly brackets to define blocks of code, we’re counting white space and making sure columns align. Just make sure you’re using a monospace font!
Well, for one thing, there’s the gap between Python 2.7 and 3.0. The big change, though, isn’t the only one and many of the newer versions include updates that might break your code. Functions that once returned 0 or 1 now return booleans in Python 3.6. Words like “async” and “await” became reserved keywords in version 3.7. The Python team, though, has heard the grief of coders who can’t keep track of the versions and most of the changes seem to be additions and new features not fixes that break your old code.
Yes, the team has no choice if they want to keep improving the language. But anyone trying to maintain a bigger project and work with older libraries will forever be checking to see which version of Python is installed.
This gets even more complicated because many of the popular Linux distros use Python for system tasks. Even if you can keep the versions straight for your code, the distro may be using a different one. Just last year, my Python code stopped working when I upgraded the underlying version of Linux and this upgrade quietly updated the version of Python on the box. Whoops. But the language is so deeply embedded that we’re stuck with it.
None of these objections matter because the soft science crowd has fallen for Python with all the warm, fuzzy emotions that kept them out of the hard sciences. Biologists and economists think Python is the one. Some even propose requiring Python code in new prospectuses for stocks and bonds so that investment bankers will be able to bamboozle us with Python instead of fractured lawyer-speak.
The bandwagon has left the station, and it’s full of soft scientists.
Swift
If you want to charge your iPhone you need a special plug and if you want to program it, well, you also need to use a special language, too. Apple always needs to do things its own way. It’s not exactly true that Swift is an Apple-only language. A small group of dedicated people celebrate using Swift on a server. But for the most part, it’s just a special not-so-secret handshake language that can only be used inside the Apple secret fort.
As languages go, Swift is better than Objective C, the other not-so-secret handshake language it’s largely replaced. The punctuation is saner; the typing is better; the header files are gone; and the memory management is more automatic.
But for all of those improvements, life is still not easy for developers. The language is big and that makes it harder to absorb. The books go one for hundreds of pages detailing all the fancy new features from elaborate types to tuples to protocols. It’s impossible to list every clever and obscure idea that got bolted onto this dreadnought.
Other companies have taken a different approach. Google tried to make Go as simple as possible to, in turn, make the code simpler to read and understand. Swift's endless clever features may end up saving time occasionally when a programmer knows how to use them, but there’s a good chance that the next several programmers who read the code might not be so familiar with them. Swift has so many clever features that it’s hard for anyone to master them all.
The best example of this cleverness overkill may be the way that any coder can create new operators out of any random set of Unicode. It’s great fun the first time you use an emoji in your code, especially one of the emotionally pungent ones, but the next person to come along is going to be confused.
But none of this matters because Apple loves its language as much as it loves going its own way. Sure, it would be nice if you could swap code with the world outside Apple's secret fort, but that’s not going to happen. So the best solution is just to study up on Swift and, maybe, stick to a small, core subset of the features.