Writing less code


Who said “There’s only really one metric to me for future software development, which is
— do you write less code to get the same thing done?”  Maybe one of the folks on lesscode.org who

practice the art of using less code to get more done. We shun
complexity and challenge the status-quo when it impedes our ability to simplify
our development tools and processes. We appreciate Python, Ruby, LAMP, REST, KISS,  

Uhh, no.  It’s the person often reviled  as a promoter of complexity and keeper of the status quo, our very own Chief Architect. [;)]



I mention this not only because the dilemma of simplicity is one of my favorite themes,
but because this came up in several conversations that I heard at PDC
about the new featues in C#.  The basic sentiments are stated pretty clearly by PDC blogger David Wheeler

But as with anything, the complexity that is added to this
language will require very careful management. …I spend a lot of time
working with developers that are new to C#, new to Object Orientation
and new to .NET. I feel that Lambda expressions, extension methods,
anonymous types and LINQ (Language Independent Natural Query) will be
concepts that they will find it difficult to grasp at the first
attempt.

C# 3.0 is reaching a point where a developer with only a few months
experience will be unable to read what an “advanced developer” will be
writing for, say, data access.

I
definitely heard a number of people moaning about
Lambda expressions in particular, which apparently can cause horrible
LISP flashbacks to those with less than fond memories of the ’80’s AI
hype wave. What was most interesting to me, however, was that in the
panel discussion on LINQ Friday afternoon, someone
asked about all the additional features being added to C# to
support XML, SQL, object-relational mapping, etc. and worried that
these features would undermine its essential simplicity. Anders
Hejlsberg responded much as Bill Gates did in the quote at the
top:  Think about all the complexity and tedium that the new C#
features removes from your application code, and weigh that against the
additional complexity of C# itself.  Anders went through a long
list of things that application developers will need to know less about
in return for learning about LINQ, etc. 


So far, and I say this after having spent the evening reading
dozens of blog entries on LINQ, it looks like a considerable majority
of the people who have been exposed to LINQ agree that it will provide
an excellent return on the investment to learn the new features. 
Remember, however, that the whole point of announcing all this at PDC
was to
get feedback, so by all means let Anders and others know about specific
features will cause you more pain than gain. 



In my opinion, adding infrastructure code that was designed and
implemented by the best people in the business then  exhausitvely
tested for years, but lets you write less code in an application, is an excellent tradeoff.


Comments (6)

  1. Joe Chung says:

    There is a balance to be struck between not compressing code enough (too fat) and compressing it too much (too skinny).

    Fat code is verbose code. Fat code means that there’s more code you can mess up. Fat code is easy to read, but there is more of it so it takes longer to understand.

    XML is "fat."

    Skinny code is less code. Less code, however, is not necessarily simpler code. When you make mistakes writing skinny code, those errors are magnified. Skinny code takes a short time to read, but it can be difficult to understand if it is too skinny.

    Regular expressions are "skinny."

    C# code to extract and manipulate data from relational databases and XML is "fat." C# 3.0 AND LINQ are attempts to make that code slimmer. That’s a good thing, but try not to make the code too skinny.

  2. Eric K. says:

    Tat’s definitely a refreshing thing to hear, particularly when you frequently hear from language designers about how "syntactic sugar"–shortcuts and additions that save the developer time and typing–is bad, defiles the purity of the language, and leads the developer down a slipperly slope to sloppiness, immoral behavior, drug use, and eventually Linux and PERL.

    Yeah, we’d all love a nice, clean, simple, pure language, but if I have to write several dozen lines to get something done that I think I ought to get done in only one, I’m going to get tired of it really soon.

    So many languages seem to have plenty of "syntactic salt"–hoops the developer *must* jump through just to prove that they know what they’re doing, additional steps that must be performed, that developers making use of these languages occasionally wonder if the language designers were sadistic or did they really just not see that developers don’t truly want to type for the pure joy of typing..

  3. doug orr says:

    reading through lesscode.org and what do I see? reference to mike champion as "one of the few remaining reasons left to respect microsoft…" I’m sure I could soften that for the present audience to, "an excellent reason to add to your respect for microsoft."

    I don’t disagree, really, but I hope someone on the panel pointed out all of the excellent facilities cobol and pascal had to make i/o more accessible to the masses. (I’m just sore because I think lambda expressions are great. 🙂