Last night’s panel discussion “The Language Debate” hosted by OTUG was fun. There was a lot of good discussion both during the panel and after the event. Charles Nutter, Robert Fischer, and Paul Cantrell were all great panelists.

One thing that often comes up in the static vs. dynamic discussion is the question of maintainability: With the lack of static typing, can future programmers look at a piece of code and understand what is happening in order to efficiently maintain that code?

My response (though I’m not sure it came off as clearly when I mentioned it last night) is that “With Power and Flexibility comes Responsibility.” That is, dynamic languages allow you to do many things that static languages typically do not. Whether to use certain features, however, is a different matter. The developer has the responsibility to make sure that the code is readable and understandable. This is why so many developers appreciate good design and the use of design patterns. When it comes to maintainability, this is no different than static languages. I have seen both beautiful and horrific code written in each type of language.

That’s why having good developers matters so much. To build good software, people need to think about what they are doing and why.

Aside from static typing, other features common to many dynamic languages also fall into this category of responsible coding. Metaprogramming is a big one often discussed lately and it wasn’t left out of the discussion last night.

My favorite quote of the night:

Code is an Information Design Problem
- Paul Cantrell discussing code aesthetics after referring to Edward Tufte

My favorite points about static vs. dynamic languages (found from one of the links on the wiki provided by OTUG before the event):

- Many programmers have used very poor statically typed languages.
- Many programmers have used dynamically typed languages very poorly.

Thanks to all at OTUG for pulling this together.

Thursday, Thursday, THURSDAY! At the O’Shaughnessy Science Hall! See your favorite dynamic language take on the statics!

Ok, actually, The Object Technology User Group is hosting a panel discussion titled “The Language Debate: Panel Discussion on Dynamic and Static Type Systems in Programming Languages,” so it may be a little more low-key than a full-fledged smackdown, but it will definitely be good.

More info can be found at the OTUG website or the OTUG Languages Wiki.

This post is the first in a series of interviews of people we find interesting that we will post here on Refactr. We asked some questions of British software consultant, Marc Palmer, regarding his experiences working for Enotions Ltd. on range of Pepsico UK owned brands using Groovy and Grails. You can read his weblog at http://www.anyware.co.uk. UPDATE: Leer esta entrevista en español

REFACTR: You left school early (at 16) to start programming, how do you think that has made you a better professional? How has it hindered you (if at all)?

MARC PALMER: I left at 16 because I was desperate to get out of school. I found it very boring and was eager to work (with computers) as I had been programming since I was 11, and I was writing 68000 assembly language ATARI ST demos and dealing with hardware interrupts etc by night while going to school and being taught BASIC.

In terms of being a better professional, I think the advantage is simply about 5 years more commercial experience than other people my age who went through further education and to university. It enabled me to become a freelance contractor in my early 20s.

It may have hindered me occasionally in that many companies use “Must have computer science degree” as a silly filter on applicants for work, but I’ve had little time without work in the last 10+ years. I have always been a self-teacher and always try to do things better. You could say I’m a bit of a perfectionist ;-)

R: How did you get involved with Grails development and why?

MP: Early in 2006 I started on some of the Pepsico UK juice brand websites, using my own Spring and Groovy framework. It was quick and clean, but once I had time later in the year to try Grails properly, I was immediately sold - especially because of GORM. However at the time it lacked some things that would make development even easier, so I decided to get involved and contribute some small things in order to increase my understanding of it so that we could deploy sites with it eventually, which happened in Jan 2007.

R: You are giving a talk titled “Grails in the Real World” at Grails eXchange 2007. Can you give us a preview of what that talk will include?

MP: It will be quite high-level, talking about some of the five high profile branded sites we’ve done with Grails this year. It will cover some Grails basics as well as some practical tips and simple design choices employed when building some of the more interesting features of the sites. It’s not going to be a “let’s code this app before your eyes” kind of talk, there will be plenty of those I’m sure! I think what people really want to hear from me at the moment relates to our experience of commercially deploying Grails applications.

