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?

10 thoughts on “Talk Less, Do More”

  1. Or try Scala: http://www.scala-lang.org/

    OOP+Functional Programming
    Static with Type Inference
    Operators are methods so you can override them or define your own.
    “{}”, “()”, “.” and “;” can frequently be omitted.
    Simple property syntax.
    Plus closures, traits, mixins, actors, etc.

  2. I’ve done some functional programming in the past, not Scala but OCaml. And although I found it elegant, I never thought of it as a mainstream alternative because functions are not an intuitive way to model real-world problems. I’m not saying it’s not a good way, I’m just saying that it requires a special mindset.

    On the other hand, Groovy seems much closer from what I’m looking for. The documentation is a bit messy, but I’ll give a try to “Groovy in action”.

  3. As well as Groovy and Scala, the newest beyond Java language is Fan – http://fandev.org

    Groovy moves from Java’s static type system to a dynamic one – fine if thats what you are looking for.

    Scala moves from a focus on OO to a focus on functional programming – fine if thats what you are looking for.

    Fan aims to hit that sweet spot of a pragmatic, evolution to Java – its one I’m keeping an eye on.

  4. I think the real problem with scripting languages is that there are not enough companies committed to train their developers to code well. In my opinion, if you have to rely on language features to enforce encapsulation, then the problem is between the keyboard and the chair.

    Being able to change the mindset about software development training, learning path and expertise is, imho, a far better solution to the problem you are mentioning than throwing some technology at it.

  5. Of course the problem is between the keyboard and the chair. It’s always been there. And IMHO our jobs as software creators has always been to reduce the distance between the computer and the guy sitting in front of it.

    Then you can reduce the distance from both sides, and both approaches are complementary, not mutually exclusive. As far as I’m concerned, I love it when technology takes care of boring and boilerplate stuff for me. It can’t take care of everything of course, but we’re still far from it, aren’t we?

  6. When you don’t have the accessors qualifier barrier, you can see a lot easier if you are making unnecessary coupling between two objects, you should be reversing the method call direction adding a method to transform the Item into something renderable by the user interface (or something in-between), when you have a get and set, you are only making your implementation public, thus coupling with everyone who uses the object, it’s just a little better than making everything public as you are at least giving a gateway for access.
    I really like your blog
    Saludos desde Argentina!

Leave a Reply