I am a software engineer at Google on the Android project and the creator of the Java testing framework TestNG. When I'm not updating this weblog with various software-related posts or speaking at conferences, I am busy snowboarding, playing squash, tennis, golf or volleyball or scuba diving. Cedric is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Lazy Programming

  • submit to reddit

This blog post shows some interesting data confirming some thoughts that I have harbored about dynamic languages for a while.

In a nutshell, so called “dynamic languages” seem to be more used because they allow you to type less than because they use really dynamic features.

Maybe it’s because static typing is so ingrained into my brain, but when I write something like:

def raise_salary(employee)

I really, REALLY, REALLY want to type:

def raise_salary(Employee employee)
My fingers are just screaming to add this type information. Same for local variables or return types. It’s in my head, it’s in my code, why can’t I just give this information to the compiler, the tools and to future readers and reviewers of this code? It’s really not that much to type and it buys me so much. Think about it: refactorings that are guaranteed 100% correct.

I know, amazing, right?

From http://beust.com/weblog/2010/12/14/lazy-programming/

Published at DZone with permission of Cedric Beust, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Eric Giese replied on Wed, 2010/12/15 - 3:34am

I do agree with you in that the compiler should get some hints about the types which are used, but I do not think this should always be the burden of the progammer. Why not use typeinference for this task? Just add some structural typing (GO, Scala, Haskell) into the mix and you have about 95% of the advantages of dynamic typing without ever sacrificing type-safety.

And the best part: You can still annotate types if you want!

I really want to have local type-inference in any language I use. On method signatures, annotating is usually best practice, so type-inferrence is not needed that much here. Maybe even Java will get it some day.. Interestingly enough, C# has gotten it with the last release.

Karl Peterbauer replied on Wed, 2010/12/15 - 4:16am

+1. Another example (from Ruby's IMAP library):

def self.add_authenticator(auth_type, authenticator)

What the hell is auth_type and authenticator? The answer is given informally in a lengthy comment:

# Adds an authenticator for Net::IMAP#authenticate. +auth_type+
# is the type of authentication this authenticator supports
# (for instance, "LOGIN").  The +authenticator+ is an object
# which defines a process() method to handle authentication with
# the server.  See Net::IMAP::LoginAuthenticator,
# Net::IMAP::CramMD5Authenticator, and Net::IMAP::DigestMD5Authenticator
# for examples.
# If +auth_type+ refers to an existing authenticator, it will be
# replaced by the new one.


Bottom line: The dynamic hype is insane.


Jess Holle replied on Wed, 2010/12/15 - 7:27am

For the longest time the web site for Scala's Lift framework noted that they could do all the Ruby on Rails examples while requiring 40% fewer tests -- as those tests were simply covered by the compiler thanks to static typing.

Also as per the Ruby example above, static typing can save you a lot of silly documentation.  For example, Java generics saved me loads of typing because I could simply express the full type of the complex collections (e.g. Map<Foo,Map<String,Collection<Bar>>>) rather than have to write numerous lines of comments trying to express the same point.  The fact that the compiler can enforce that type is immensely helpful as well, of course.

Sadsds Dsadsadsa replied on Wed, 2010/12/15 - 9:59am

another common reason for use of dynamic languages is its easier for non-professional developers to use - ie testers for example. They love being able to put together little tools. They probably started looking at something like Java and decided it was too much work to do simple things (which it is).

Jonathan Fisher replied on Wed, 2010/12/15 - 10:30am in response to: Karl Peterbauer

For any large amount of development, where you cannot have compiled the entire design in your head, you are correct.

Jose Maria Arranz replied on Wed, 2010/12/15 - 12:09pm

I absolutely agree with you Cedric, I can understand non-typed languages for (very) small projects but I hardly can understand what is the benefit of losing types, we are not code-monkeys stroking keys, coding is a careful task, coding implies minor or big refactorings for reusing and to accommodate new features. The minor gain avoiding types is the delay when you must to improve/review your code or any other's. 

Currently I'm refactoring a real time Java web application using ItsNat and strongly based on Comet. The program works fine but it has some concurrency problems because several web users must share on memory data and end users must be notified in real time (Comet). Concurrency is one of the hardest problems of software, to fix concurrency problems I need to improve the architecture to decouple and isolate the parts affected by concurrency.   

To perform reliable refactoring I'm using CONSTANTLY the Find Usages feature of NetBeans (any decent IDE has a similar feature, in fact this is not new for instance Microsoft Visual C++ has provided this feature 15 years ago). Without NetBean's Find Usages my job would be ABSOLUTELY PAINFUL and the risk of introducing bugs would be extremely high. As anybody can understand Find Usages and refactoring capabilities are only possible with STRONG TYPING.

Yes, an enormous number of tests can mitigate the lack of typing, but the hard fact is I don't need tests to refactor an application that works because refactoring by definition does not imply a functional change.

The application I'm working on is 90% Java and 10% Groovy, Groovy is productive and fine, really but it is a pain when you need to refactor it because the compiler cannot help you and NetBeans's Find Usages does not work, I feel like I don't have the control of this Groovy code (replace Groovy with your favourite non-typed language). I'm sure this 10% Groovy was very productive in the beginning but a problem in the end...

Some idea for Cedric: I think annotations could extend and enrich the compiler phase on development, for instance @Override is fantastic, new annotations and some kind of post-compiler processor could improve Java as language without breaking the compatibility.

For instance something like @Protected(packageAccess = false)... the sky is open.

This is a very easy task for a prominent software engineer like Cedric ;)  (I would like to do it myself but I have no time, any free time is spent in other things).


John J. Franey replied on Thu, 2010/12/16 - 3:43pm

Funny. This morning I was only thinking how lazy I am because I lean on the compiler to prevent type errors in my code. There is more work for me if I have to check compatible types for myself.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.