R: What do all the Groovy/Grails folks on this side of the pond not know about what is going on over in the UK and other parts of Europe?

MP: Well I’m a bit of a recluse to be honest; with work, Grails dev, working on our house and garden, and being with my wife and two daughters - I don’t get much time to be part of the “scene”. It seems like Groovy is getting some good coverage in Germany, no doubt due to the great work of Dierk Koenig and Sven Haiges. Over here in the UK generally I think people are rather slow to catch on, businesses are generally very conservative. The biggest thing I think people may not realise is how much work Graeme (Rocher) puts in to Grails and Groovy dev. The guy’s a coding demon.

R: What new language features would you like to see from Groovy?

MP: At the moment, nothing special in terms of features. Truly lazy valuated GStrings would be nice for making logging more elegant (no if (log.traceEnabled) …” needed).

What I do want from Groovy is high code coverage in regression tests, and stellar documentation. Far too much Groovy detail is stuck in developers’ heads. I want a definitive language reference, not a bunch of cobbled together wiki pages! Back in the day when I was teaching myself Pascal, “Oh! Pascal” was a bit like the “Groovy In Action” for Pascal - but it was the Borland Turbo/Object Pascal manuals with their detailed grammar diagrams and truly excellent writing that had me using every feature of the language and understanding every “corner case”.

I love Groovy, but at times I feel it is a murky catacomb of “corner cases”, and sometimes the principle of least surprise is violated and a monster jumps out and makes you sh*t yourself! Things are getting better, but Groovy is under-resourced. Someone needs to invest in a salary for a single experienced author to co-ordinate and write definitive documentation for the language. Wikis are fine but they are a cop-out - it’s what you do when you can’t be bothered / don’t have time to write documentation yourself.

R: What have your experiences with large Grails projects like PepsiCo and Tropicana shown you in terms of both the difficulties and successes of using the technology on large scale projects?

MP: Difficulties… well we were bleeding edge for a while circa Grails 0.4 and there were some painful moments, which meant the primary difficulty was convincing “Mr.Boss Man” that we were doing the right thing. Performance of GSPs was a concern for a while, but then Graeme and I did some profiling and made some good in-roads there, although there is more we can do in future. Some of our form handling requiredsome Grails improvements and some crafty coding. The few multi-page forms we have were a bit painful because flows weren’t implemented when we did the work.

In success terms… well we had 2 sites launched by early Feb after starting from scratch, with just me and an HTML dev working on the code. By June we had five Grails sites deployed, all gradually upgraded from Grails 0.4 to 0.5 to 0.5.6 smoothly. We were able to add new features easily including a blog, weather feed, “no frills” CMS for specific content elements, admin reporting on data stored by the sites (criteria builder rocks!), drawing of competition winners, high score tracking, e-cards and more. We often have hard dates to work to, where a feature has to be live to tie in with promotion or a new product launch, and we didn’t miss anything.

Seb - our HTML/PHP developer - loves Grails and GSPs/layouts. We now prototype rapidly, locally and reproducibly thanks to Grails’ built in web server, we can check out the whole app from SVN onto another server for the testing/QA department and it “just works”. It’s really helped improve our working methods.

R: In the past few years, a number of Java developers have taken to Ruby on Rails. Do you think as Grails matures, more of those developers will switch to Grails? Said differently, what does Grails need to do to win those folks back?

MP: Grails momentum is building. Moving to Rails is even more of a leap of faith than moving to Grails, so I think as awareness of Grails grows it will stop any hemorrhaging of Java people to Rails. In terms of luring people back… I think they may return by themselves when they realise all their favourite APIs are instantly accessible, and that they can get the tools and scalability that they were used to with Java, but without any of the pain.

We just need to keep driving up Grails’ profile.

R: With Grails 1.0 coming out soon, there’s an expectation that Grails adoption will grow rapidly because of the perception of increased maturity of the technology. What are your thoughts? What is getting you the most excited about Grails these days?

