So I'm diving into dynamic programming with Groovy and I love it. I consider myself an expert Java & C++ programmer, but I'm definitely having to do some re-learning with dynamic languages. I think its like when you encounter someone who, for some reason or another, really doesn't grasp object oriented methodologies. Its a way of thinking and designing your software that you really just have to understand. I think programming in dynamic languages, while very different, follow the same learning process. And I'm definitely in it.
So lets start with closures, probably the most verbalized features of dynamic languages.
Obviously the most famous is iterating a list. Lets say I want to print out every element in a list... obviously I could do the following in straight java.
Vector list = new Vector();
// add stuff to the list
for ( Object x : list)
System.out.println(x);
In groovy I can do:
def list = ["one","two","three"]
list.each { println ${it}}
The idea is I actually pass the list a segment of "code" to execute on itself. But wait, it gets better.
Lets say I want to create a function that will do something n times... easy in Groovy:
def doSometing(number, Closure c) {
0.upto(number) {c}
}
// now you can call the method like this:
doSomething (4) { println "Say Hello" }
Pretty smooth huh? Obviously the possibilities are endless and, possibly dangerous. When passing a closure to an object, you basically give it permission do do whatever it wants
class Hello {
String name
String important = "DON'T CHANGE"
def Hello (name, Closure c) {
this.name = name
c()
}
}
I can then create a Hello object like this
def h = new Hello("Jonathan" ) { this.important = "BAD"}
And the Hello object's important field will be changed, even if I make it private. Makes it a little difficult to create well-formed and protected libraries.
Friday, April 25, 2008
Thursday, April 17, 2008
grails and the nulls that confuse me
Recently I've started doing a lot of my work in groovy. Being an old fart I love my java, but many of the young guys are pushing me to pick up the dynamic languages of the times. I'm not a fan of Ruby (mostly due to the community, you know who) and while I like Python it just doesn't fit for scalable enterprise systems.
Then I noticed groovy, and I love it. I have all the power of java with the syntactical candy of dynamic languages. And Grails is really awesome (especially the 1.x series). Its like Ruby on Rails, but made by people who really want to use it in production. I can write groovy code, and use hibernate, and run on top of a clustered Jetty with terracotta, how cool is that?
I do have to say, its the little things that get you. A good example is GORM and exception handling. In EJB3 or even straight hibernate, when I save an object that doesn't validate I'll get a java.lang.RuntimeException. Example
Person p = new Person();
p.setName("something Bad);
entityManager.persst(p);
If for some reason p isn't able to be saved by the entity manager a runtime exception will be thrown. Being a seasoned EJB developer I'd use this exception to my advantage and let it trickle out to the container and roll back the managed transaction (I think this is beautiful, but I guess a thing of the past).
Groovy, grails, and even rails does this different. The way you know an entity is saved is by the return value on the entity.save() method. Lets use the example above in grails.
def p = new Person(name:"something bad")
p.save()
if for some reason p is unable to be saved we won't be notified by the above code, you actually have to do it like this:
def p = new Person(name:"something bad")
if ( !p.save()) { p.errors.each(log.error(it))}
What I find fascinating about this example is a statically typed language is actually less code than a dynamic one!
Then I noticed groovy, and I love it. I have all the power of java with the syntactical candy of dynamic languages. And Grails is really awesome (especially the 1.x series). Its like Ruby on Rails, but made by people who really want to use it in production. I can write groovy code, and use hibernate, and run on top of a clustered Jetty with terracotta, how cool is that?
I do have to say, its the little things that get you. A good example is GORM and exception handling. In EJB3 or even straight hibernate, when I save an object that doesn't validate I'll get a java.lang.RuntimeException. Example
Person p = new Person();
p.setName("something Bad);
entityManager.persst(p);
If for some reason p isn't able to be saved by the entity manager a runtime exception will be thrown. Being a seasoned EJB developer I'd use this exception to my advantage and let it trickle out to the container and roll back the managed transaction (I think this is beautiful, but I guess a thing of the past).
Groovy, grails, and even rails does this different. The way you know an entity is saved is by the return value on the entity.save() method. Lets use the example above in grails.
def p = new Person(name:"something bad")
p.save()
if for some reason p is unable to be saved we won't be notified by the above code, you actually have to do it like this:
def p = new Person(name:"something bad")
if ( !p.save()) { p.errors.each(log.error(it))}
What I find fascinating about this example is a statically typed language is actually less code than a dynamic one!
Subscribe to:
Posts (Atom)