On the way to codeless programming

Published 28 November 03 11:49 AM | despos

Next week I'll be in the States to teach a Wintellect class in Tennessee. It's about .NET programming with VB.NET. It's with classes like this, apparently huge and pretentious in their effort to cover just about everything about .NET in 8x5 hours/days, that you understand the true sense of .NET. The framework is ONE. And supports different programming models--WinForms, WebForms, WebServices. I started in the early 90s with the Windows SDK and the Charles Petzold hefty tome and .NET is like a dream. Yeah, the childish dream of a shy junior programmer...

There's a trend in the evolution of .NET. A couple of weeks ago I was in Milan speaking at the biggest Italian technical event for developers (the WPC). In one of the jam sessions, one of the attendees made me the target of a gently rebuke about one of my statements. What did I say to deserve a rebuke? Gentle, but still a rebuke.

I said that Whidbey tends to make programming virtually codeless.

I was referring to ASP.NET programming and it's unquestionable that with ASP.NET 2.0 you need to write much less code to accomplish the same things. For example, look at the powerful combination of GridView and data source controls. You can easily arrange realistic master/detail views with no code at all. Unlike the codeless master/detail feature of Windows Forms (version 1.1), in ASP.NET you don't even have to write code to customize the appearance of the grid. (You realistically need to in WinForms)

However, the question here is: how much lack of code (so to speak) can realistic apps support?

Applications are still made of code. And programmers have been created (actually, instantiated and guess it happened after the canonical seven days of creation) to write code. No, I don't think .NET is going to starve programmers. I believe that codeless applications will never be a reality.

So emphasizing that Whidbey (specifically ASP.NET) largely reduces the code to write and approaches virtual codeless programming is technically incorrect?

All in all, the good news about Whidbey (and the MS trend) is that with the same effort you can now (actually, in 2005) build more powerful apps because you manage more powerful tools.

How do you feel about codeless programming?

 

 

 

 

 

 

 

 

Comments

# Frans Bouma said on November 28, 2003 06:16 AM:

"All in all, the good news about Whidbey (and the MS trend) is that with the same effort you can now (actually, in 2005)"
... does that mean Whidbey will be released in 2005? :)

(Yesterday I saw a presentation about asp.net 2.0, completely without writing any code... amazing :) (not always what you want of course, all those queries in the html, but still..)

Your presentation earlier in november in Delft/Netherlands was very good :)

# Paul Bartlett said on November 28, 2003 06:26 AM:

The quoted stats say, I believe, that ASP.NET apps could be rewritten with only about 30-40% of the code that is currently needed. This would naively suggest that the next generation of apps would be smaller. However, apps are seldom just rewritten, so I suspect that they will be just as big, but we'll be writing different code instead. Code which adds new or more powerful features, which in turn will probably be achievable via codeless techniques in the future.

I believe this is "a good thing" as users get better products, app developers get more interesting jobs to do, and language tool development (IDEs, compilers, etc.) continue to have more to offer with each new release.

# Phil Winstanley said on November 28, 2003 06:50 AM:

I think it will make things much easier for begginers, but the people who are good with .NET now will continue to know how it all works under the hood, which is very important to know when you want to do something that the controls and frameworks were not designed to do, we can have codeless programming, as long as we onl ever want to create applications that the frameworks will support ... otherwise it's going to be the same code that we're writing now.

As for the code reduction I think it's more like 70% if you take in to account the loss of control declarations etc.

# G. Andrew Duthie said on November 28, 2003 07:49 AM:

I agree with you that the codeless scenarios aren't necessarily the most important selling point of ASP.NET Whidbey. But they do make great demos, and they do particularly highlight the extent to which code *reduction* (as others have already noted) is a big theme of Whidbey.

Also very important to me as a developer is the removal of vast amounts of junk code that is needed solely by the IDE for maintaining the current brittle code-behind model. Having code in pages and code-behind modules that was not (and in fact should not) be written by or modified by the developer was a poor design decision that I'm very glad to see being reversed.

# Paul Bartlett said on November 28, 2003 08:23 AM:

Not wishing to be picky or anything, Phil, but rewriting with 30% of the code is a 70% reduction!

# Mike Parsons said on November 28, 2003 08:50 AM:

A recent statistic I read (can remember source right now) stated that less than 20% of code written every year is "new" code. Why is that?

It's because software developers like you and I always start off with the assumption that we can do a better job if we write it ourselves (which in a very small number of cases is actually true). Take for example the ASP.Net datagrid ... you still have to write a crap-load of code in order for this thing to be as functional as the datagrid that shipped with VB 3.0.

It amazes we that we are still writing code from scratch for things whose requirements have changed very little over the past 5-10 years. I say if we focused as much effort on creating useful applications as we did on re-implementing (or re-inventing) the wheel, we would have some killer "apps" out there.

But that's just my opinion :-)

# Douglas Reilly said on November 28, 2003 09:40 AM:

I think that one of the down sides of the code reduction is that, absent source for the framework, there are lots of times when you simply cannot debug a portion of the applicaiton. Lets say to have done lots of stuff using declaritive code. And you declare something incorrectly. How do you debug that, presuming what you have declared is not so invalid that the object created byt eh declaritive code throws an obvious exception? This is where I think the need for source code for at least the supporting code is essential.

For example, you can often do a lot of things in Delphi just using non-visual components (meaning, datasource controls, query controls, etc.). Not quite declaritive, because underneath it all, there is code being written, but it is transparent to most developers. If in fact you have a complex set of relationships between various non-visual controls, there is in fact none of your code you can debug. This is where having source (in the case of Delphi, the VCL Code that acts as a wrapper around the underlying ADO) can be a life saver. It may be that what you are doing is not reasonable, it may even be a bug in the VCL, but no matter what it is, you have a better chance of finding it.

# Jason Perry said on November 28, 2003 02:57 PM:

One thing that is really irratating me about ASP.Net 2.0 is that all that declarative programming is being called codeless. A line of declarative programming is a line of programming. I've seen no app written with no lines of code and I've seen similar demos claiming that, but there are still lines of code! Even if the IDE is writing the code, it's still being written. I think the move to more declarative code, especially when the code it's replacing is very repetitious, is a great thing, but there is no need to lie and say that there is no code at all.

# Shawn said on December 2, 2003 10:48 AM:

I've never been happy (in my 7 years experience professionaly, and 15 all together) with tools that do the job for you. Sometimes they have value. But overall, as a rules of thumb, the more I end up "relying" on some tool to produce x% of code for me I always have ended up needing to scrap it for some limitation at some future point of development. Perhaps 2.0 can greatly assist. 1.0 was great. Businesses will love it. Especially consulting houese. But I just can't see myself embracing it as a rules of thumb. Perhaps to compliment some of our work but that's about it. I can't see myself complimenting its work but in reality, they are designed for certain purposes and my business needs/requirements have always been of a different purpose.

While I've had many argue me fervently that I'll be out of a job while they are making applications, well, hate to say it this way, but, the level of productivity I enjoy is competitive with that of my peers. The point is that I know my stuff. I know how things work. I know what the problem is when it doesn't work. I know why things work well in this case and not in that. I understand win32, I understand .NET, I understand COM from an internal perspective. Put all this together and I know how to design, implement, debug, and maintain enterprise applications. I seem to be equally good in all those areas.

Relying on code generators and things that do my job for me only tips the balance, although I'm not narrow minded. If it'll help me get to point B I might give it a try. Just wait until I have a complicated requirement that the "automatic" stuff can't handle "easily" and it'll go out the window.

Thanks,
Shawn

# brady gaster said on December 2, 2003 03:42 PM:

Dino, there's an EXCELLENT article in last month's issue of the MIT technology review regarding some pioneers of this area. The article can be found here - > http://www.techreview.com/articles/tristram1103.asp

# Shawn said on December 3, 2003 11:57 AM:

I forgot to mention on my post above that your blog entries are quite informative. Keep it up =))


Thanks,
Shawn

# TrackBack said on December 30, 2003 11:56 AM:
# jayson knight said on December 30, 2003 06:03 PM:

first i wanted to say i am glad you decided to start a blog, i've been reading your articles/books for quite some time now and they have always been extremely helpful, if not usually over my head. this post got me to thinking, so i blogged my own reply here (won't rehash it) http://zerotrilogy.gotdns.com/jaysonblog/. your post reminded me of this article http://www.ftponline.com/wss/2002_11/online/tmurphy/default_pf.aspx, thus i believe it's safe to assume that microsoft will provide many different solutions to obtain a common goal so that all means of programmers can get there. i have my own personal beliefs on xaml, but won't waste precious space with them here :-)

please keep the posts coming!

# Zach In Russia said on July 4, 2007 05:48 AM:

It is a complete waste of time to write code.  The only people who argue about it are programmers!  Is it because programmers are the only ones who really understand how to communicate with a computer?  The development of codeless programming is retarded by an entrenched mindset.  Take, for instance, Linux.  A major setback is its dazzling flexibility.  90% case is Internet, word processing, and basic file management.  Why does my grandma need to know what ext2 is or that the little black icon will launch a command prompt?

Similarly, the 90% case for code is an assembly of algorithms, user interface components, and I/O methods that have been around for 25 years or more.  For the vast majority of projects, most of the time goes into managing the project, debugging code, and testing.  All of this for a slightly more flexible environment?  For code that has already been written, debugged, tested, and deployed a gigabillion times?

Many people tell me “oh, your short sighted – you’re over simplifying the issues…”.  Having written a commercial SSH server, FTP client/server, HL7 applications, BPM apps, managed enterprise environments, and addressed major issues like scalability and fail safety – I know what the issues are for the majority of business and consumer data applications.  A picture is worth a thousand lines of code.

Leave a Comment

(required) 
(required) 
(optional)
(required)