MP: Yes, I agree 1.0 is crucial. It is mainly psychological but 0.6 sounds so… lame compared to 1.0. Its also our guarantee that we won’t break stuff any more. That’s the killer for many people - with our five sites I didn’t really relish upgrading each one through the various Grails builds, even though each one was a great improvement. It’s OK with your own toy projects but when the customer is paying for your time and you have deadlines, upgrading to a new version of your framework is unattractive at best.

The most exciting thing for me about Grails is that its all coming together now. All the main pieces I’ve wanted to see are coming in - flows, rationalized config, ORM caching and mapping control, plugins, better documentation. We’re cleaning it all up and sanding off the rough edges so that it’s not just a productivity boost, it feels coherent and designed. The difference between a white-box PC and an iMac.

Oh, and there’s the future plans we have for some great plugins and other stuff in the pipeline…

R: Jumping feet-first into helping out with the Grails project may seem daunting to some. What’s the best way for people to get involved if they want to help?

MP: Yes, I was daunted at first. The best way to get involved I think is to check out the developer docs on the website which give a bit of an overview, then pick a simple looking issue from Jira and dive in to where you think it will be in the code - and ask on the dev list for the starting point. I found it very hard at first because, while IoC is a good thing, I find it can make applications very hard to fathom because its often not clear where your entry point is, what order things occur in and so on. To be honest there’s still some bits that make me scratch my head, and I don’t have time to fully investigate them at the moment - the flow of execution during GSP compile and rendering for example.

The great thing about Grails is that most of the core functionality has very good code coverage for tests. So as long as you run all tests successfully before committing, you can feel pretty sure that you haven’t broken anything. This is unit testing at its best because you can go in and work on little bits without worrying too much about breaking other things. Nothing more embarrassing than causing the continuous integration to spew a “Build Failed” message citing your commit! I should know, I’ve done it a few times.

If all your tests passed and it still broke something, make sure you write the unit test to prove this failure locally BEFORE you fix the bug! We love unit tests. The more the better. A project of this complexity would fall apart quite quickly without them.

R: Do you have any expectations/hopes/predictions for Grails development in 2008 other than what’s specifically on the roadmap (e.g. new features, etc)?

MP: I think that 2008 will be see rapid adoption, and with that primarily bug and compatibility fixes and performance improvements to 1.0’s core, and probably one or two point releases with new features.

Alongside I’m hoping for an explosion in high-quality plug-in development. Once you can drop in a blog, forum and authorization plug-in to your application and have it just fire up and work, for many users of Grails this will be killer. It will also open it up more to the non-Enterprise crowd. I am a firm believer, as this is where I sit currently, that Grails is brilliant for building web sites, not just web apps.

Not being a computer scientist by training, I don’t know whether or not people hear stories like this when they study computer science in school. Either way, I always get a kick out of them: The Parable of the Two Programmers.

Coming off a presentation of Grails to the Ruby Users of Minnesota, Scott will be presenting again, this time on Acegi Security - a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Come on out to the groups new location: The Loring Park Dunn Bros in Minneapolis next Tuesday the 10th at 6pm.

Want to read up before? Here are some links:

http://www.acegisecurity.org/
http://grails.codehaus.org/AcegiSecurity+Plugin
http://grails.org/Acegi+on+Grails

Graeme has taken the time to respond to some of the comments floating about in the blogosphere about the performance of Grails vs Rails. This benchmarking comes out very favorably for Grails. In nearly every case, the requests per second and mean response time come out with Grails performing better than Rails. And in some cases, Grails literally blows Rails away (140 vs 35.5 requests/sec on the create test!!). The max response time for Grails is higher in nearly every test case, but this is completely understandable as Graeme points out. I also wonder if he took note of the fact that Grails is always going to be slower for the first hit, but over time will speed up due to the nature of the JVM.

It’s important to keep in mind that Grails has yet to be optimized much (or at all), whereas Rails has been around longer and has been optimized much more. This is the part that makes me feel the best, actually, because it means that there are probably a lot of places where relatively simple changes can improve the performance of a Grails app significantly. Add to that the fact that in Grails you can always drop down and write native Java to increase efficiency (vs. having to write C in Ruby/Rails) and I think it’s clear that Grails is at the very least on par with Rails and likely has even better performance characteristics.

