Tuesday, June 11, 2013

Java's problem is that Jidigava idigis gididibidigeridigish

I posted a while back about how ruby's syntax is better for designing software than java because it removes extra language cruft and enables developers to write more succinct and direct code. A common response to this from detractors is that "it's only three extra characters" and "my IDE can automatically generate that code for me". Sitting at the train station today reading a comment from someone that said something similar to "geeze, if you've got thousands of lines of code, why do you care about a couple of letters and a parenthesis or curly brace here and there?". I started thinking about why I care and discovered the reason: With those little three letters here and there, your code literally becomes a type of Gibberish

In gibberish, you use simple rules to add extra characters here and there (sounds familiar) to create and quite confusing language that is a 1 for 1 direct translation to/from english. While gibberish, pig latin, and other language games are entertaining past-times to kill summer afternoons and baffle outsiders when you converse using them, MOST folks wouldn't subscribe to The New York times translated into gibberish. More importantly, almost nobody would agree that writing a blog post in gibberish is worth the effort. So java programmers, instead of arguing about how "it doesn't matter", lower your defenses and look around at alternatives available to you (there are a lot).

As a graphic illustration (and a bit extreme, I admit), the first sentence of this blog post translated to my best attempt at idig/adig gibberish:

Idigi pidigostiged idiga whidigile badagack adigabagout hadigow ridiguby's sidigyntadigax idigis bidigettidigetter fidigor didigesidigignigiging sadigoftwidigare thatigan jadigavadaga bidicadigause idigit ridigemidigoves idigextridiga ladigangidiguage crididguft adigand idigenadigables didigevidigevladigopidigigers tidigo wridigite madigore sadiguccidiginct adigand didigiridigect cadigode.

I'm pretty sure the "plain english" version is probably better to communicate an idea if the intent is to communicate clearly. The only thing I did to render that above sentence was add "idig" or "adig" after the initial consonant of each syllable and put it at the front of the vowel for syllables that start with a vowel. This is very simple and we could probably create a word plug-in to make it super easy to translate normal english to gibberish with the click of a button.

That having been said, if there was a subculture that wrote and spoke exclusively in gibberish, wouldn't normal english speakers/writers also question their choice of languages? After all, it's adding extra syllables and letters that don't provide any direct value. In fact, the whole value of gibberish (other than entertainment) is that it's MORE difficult to understand, why would we ever argue that this is a good thing or "Not a problem (tm)".

Thursday, June 6, 2013

Software is design, how ruby is better for that job than java

As a long time java developer and ... well ... at this point also a long time ruby developer, I've found some things about the ruby language are much less bothersome than in java. Groovy takes an interesting middle road, but only gets about halfway in my mind. I'll leave the runtime differences and the dynamic/static compiled/interpreted debates for other forums and just focus on the Focus on this one irksome quirk.

Property Accessors are too verbose

Java Definition
class Car {
    private Color color;
    public Color getColor() {
        return color;
    public void setColor(Color color) {
        this.color = color;
and to use it:
Car car = new Car();
Color blue = car.getColor();

The whole getter setter thing is a pain to me. The bean pattern used by java is just overly verbose. For all the OO purists, I get it, we need to hide the private variables and put them behind methods to abstract away the inner structure, but I'm so weary of 3x lines of generated code to accomplish this.

Groovy (1/2 way there)
class Car {
    Color color;
or (if you need to override a behavior):
class Car {
    Color color;
    public void setColor(Color color) {
        println color
        this.color = color
and to use the class (either approach) the syntax is much better:
car = new Car();
Color blue = car.color
car.color = blue

In the first groovy example above, the actual class implementation is identical to the java example. It is much cleaner and obviously easier to read because it's missing all the cognitive overhead of explicitly defined methods, parentheses, and other java doodads.

In the second example, we've added some code to print the color to the console in the setter and still written fewer lines of code. This both reduces our typing/typo load, plus reduces our "100 lines of getters and setters" overhead. So, good marks to Groovy for striking a middle ground and allowing developers to do the easy stuff the easy way and only imposing the java crazy syntax tax :) when it's necessary.

class Car
    attr_accessor :color
and to override the set color method:
class Car
    attr_accessor: color

    def color= color
        puts color
        @color = color
and to use it
car = Car.new
blue = car.color
car.color= blue

While perhaps a little implicit, one might think that there weren't any methods at all, it looks like you're just setting and getting values. The advantage of the ruby approach is that when you change the underlying implementation, you can still use the simple syntax much like looking at java properties, but when you NEED the complexity of hiding things behind a method... you can do this you still have method declarations that are symmetric with how you call them.

One thing I hear over and over on this regard from die hard java folks: "But mike I can just use a tool that will automatically generate all that boilerplate and even automatically refactor all the names, so this isn't an issue". I disagree, what they're really saying is that there is a workaround they feel "isn't a big deal" to minimize the impact of this wonkiness, but I feel this is a broken window that is a foundational problem with java based solutions.

For detractors, let me start by stating that is is my opinion that all programming is design. If you disagree, then we probably won't be able to come to an agreement on the following statement, which is: "The most important part of a programming language is its ability to convey ideas clearly, succinctly, and unambiguously to other developers". The problem with java (and many other languages) is that it isn't designed to convey ideas to developers, its design instead seems intent on conveying instructions to the computer than it does to convey ideas to other developers. The ruby approach, in this regard, is much better.