Why?

This is the first in a series of 5 posts:

1. Why? (this article)
2. Attumi (email Batch A) - A Java-like Language with default immutability
3. Attumi (email Batch B) - A Java-like Language with default immutability
4. Attumi (email Batch C) - A Java-like Language with default immutability
5. Attumi (email Batch D) - A Java-like Language with default immutability

---

The oppositional part of me says, "Because!" However, that would make for a pretty brief blog entry and not leave much else to post later, huh?!

There are numerous reasons. They cover a wide spectrum. Here are the top three influencers for me:

1. Java's getting long in the tooth and becoming too complex - it badly needs a reboot as the legacy it's having to maintain (ex: raw collections) is now deeply thwarting effective adaptation
2. Oracle now owns Java, and I don't trust Oracle. At all.
3. I want to create multi-core/multi-CPU apps with less effort (than Java) while future-proofing my new programming language investment

Here's a less emotional more technical article (on IBM's Developerworks site).

1. Java's Becoming Over-Complex:

I suppose the strongest reason for me is related to the complexity of Java; i.e. I just finished writing a personal project over the holidays. And I found myself having to write acres of defensive boilerplate code in Java to implement a relatively simple two player turn based game. And when I went to do performance testing, I discovered weird inconsistencies I had not really noticed before. It was a personal learning project, so I was bringing an additional level of scrutiny to what I was doing.

For example, to prepare for taking my code multi-threaded later, I decided per Joshua Bloch's advice in "Effective Java 2nd Edition" to make as much of the app as immutable as possible. It was quite a bit of work, but I essentially achieved it. And I was quite proud of that. However, I discovered that there was no real safe way to tell if a List had an immutable wrapper already. So, it turned out I was copying, wrapping and then re-copying and re-wrapping the same List and passing it around. And after researching the issue (I even started a StackOverflow question), I found there was no "smell-free" way to effectively detect if a list was already immutable; at least not one that seemed like good OO design which was also high performance. This led me on a chase to see what other options I had besides using the standard Java collections. I quickly found Google's Guava libraries project and it felt like a leap in the right direction. Guava seemed to address a number of obvious pain points I had experienced with Java.

Another inconsistency in Java was the weird differences between Java arrays and Java collections. Arrays just don't work right and are by default mutable (and there's no real way to make them immutable without TONS of boilerplate). And as I researched that, it appeared to be the challenge of ensuring strong backwards compatibility with original versions of Java from 15 years ago. Java's starting to have a pretty distinct odor around it. It sure appears it's time to stick a fork in it and call the 1.x branch done. And generate a new backwards incompatible (to some degree) version which shakes off some of the old crufty/smelly/dingy stuff from the past.

2. Oracle's FLOSS behavior regarding the Sun products/projects has been atrocious:

And then Oracle sued Google over Android (claiming copyright and patent infringements). And the fact Oracle did so using software patents pissed me off to no end. I was already pretty suspicious of Oracle's motives after buying Sun and how they treated the FLOSS communities initially. Then, Oracle's initiating aggressive litigation was just another "annoyance" around Java itself. I no longer trusted Java's steward, Oracle. Here's an article I wrote on my personal blog covering this in a bit more detail. And it isn't just me having these thoughts. Here's a snippet from an article by a world-wide consulting group sharing a very similar view of uncertainty (i.e. instability) around Oracle's now "owning" Java.

3. Writing mobile phone apps for iPhone/iPad and Android:

Finally, I am interested in creating an app for mobile phones, and specifically my mobile phone. I had an iPhone 3G (and have since gotten an iPhone 4 upgrade the last week of the 2010). I spent most of October getting the cheapest Mac-Mini I could find so as to be able to learn how to create apps for the iPhone.

I then spent some time diving into Objective-C. UGH! That was like losing the last 20 years of software language advances in one fell swoop. I am not saying Objective-C is bad. I am saying that I also don't think COBOL is bad. However, neither appears to have any sort of long-term career development positive angles for me. And of course, Steve Jobs mandating that all iPhone and iPad apps must use Objective-C, C and/or C++ this time last year just pushed me over the edge to dig in and research alternatives. I think Job's dictate last year created more interest in Android by developers than anything either Google or the OHA (Open Handset Alliance) could have ever done. So tyvm, Steve.

After about 5 hours of investigation into Objective-C, I was looking around and found MonoTouch. This meant I could use C#/.NET to create iPhone and iPad apps. And knowing C#/.NET had lots more long-term career advantages than my learning Objective-C. I spent about 15 hours working through my options in the area. I then decided, once I had completed my board game rules model in Java, I would have someone else put the UI on it (via Rentacoder - apparently recently renamed to vWorker) and I would work on converting the model to C#/.NET.

While reviewing C#/.NET, I couldn't help but notice a very similar amount of boilerplate was required to author classes as I had to generate while in Java. Granted, it was not quite as much. But it was still LOTS. And I have very limited spare time within which to make my learning investments. So, while C#/.NET was WAY better than Objective-C (for me and my values) in that at least I had a garbage collector (talk about removing tons of craptastically intricate Objective-C code), it still felt heavy, like Java...significantly over budget in the complexity department.