Graeme responds to Charles Nutter’s thoughts on using the Ruby language (instead of Groovy) with the Grails framework. I think that Charles has some good points, but I agree with Graeme. With the resources available, let’s focus on continuing to add functionality to Grails itself.

I’m a huge believer in using the tool that best fits the situation, so I think the idea that Charles has about more freedom of choice regarding languages is completely reasonable - especially with the movement toward more languages running on the jvm. However, my preference at the current point in time would be to continue development of core grails functionality and consider integration of other languages down the road.

Marc Palmer has commented on the discussion as well and has some good points of his own. I highly recommend reading all three posts (by Charles, Graeme, and Marc) as they all have some great insights.

Do you live in Minnesota? Are you a Java developer? Are you interested in learning more about the “agile, dynamic programming language” that is Groovy? If so, you should check out the Groovy Users of Minnesota (GUM) group.

The group is brand spankin’ new and is having it’s very first get-together at 6pm on Tuesday, March 13th at The Coffee Grounds on Hamline Ave. in Falcon Heights (near Roseville and Larpenteur Ave.) (map). We plan to meet on the second Tuesday of each month, and have set up a calendar (iCal, XML).

Check us out and we can learn more about Groovy and related topics, such as the framework: Grails. We can all share our experiences, techniques, and knowledge to strengthen the rapid software development crowd here in Minnesota. Join us.

*Although we cannot promise it won’t happen, there will be an effort to refrain from trying to use the word groovy in a comical/cheesy** way.

**Humor, like beauty, is often in the eye mind of the beholder speaker/poster.

Refactr is proud to be the first company to be profiled by Garrick Van Buren as part of the MNteractive Podcast Profile series. In it, Jesse, Scott, and I discuss our experiences with agile software development, Groovy and Grails, and working without an office space. Here is a direct link to an mp3 of the interview.

I have been on too many projects where the discussions went way overboard (many times through my own causing.) It is so easy to fall into the trap of “let’s just discuss it quick” and one hour later still be debating the finer points of a relatively minor architecture issue. The truth of the matter is this happens more frequently for teams that don’t do pair programming. When pairing is used, the discussions tend to be shorter and you are generally still working while you are debating. So the question is, how much time should “discussions” take?

Here is a simple scorecard you can use to figure out if you have beat-the-horse-dead.

Tally your total points and see below

Now take your TOTAL answer and multiply it by 10 minutes. In the absolute worst scenario the discussion should only take 60 minutes.

If your TOTAL was zero or negative, you should be doing more development and less “discussing.” As a rule of thumb you should limit all design conversations to ten minutes, anything over is waste. If you find your conversations are getting out of control try some of these tactics to reel them back in.

• If you aren’t already pairing, do so. Sit down and pair for a few hours. You will get so much more done than having a 30 minute debate about if you should use polymorphism or delegation.
• Start a team decision maker baton. When you get hung up in a debate, it is the person holding the baton’s job to step in and make a decision. After the dispute is settled pass the baton to a new team member to solve the next problem. This way everyone at some point will be the final decision maker which will foster collective ownership.
• Remember winning the battle doesn’t mean you are winning the war.
• For 90% of you, relax and remember, you are just building a social networking app for teens. It isn’t pace maker firmware.
• Cite actual evidence; show patterns or examples of others in the industry that are doing it like you are proposing.
• Take precedence of a solid object model that represents your domain and reduces your complexity *** (I highlight this one because I think people sometimes take exception to it. Some argue if you spend time on a “solid object model” you are building more than you need right now. I argue it is generally as easy to build it the “right” way than to piece it together the wrong way. When there is a significant difference in time (hours) between “ways” choose the faster, (and I know this is many times at the heart of debate). If they are pretty close in time, (within hours) choose the one that reduces and cleans up your model. Performance should not come into consideration at all at this point.)
• Tell your partner this time we do it his way if next time he promises to do it your way.

I hope these few simple tips will help you save time and headache in your next design discussions.