How I Learned to Appreciate and Enjoy Groovy

Posted by Jim Jagielski on Monday, February 9. 2009 in Programming

As most people who know me know, I am a big fan and user of scripting languages. There are just so many places where they not only make sense, but are the only logical solution to the problem. My recent preferences have been Python and Ruby and PHP and Perl, and they've been enough. At least, up until now. At SpringSource, I and my team been working quite busily on software products, and one area which tied all the pieces together was a front-end installer and various post-installation scripts that provide additional capability. Now historically we would use Perl for these scripts, but an additional requirement was on the product: assume a bottom-line dependency of a Java JVM. This meant that Perl was out. Now of course, I could still do this in Python or Ruby (the languages) but that the implementations would need to be the Java versions (Jython and JRuby, respectively). So I could still script in one of these languages, I would simply compile them and ship the class files for the scripts (jar-ed up, of course). So there was no real problem. I did some prelim testing and was somewhat disturbed to fine that Jython was somewhat old but happy to find that JRuby was quite up to date and, from my testing, very, very robust. But SpringSource had recently acquired G2One, and so, in the logical interests of eating our own dogfood, decided to take a look at Groovy. I'm glad I did. My first mistake, unfortunately, was looking at it as a "version" of Ruby. Although there are numerous similarities, there are also enough differences that programming Groovy requires you to, at a very low level, keep your Java thinking-caps on. For example, you need to concern yourself more over actions that would cause an Exception in Groovy, whereas Ruby would just "do the right thing". In this way, I discovered my 2nd mistake: ignoring the fact that Groovy *wants* to maintain a Java-like consistency. In other words, I was looking at Groovy from the standpoint of a "traditional" script monkey, and not from that of a Java-monkey would wanted an extremely robust scripting language that removed like about 98% of the normal pain in programming in Java. When I got my head around that, then foo = new Fee() made more logical sense than foo = for example. So I've added new language to my scripting belt. And, I'll be honest here, it's made me enjoy Java programming more than ever.

Spring Python

Posted by Jim Jagielski on Friday, September 5. 2008 in Programming

Lots of people like Spring. The only trouble is that a lot of people also don't like Java. They would love to be able to use Spring but don't want to make the leap from their favorite scripting language. Well good news, especially for us Python fans. The latest version of Spring Python is now available. The real cool thing about this is that Spring Python is now an official Spring Extension with this latest release. Spring Extensions are a way of extending and enhancing Spring and Spring-related addons with the official help of SpringSource. It's sort of like a mini-Incubator for SpringSource. Anyway, I'm looking forward to diving into Spring Python. Looks like fun!

Enterprise worthy

Posted by Jim Jagielski on Saturday, August 16. 2008 in Programming

Due to both my interests, as well as projects at work, I go thru phases of using various languages. Lately, it's been a C, PHP and Java cycle. It's amazing that of the 3, Java is the only one that most people consider "enterprise worthy". For PHP, I think it's mostly due to its association of being "just" a server-side language. People forget that you can write standalone PHP applications, which is a darn shame. I'm not saying that PHP is better suited for such tasks than Python or Ruby, but it is pretty rare to see PHP apps that aren't assumed to be running in a web environment. Be that as it may, as anyone even remotely familiar with various social networking sites (and others) know, PHP is certainly more than capable of being a cornerstone of an enterprise worthy implementation. Now C is very different. Most people don't write applications (web applications, that is) in C, and yet most of the entire service infrastructure (OS, various protocol daemons, utilities, etc...) is programmed in C. So how can C not be enterprise worthy, if it provides the underlying foundation for enterprise apps? And yet people deride C, as if it is somehow quaint and yet also stupid to "dirty your hands" with C, simply because C requires the programmer to have a better understanding of how hardware is actually implemented and how software and hardware interacts. I've met many "professional" programmers who have no idea what "native word size" or "indirect addressing" means, and yet optimal and efficient programming depends on these, and other, constructs so much. Instead, the glory is saved for precious "programming patterns", which have their place, to be sure, but are not the be-all and end-all. And so we come to Java. IMO, there is nothing within the actual language itself which makes Java enterprise worthy. Instead, it is the vast supporting infrastructure which does so, as well as the results of years and years of external forces "convincing" people that Java is the (only) way to go. Unless you think otherwise, consider how crucial RoR was to bringing Ruby to the forefront. Now imagine if Ruby (or Python or whatever) had the same sort of supporting infrastructure that Java enjoys, and Java had none; in that case, Java would be considered the "toy", the "fringe player" as far as enterprise apps. IMO, enterprise worthiness is more a measure of the talent of the programmers, developers and architects, and not the language itself.

To understand a language

Posted by Jim Jagielski on Thursday, June 26. 2008 in Programming

Each language has its own personality, advantages, warts and inconsistencies. But each also seem to have an almost singular aspect that, if you really wish to be proficient in the language, you must know really, really well. Here's my list on my top 4:
  • C: pointers
  • Python: name space rules
  • Java: Interfaces
  • Ruby: Ducking
Of course, this is far from complete, and "expertise" in each topic doesn't imply expertise in the language itself, but without getting your head around these, I feel that you are limited by what you can do.

Page 10 of 11, totaling 54 entries


Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!