Over a million developers have joined DZone.

Ladies and Gentleman: the Language Grafters

DZone's Guide to

Ladies and Gentleman: the Language Grafters

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

In the spirit of Serial, the remarkable podcast, I am going to start pursuing threads through multiple posts here. There were a lot of unexploded bombs left in the rubble of my Java 8 post. I want to pickup one of them in this post: what happens when languages are glued together with either prior incarnations of themselves (Java 8/7/5/4) or are bolted onto existing ones (Swift/Objective C). Just so happens, I did a bunch of Java 8 programming, and a bunch of Swift in the last few months. Two things the prior post failed to suss out adequately: 1. why in Java‘s case, the grafting is particularly pernicious, and 2. why in the case of Swift, I would return a different verdict. One of the things that I grew up thinking made me a logical sort and every year makes me feel more like a nut is I like to consider outcomes when evaluating how well something works.

The first language satyr, and maybe the one that could have destroyed the whole category was C++. It literally took a language from one Kuhnian Paradigmatic period (Structured Programming) and pushed it into the next one (Object Oriented Programming). Sadly, while I really liked C++, any judgment rendered on outcomes has to consider it largely a failure. Based on metrics studies that showed that over a decade after its appearance, 90% of programmers using C++ were writing C code.

The Producer/Consumer relationship in coding is a source of endless wonder. I hold to the belief that a framework fails if it allows itself to be used improperly. Sounds like a kind of stupid commandment that is about control. It‘s not. It‘s about making sure that the path is clear so you don‘t just end up with a wilderness in which a million wanderers lay down completely unrelated paths. When I first started working with Cocoa, I thought ‘this is kind of a tinkertoy, didSelectRowAtIndexPath, etc. But after a while, you realize that Cocoa is one of the best frameworks ever because once you learn it, you can write fairly clean, uniform code, and you can read the code of others. Languages cannot prove themselves on their own, we should have learned that by now.

The C++/Java Watershed was really not about language. C++ spent almost a decade and there were pretty much no APIs/SDKs, other than the STL. Java went to the other extreme and decided to try to paper the whole waterfront. Now, we have competing walled gardens. But they look pretty good efficiency-wise, when compared to the dog‘s dinner/rambling wreck of movements that go from growth to bloat but can‘t help themselves.

When you look at Swift vs. Java, the first possible way to see their differences is that Swift is an aggressive example of focusing on offense, while Java 8 is the lumbering wonk who, in the face of hipster criticism, finally agrees to grow a beard. I was pretty happy with the Modern Objective C changes. When Swift landed, I thought ‘what? someone got a whiff of glue instead of aromatherapy.‘ But using it is kind of magic. Another post, but the early takes on it were so stupid, so off-base, so glaringly imbecilic it was hilarious. The most refreshing thing about Swift is its an attempt to kind of utter the last word on language design. Does that sound nutty? I hope so. But really, hipsterism, in Nietzschean terms, is by definition built on self-delusional. We keep having the dream of the new language that makes coding an uninterrupted, skipping and whistling joy, through some new features none of the oldsters thought of. Shouldn‘t language eventually, in Nash terms, tend toward an equilibrium? Meaning, isn‘t there a period in which feature discovery and experiment gives way to a settling of combinations and certain accepted consensus? Yes. There truly are not new ideas, and there is a LOT of consensus. Swift doesn‘t make the mistake of favoring polemic over power. Using it doesn‘t feel like you are having some hipster show you a new way. At some point, as you go back and forth through the (excellent) book, you think ‘this is a kitchen sink, but one that is put together, well.‘ There is some trash talking in the advanced session at WWDC. Some of it is deserved, like when it is pointed out that the generics are real and don‘t use Type Erasure (like Java), but some of it is hyperbolic and stupid, of the ‘ok, what I‘m about to tell you is going to blow your mind, ....pow…...‘ variety. Overall, though, on a good Swift day you are thinking ‘this feels like cheating,‘ and on a great Swift day, you think ‘this is the best language that ever was.‘ (That said, for a really whack twist here, I have flipped and prefer Android now, next time…)

The response amongst programmers was gleeful at first, followed by not even skepticism or day after remorse, but just kind of whininess. Some of it I agree with, it can get tiring having to change code that was compiling, to suit some syntactic shift. But, most of the time, the improvements feel like adequate recompense. The only thing I miss, and am still not sure about, is the absence of Exception Handling. That‘s a post in itself, but for now, it certainly is not enough to turn the verdict for me.

Back to question number one of this post. First off, though Oracle has been selling Java 8 as the biggest batch of new since 5, it‘s really not a new language, and it took too long and came in backpedaling. That said, I like Java 8 a lot. Swift, on the other hand, is poised to do what probably no other language ever has: to transport a population of coders from one language to another. It‘s not without pain, but unlike C++, it also isn‘t going to result in a scene of a few elders declaring victory while trying to hide the fact that only a tiny portion of the population took their ferry, having chosen instead to just stay behind.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Published at DZone with permission of Rob Williams, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}