Tag Archives: python

Top 5 reasons why you should consider Groovy and Grails for your enterprise software architecture right now

I’m so amazed when I see how so few companies are using Groovy and Grails right now, and are still using old stuff like Spring and Hibernate, that I thought I would jump in and do my share of educating. And why not give in to the fashion of top lists while I’m at it? So here it goes: if you are an enterprise software architect and you have a lot of Java in your world, you might want to read carefully what follows.

Continue reading Top 5 reasons why you should consider Groovy and Grails for your enterprise software architecture right now

Talk Less, Do More

I’ve been a Java developer for almost 8 years now, I’ve used many frameworks and tools, Spring, Hibernate, EJB’s, Swing, etc. And a few years back, I started to look for a less verbose way to express concepts like business entities, services, workflows and so on. For some time, Model-Driven Architecture (MDA) has been the best answer I could find. But the learning curve and the difficulty to customize transformation patterns for specific setups, like a Flex front-end on a Spring back-end for example, have made me realize that this approach was somewhat limited by its UML foundation.

So I started looking for a better answer, and I thought I had found it with Language-Oriented Programming, the idea to decouple the structure, the syntax and the semantics of a language and ease the creation of Domain-Specific Languages in a very generic way. Unfortunately, as promising as it looks, it’s still in early stages of research and development and I needed a more immediate way to improve my productivity, my ability to do more with less words.

So I came back to something I had totally pushed aside till then: scripting languages. I’ve been “raised” with strongly and statically-typed languages since day 1 of my programming carrier: first Pascal, then Delphi, C++ and Java. And I always thought that scripting languages like PHP, and later Ruby were just tinkerer stuff for lazy hobbyist programmers, that didn’t take into account constraints like maintainability, robustness, readability, performance, etc. All those constraints I faced as a professional consultant. But a few weeks ago, I started to question my certainties and began wandering around PHP, Ruby, Python and others.

PHP, I’m using it at work on You And The World, it’s too hard to debug in a Flex/AMF setup and it’s really too permissive. As for Ruby, I like the ability to design DSLs but the syntax is definitely not intuitive enough for me. So now, I’m trying to learn more about Python, whose syntax seemed more familiar and maturity is reassuring. Everything seemed good until I read this single sentence in the documentation:

[…] classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to “break into the definition.”

Come ooooon! Politeness of the user? You must be kidding right. In a corporate environment, when your code is likely to be reused and shared and refactored? I thought “hey, that’s probably just a provocative way to say that we Java developers tend to overdesign, and I know it’s true… so let’s read on…”. But unfortunately it proved to be much more than just a provocative sentence, since a few lines later:

In fact, nothing in Python makes it possible to enforce data hiding — it is all based upon convention.

OK. It took me a while to accept the argument that static typing can be too much of a cost in terms of verbosity compared to the poor protection it offers in terms of code correctness. But I said “OK, we’ll see how it looks when we come to real code”. But now they want me to forget about encapsulation too! What is the purpose of even writing a class then? What are you describing? A library of functions with a hidden first parameter? Is that it?

I mean, typing might be a unnecessary hurdle when writing unit test becomes much easier, but giving up on the behavior/state balance, the ability to describe what a class can do AND what it looks like, this is too much to ask.

So now what? Am I stuck between two extreme alternatives: either describe everything and waste energy doing it, or describe nothing a pray/ask for politeness?

And then I thought about LOP, and this interesting idea to decouple structure, syntax and semantics. After all, programming languages have entangled those three aspects for decades. And now both mainstream platforms (Java and .Net) are offering a variety of languages running on the same Virtual Machine. Isn’t that a first step in decoupling syntax on one side, structure and semantics on the other side?

Suddenly I’m starting to dream of a new syntax, far less verbose than the one of the Java programming language but with the same rigorous Object-Oriented structure, and the ability to run on all runtimes with different semantics…

What if the following Java code:

{code type=java}
public class TodoItem extends Item implements Synchronizable{
private String title;
public String getTitle(){return title;}
public void setTitle(String t){title=t;}

protected boolean done;

public TodoItem(String title){this.title=title;}

public void check(){done=true;}
}
{/code}

Could be rewritten like this:
{code}
+ class TodoItem > Item @ Synchronizable
– title
+ <-
return title
+ -> t
title = t

#done

init t
title = t;

+ check
done = true
{/code}

…or something similar ;o)

The key ideas being:

  • Keep all the key concepts of OOP: encapsulation, inheritance, polymorphism, composition
  • Remove static type declaration: I don’t care that my hammer has a wood or a steel handle, but I need to know it has a handle.
  • Replace long keywords by well-identified signs
  • Replace “{}” and “;” by indentation (Python-like)
  • Add simple property syntax (I love the way ActionScript does it)

In other words, I’m looking for a middle-path alternative between Java and Python, between waste and pray, between overdesign and politeness. Does anyone know of a language that offers that kind of compromise? Does anyone know if it has already been tested but has proven to be a dead-end for some reason?