Java Götterdämmerung [opinion]
Java Götterdämmerung [opinion]
Like all organisms, better languages replace those that don't adapt rapidly enough. But what does it mean for a programming language to be alive?
Join the DZone community and get the full member experience.Join For Free
A few weeks ago I mentioned that I thought Java was dead, and was surprised that it elicited any reaction whatsoever.
Most people want to take a statement like that and immediately make it personal: you have an axe to grind thus you are electing yourself constable and coroner and issuing a decree.
My argument was that it simply fails to satisfy any definition of being alive. And I don't necessarily mean alive in the Walter White sense ('I felt…. alive….'), but kind of.
Since then, all the evangelists got fired and rumors are swirling that Oracle has given up giving a crap about Java. The other part of this whole thing that kind of cracks me up is I keep wondering what did these Java priests think was going to happen when Oracle took possession?? The answer to these two weird threads are the same: the antithesis of the black swan is of course the white one, and once an organism reaches a certain mass, it just thinks inevitably it will remain the biggest organism around. But in technology, mass is pretty meaningless, because inertia has become less powerful in the last few decades. The whooshing sound that came when people finally lost hope for Subversion ever supporting lightweight branching should be a cautionary tale, and I think Java may be at that tipping point now. Furthermore, the world has moved: what Java dominated is a market that frankly no one really cares about anymore. Enterprise software is now considered the realm of monolithic necrotic brontosauruses sunning themselves next to the primordial ooze, squirting out glacial releases that contain mostly bug relocations. One of the main reasons Enterprise is so dead is that no one good wants to work on it anymore. Once people have worked on a project where the releases come out frequently, people can run their app, it does things, going back to the grit and bear of a demands list from business nitwits in an elaborate corporate hostage crisis has all the appeal of a fungal sinus infection. Seriously, if you have an enterprise programmer and you think (s)he is any good, here‘s my main point of advice: make sure no one introduces that person to mobile development. Of course, you could use more traditional means of convincing said individual that being alive is not all its cracked up to be. Good luck with that.
Meantime, doing another new project with iOS, it is the standard-bearer at this point in time. Incremental compilation and great testing support make it the best way to do TDD in the history of development. Swift is just stupid. My favorite part of it is that there are not few occasions where you put time into figuring out half-assed stupidities, but really next to none. Some of this is just due to the inclusion of Optionals, and some to the fact that abstractions are mapped more cleanly. There are still some things that I think are needed: unit testing of CloudKit is the most pressing one. Doing Protocol-Oriented Programming has been pretty easy and clean for the most part, though, using a Protocol as a key in a Dictionary, which you would have thought would be trivial, turns out is not, for reasons that are not totally surprising. Apple needs more and better sample apps that demonstrate this, that's for sure. There are, however, stupid amounts of interesting things being written about Swift. (If community activity of non-trivial engagement is a metric of life, again, Swift to Java looks like running bamboo v. the petrified forest.)
Finally, having watched the NSOperation session 3x, there are a lot of quiet aspects to the revolution on the Swift side, that I think will creep up on others. Everyone who watched that session I know was excited by it. While I do think it is important, there are vectors of importance about it, probably the most important is it‘s a further integration of concurrency into normal programming, which, surprise, most concurrency priests see as backward mo, but for sure it is not. The other thing it is, though, is a pretty startlingly effective means of dealing with a common source of code bloat through a simple, conceptual model: the notion of a dependency. If your goal is to write code that will do many things concurrently in a way that is testable, and the code is readable, Swift 2 is without peer.
The fact that Java has become overrun with priests, spouting on about best practices, and running around slinging their slide decks at conferences should be the best representation of the language‘s necrosis. It's an admission of the fact that the thing in itself is never really going to be what you need and want it to be. That's an easier position to stake out when you just keep pointing to your size. Once other organisms appear that are clearly growing and fixing things you never had the resolve to address, it starts to look like Subversion (being subverted) all over again.
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.