Archives For Software

1000px-wave-svgBack on 14 July I wrote a post titled “no more java“, in which I swore off the use of Java for everything new and to “walk away from any Java programming opportunity.”

It turns out that there is, practically speaking, no way for me to do that. As much as I despise Oracle, the use of the language throughout the last 21+ years of my software engineering career (Java officially turned 20 in 2015) isn’t something I can just blithely walk away from. As I came to discover over the last 60 days, while there are a lot of very good programming languages besides Java, there are some things for which Java is the better fit, warts and all.

That’s not to say I didn’t find the other languages I looked at as less than Java. I found them all quite compelling in their own rights. The languages I did go back and look into included Python, C-Ruby, JavaScript (via node.js), the latest stable version of C++ (C++14 via gcc and clang), Google Go (up to 1.7) , and Rust (up to 1.11). Notable by its absence is Swift. I chose not to dive into Swift because it’s still only on one platform (OS X, soon to be called macOS) and because it’s still in a state of flux as it transitions to Swift 3.

All those languages I did look deeply into were quite compelling in their own rights and offered powerful solutions for different classes of problems. And while they tended to overlap some features and capabilities of Java, they could never replace Java for the types of software problems I like to work on. And please note, when I speak of the languages I also speak of the development, build, test, and deployment tools that wrap a language and help make it a powerful problem solver.

I don’t consider my two months looking elsewhere a waste of time; far from it. It was an eye-opening trek into languages I would have never taken otherwise, as well as a deeper dive into some languages I’d had considerable experience with before, such as Python and Ruby (in fact, working with Python 3.5 was almost like re-learning the language, as the last version I’d touched was 2.4). With Java I’d grown a bit stale in my thinking, which is never a good thing. Looking at other programming languages fosters opportunities to expand perspectives and offers alternative solutions to tough problems for which Java might not be the best fit. It also illustrate ways to weave these “new-ish” solutions back into new and existing Java solutions.

And finally, by taking two months away from my Java work, I discovered when I came back that tough problems I couldn’t quite solve before were suddenly solvable, some of them quite easily so. I really needed a break away from Java.

So it’s back to Java, or more precisely, the Java Virtual Machine (JVM). For with the JVM I also have Scala, Groovy, Gradle, and JRuby, not just Java 8. I’m using the Actor pattern Futures and Promises and the Parallel Collections Library supported by Scala for modeling and simulation, while using Groovy and JRuby to solve unique problems while calling down into the Java libraries, especially for UI bits. And finally I’m getting the hang of using Gradle as my primary build, test, and deployment framework. I am so tired of Ant and I’m no fan of Maven either.

I need to do this again, at least once/year, to maintain a clear mindset and fresh perspective. I look forward to my next walk-about through the programming language landscape.

I share code on my blog from time to time in order to illustrate key points. In order to display code I use the code tag provided by WordPress. Most of the time I have no problems with displaying code, especially on any of the desktop browsers across the Mac, Linux or Windows operating systems. The only time I have a problem displaying code is on any iOS-hosted browser such as Safari, Chrome, or Opera. But before I show you the problem on iOS let me show you how successfully it renders under Android Chrome (Android 6.0.1 on a 2013 Nexus 7).

This is the prior blog entry with a Makefile and a C++ source file. The Makefile is being displayed properly. Note in particular how the text is of the proper size and alines correctly with the line numbers to the left. Now look at Chrome on iOS 9.3.1, the current release, on an iPad Air 2.

The source code file for the Makefile is grossly oversized. This poor source file display shows like this on any iOS browser, not just Chrome. And that’s because Apple forces all browsers to use the same Apple-provided rendering engine. Thus, it’s not just a problem with Chrome on iOS, but with every browser on iOS, because it’s an Apple problem. I should note that all browsers on Android render source code on my WordPress blog correctly. They each have their own rendering engines, and they all handle this correctly.