views:

179

answers:

1

Like most professionals in the area of software development, I'm always open for learning new technologies/frameworks that might improve productivity. Relatively speaking, I'm still a novice in the area(3-4 years of experience) and my first contact with software development was in the .NET plataform with VB.NET language. At the time I had a very simplified view of software : Using Visual Studio 2005 was the only way to write/build software. The autogenerated ADO.NET classes hid all the "complexity" of accessing a database and with no understanding of how things happened "under the hood" made me a hostage of that environment. Problems were impossible to debug and most of the time I needed to follow step-by-step tutorials to solve them.

As the time passed, I felt that if I was going to work with software, I needed a better understanding of it so I started expanding my knowledge of C#/.NET and eventually wrote my first mixed C#/C++ programs. Ironically, it was this Microsoft technology that made me switch my working environment from windows to linux(through the mono project) which I can't live without today. The learning curve was hard, but messing arround with linux/C gave me a much better understanding of how operating systems/computers works than in Windows/C#. It was only after I wrote a few unix C programs that I really understood the need of languages like C#/Java that provide useful services like platform independence/automatic memory management while also providing decent performance(not that this seems to matter much these days).

Maybe its just me and my need to understand how things works, but I felt really 'at home' when writting C(and even a little assembly) code. Of course I can't use C for my daily work, but I felt that by understanding a little more low level computing I became a better C# programmer.

These days I use Java for the majority of my work. I think of the JVM's simplicity compared to the CLR as an advantage. Plus most of the advantages of C# over Java are nothing more than syntatic sugar(if you don't believe me, try decompiling a C# program that has a lot of linq/lambda expressions).Java seems to have more control over its loading process than .NET(In my opinion, the only real advantage of CLI over JVM is the possibility of running multiple isolated programs in the same process through appdomains). Last week I started a web project and as a learning experience I decided to use groovy/grails. To those that don't know, groovy is a dynamic language that when compiled produces JVM compatible bytecode, and grails is a web MVC framework that is built on top of groovy and other JVM technologies like hibernate, spring. In less than five minutes one can build a fully working CRUD web application, so its productivity is unquestionable. I don't know if its just because I'm not used to dynamic programming, but I'm really unconfortable when programming in groovy. Its flexibility actually makes me very confused sometimes: While it supports a most of java syntax rules, almost none of those rules are enforced, and if you write groovy programs using a groovy-like style, they look nothing like java programs. Its like theres no rules in the language and I kept wondering if thats really a good thing. The following snippet is a simple groovy program that prints a string

class groovyprogram {

    static main(args) {
        def n = 5
        def s = getString(n)
        println s
    }

    static getString(n) {
        "hello ${n}"
    }
}

This is the Java equivalent :

public class javaprogram {   

    public static void main(String[] args) {  
        Integer n = 5;    
        String s = getString(n);    
        System.out.println(s);
    }

    static String getString(Integer n) {
        return "Hello " + n.toString();
    }
}

The above Java code is also a valid Groovy code. Here's another groovy version that produces the same output :

class groovyprogram2 {

    static main(args){
        def n = 5
        println ("hello ${n}")
    }
}

Or even :

def n = 5
println "hello ${n}"

The following, even without producing any output, is a valid groovy program :

"hello world"

Since all groovy is compiled to JVM, the groovy compiler does a lot of magic under the hoods. The above example will probably be compiled into a Java class containing a method that returns the "hello world" String. In truth, the compiled class has a LOT more than a method that returns the "hello world" string. Try compiling that code and then examining the generated .class file in eclipse, you will get scared on how much bytecode groovy generates just to make that groovy code behave like a script.

I'm wondering how helpful this syntatic sugar really is. Does it really matter not having to declare the Type a method is suposed to return? Will anyone get more productive by not typing semicolons at the end of statement? What about optional parentesis for passing method arguments?

In my opinion think that groovy's lack of standards makes it very difficult for a programmer to follow coding patterns. Any C programmer can easily understand any language that follows a C like syntax. Its really fustrating when you see a lot of groovy samples that follows Java syntax and then you stumble upon the following :

def list = {
        params.max = Math.min(params.max ? params.int('max') : 10, 100)
        [airlineInstanceList: Airline.list(params), airlineInstanceTotal: Airline.count()]
    }

This is a sample groovy code that gets scaffolded by grails.

In my current project I'm loosing a lot of time trying to debug some simple unit tests that throws obscure groovy exceptions that never happened with the old Java/EasyMock combination. Probably next week I will start the project using my old JEE environment using plain Spring-MVC/Hibernate with a lot of beans configuration files. After these experiences I think that theres a limit in the level of abstraction an activity can have to be called software development, and I don't feel that a software developer is complete unless he can completely control/debug his environment. I posted this so I could hear people's opinion about this. Does anyone else has the same kind of troubles with these really 'high level' environments?

+6  A: 

This question is very subjective, so I can only give my own viewpoint, but on the whole - not really.

So long as I can unambiguously tell what some code is going to do, high-level isn't a problem. In fact, it's a positive benefit - if I can accurately communicate my intentions to the compiler/runtime in one line of code (your last Groovy "Hello World") rather than twelve (the Java version) that's going to be quicker to write, will ceteris paribus contain less bugs, and will be easier to understand when it come back to it in future.

So no - appropriate abstractions are what makes modern software possible. The only time it's a problem is when there's "too much magic"; where too much loosely translates to a situation where it's difficult/impossible to know for sure, just by looking at the source code, what's being done for you.

I know that your Groovy examples were deliberately short and basic, but to my mind they are not examples of "too much magic" but on the contrary represent "reduction of boilerplate". By removing all of the uninteresting, "nothing to see here" code they let one immediately focus on the important parts of the program.

Andrzej Doyle
+1 for second paragraph
delnan
+1 for third paragraph.
Matt Joiner
+1 for fourth paragraph
seanizer
+1 for the general concept of "whatever helps the programmer convey his intent".
RHSeeger