Writing less code

mikechampion — Mon, 19 Sep 2005 06:40:00 GMT

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.

PDC Day 2 - some details and reactions to LINQ

mikechampion — Thu, 15 Sep 2005 09:30:00 GMT

The high point of my day was seeing Anders Hejlsberg go through his presentation (actually it's more or a real-time code writing demo, with few slides) on LINQ. I had never seen him in person before this week, and the experience can only be called Shock and Awe. I had read this stuff, talked about it for hours, seen other presentations, but getting it from the source was really eye opening. If you are at PDC, I believe the talk is being repeated Thursday. Find out when and go!

A few tidbits I got from seeing it all in person: First, he was demoing the new type inference features of C# 3.0 and said something like "Notice that this looks like script, but is really strongly typed." It really does seem like the best of both worlds - the programmer productivity of not having to fool with all that tedious type declaration if the compiler logically could figure out the type, but the safety, performance, intellisense, etc. advantages of having the system be able to automate some of the tedium of typing and checking code. Also, Anders emphasized how this really is a much more declarative style of programming, even if it is hosted in an imperative language. This really could change the world -- taking concepts that are well-understood by SQL, XSLT, etc. programmers and making them accessible to people working in a conventional programming environment rather than a DBMS or XML.

The low point of the day for me :-) was when Anders was describing how XLinq addressed the numerous things he doesn't like about DOM, and Dave Campbell (the SQL Engine General Manager, hence my boss's boss's boss) pointed to me and said "it's all HIS fault". All kidding aside, I must say that it is humbling to see how much more elegant something can be when designed by one person with the knowledge and authority to make decisions can be, compared to DOM and XQuery which were basically designed by committee (remember Fred Brooks' chapter in the Mythical Man-Month about Conceptual Integrity). To be fair to my poor fragile ego, XLinq does reflect a number of hard-learned lessons from DOM, and builds on 10 years of advances in basic language technology. Newton is widely quoted as saying "If I see farther it is because I stand on the shoulders of giants." In this case it seems to be a giant standing on a big pile of us dwarves.

While almost all the reaction I've heard to LINQ etc. has been positive, there are a few interesting notes of skepticism ... partly that anyone can make the DLinq and XLinq pieces work in a fully scalable manner) (Michael Rys has a nice discussion of this), but also raising questions about whether it is really a Good Thing to give programmers who don't really understand the workings of DBMS systems the ability to go wild. I talked with Esther Schindler about this basic topic today, and came away with the impression that she thinks(something like, putting words in her mouth) we might be handing a 16 year old the keys to the family Ferrari and expecting him not to go too fast. Maybe having people who understand the strengths and limitations of a technology be the only ones capable of using a technology is not such a bad thing? That basic point has come up in a number of conversations, which might be summarized "our DBAs will NEVER let us use this, it's too powerful". I think those concerns are valid and interesting, but premature -- there is an IMMENSE amount of work to do before that will be a real problem.

Also, there's the inevitable question of how LINQ / XLinq / DLinq relate to XQuery. Just as SQL isn't going away on the data tier (DLinq generates SQL), XQuery won't go away as a database query language even when a mature LINQ -> XQuery mapping and code generation / optimization component is built, maybe someday. There will always have to be escape hatches for power users who need the ability to fine tune queries to be fast, reliable, etc. As for the client side, someone asked in a comment on yeserday's post whether this affects the likelihood that we'll ever support XQuery in .NET itself. I replied:

First, XLinq is a statement of a vision, not a concrete product plan. The idea is to get feedback from outside the rather small group that has worked on it so far. For example, it would be interesting to hear from XQuery fans on what XQuery does that LINQ doesn't, other than run on multiple platforms of course. Ultimately, decisions such as this are BUSINESS decisions; no matter how geeked up we might be about LINQ/XLinq, if the market wants XQuery they're gonna get XQuery.

So, let us know what you think the market is going to say ....

http://msdn.microsoft.com/netframework/future/linq/

mikechampion's weblog : XML Futures

Writing less code

PDC Day 2 - some details and reactions to LINQ