I know, I'll just invent my own programming language:

And then on the way to work in early December, I had an "aha". A question entered my mind on my morning commute, "What if I were to invent my own Java-like language, but make it default into patterns that were more aligned with the pathways I primarily used?" As soon as I asked that question, my mind began to flood with ideas. And as I worked on my personal project over the next month, I kept doing a reply to an email I sent to myself adding the things I wanted. I covered the gamut, from very low level machine instruction efficiencies all the way up to strategic re-configuration/adaptation of collection classes defaults for running systems. It felt great to have all these ideas flooding me.

After about 3 weeks of writing emails to myself, I began to share my ideas with a couple of very close friends, explaining my predicament and my "aha". And from those conversations, I began to become convinced the "pain points" in the current tools were exceptionally high around multi-core/multi-CPU regardless of Java, C#, C++/C, Objective-C, etc. And none of them really "defaulted" into a more immutable way of thinking.

And then I had a conversation with Charlie Strahan, my best friend's son who is becoming a software engineer. I shared with him some of the details of my "programming language invention". He then asked me if I had checked out Clojure and Scala. I said I thought those were JVM scripting languages. He then urged me to check out functional programming, mentioned F# on the CLR, and that he thought Scala was the closest to what I was describing. And that there were some free chapters on the Internet I could read to get a feel for the language.

First Clojure, and then Scala:

The next day, I noticed an article on Clojure and began to research it. I spent a couple of hours reading up on it. Basically, it was a JVM implementation of Lisp with some better specialization. The most important part, though, was that it was by default immutable. I was immediately intrigued. I spent a couple more hours reviewing it. That's when a text from Charlie came in directing me to the free chapters from the book "Programming in Scala". I read them. I then started reading any articles I could find on Scala. I was startled that it hit at least 60% of the ideas I had generated on my own. At first I was annoyed. That lasted about 10 seconds until I realized, OMG, this means I don't have to do the work. I can just use Scala.

And so began my trek into learning Scala. The points which convinced me the quickest were around the language's originator, Martin Odersky. As I learned more about him and his having started in Modula 2 around the same time I was using Modula 2, his being a student of Nikolas Wirth for whom I had great admiration around Pascal, Modula 2 and Oberon, and then his being the originator of Pizza and GCJ (generic for Java before Sun even had the thoughts), his then moving to work for Sun and their requesting the use of his compiler and inclusion of generics replacing their own in-house compiler and finally his finishing at Sun and starting the Scala project around 2003. I read a bit more about Odersky and found myself admiring him and his accomplishments. And then I found "Programming in Scala, 2nd Edition" had just been printed. I ordered it, the physical book and ebook version from artimadeveloper. I got the .pdf, put it on my iPhone and started reading it. And I have not put it down since. That was three weeks ago.

Back to my Whys and Hows:

So, that brings me full circle. I still want to port my game app. And I still want to do an iPhone/iPad app. And I found out that Scala is currently being worked to target the .NET CLR (it already targets the Sun JVM). So, if it can target the CLR, and I can get MonoTouch to take the CLR output from Scala and compile it to Objective-C (I know this is a stretch...still lots of work to figure out if this is even possible...I don't know the limits yet), I can use Scala to author those iPhone/iPad apps. And that will make me UBER happy as I will have maximized my new language learning investments across the spectrum.

So, I intend to post here about my slow but sure process of leaning Scala by programming with an imperative (as opposed to functional) style in Scala on basic starter applications. And then through comments, coaching, cajoling and debate, I hope to quickly hone my skills at seeing how to begin to understand and integrate functional programming into my existing OO knowledge. I am hopeful this creates a nice "default pathway" for those that decide to follow this same path, a gentle approach to first getting Scala's syntax by just converting straight Java to Java-in=Scala. And then little by little (certainly much slower than the way it is presented in "Programming in Scala, 2nd Edition"), I will make the adjustments and leaps to incorporate new concepts, revisiting the code I've already written imperatively.

Feedback loops are essential to effective adaptation:

So, don't be shy. Comment away. Tell me I'm being silly, distracted, ADHD, ABM (Anything But Microsoft), ABA (Anything But Apple), arrogant (invent a programming language, are you KIDDING ME?!), etc. The other purpose of this blog is to learn of others who share my frustrations. And or to learn of frustrations others are having so I might discover they are undistinguished frustrations I am also having, but have not had the time or focus to put the words on them myself. And thank you for anything you contribute. I can only grow and learn from whatever it is you choose to share.

Next Post:

I will present the (cleaned-up) self-email-chain which lead me to begin exploring Java/C# alternatives, identifying the parts that are already present in Scala, planned for Scala or if still relevant, posed as requests for enhancement to Scala. I am not so presumptuous to think my thoughts were so well thought out as to be able to really be integrated into Scala. However, what I recorded was my personal pain points in using Java (1.6.0) today (well, as of 2010/Dec).