So what's next?

Code is a document. A document is written in a language and describe something of meaning. A language is a bunch of terms and a grammar that give the author a framework to present their meaning. In programming, the 'document' is intended to describe a set of instructions that the computer can understand. What form does the computer want these instructions? Well as a document in another language. So a compiler just translates the code from one language to another right?

Translation involves two stages, transforming the original document into an 'understanding' or model of the documents meaning, then expressing this again in another language.

When dealing with a human translator you can say anything. Where there is ambiguity the translator can then ask questions to ensure he has captured the meaning correctly. He can then express the meaning in the new language. The process is interactive.

Your IDE/Editor should be just as interactive.

The future of computing is in making the interaction as simple as possible. The smarter the IDE the simpler the interaction. When the translator knowns what you mean you should be able to stop typing. When the translator is confused it should tell you. Working with and IDE should be a conversation.

Unit testing is good! Unit testing is the gateway to example driven programming. 'When I do X and Y, Z should happen'. This is a form of requirement specification.

Talking of which... It is easy to see that any 'requirements' document that completely explains the requirements of the system is code. The code is just in a language that is much harder to create a software based translator for, so we use humans to achieve it. To me this is the least rewarding form of programming.

With OO software development the codebase breaks down into the model, business rules and user interface. There is also persistence and networking etc. but lets ignore those for now.

The model is just a way of extending the terms in the language you are using to allow you to more concisely explain the system behavior(business rules) you wish to explain to the computer.

If you are extending the terms in the language why not the grammar too. You are then describing your own Domain Specific Languages. JetBrains are doing great job in this area. They intend to create a development environment that allows you to create a programming language quickly that represents the problem domain. They also want to provide you with an intelligent 'editor' for your language capable of intellisence, refactoring etc. This is very exciting. The other approach is to use a language like Ruby or Smalltalk where the language lends itself to easily being extended to include your new concepts.

It would be possible to have the IDE aware of unit tests. Evaluate the unit tests against the current codebase. It could then give you realtime feedback on what code is covered by tests. It could remember the code coverage for each test. Any change you make to the codebase from that point on that effects an existing test forces that test to be re-evaluated. If the test then fails the user is notified. 'Your change just invalidated one of your tests'. Faster you get feedback means less bugs.

IDEs should be more intelligent. I don't just mean smart. I mean AI intelligent. A mixture of automatic refactorings, 'good' design heuristics and Genetic Algorithms could lead to a system that automatically generates the simplest code solution that meets all the requirements (unit tests). Programming would then be the process of coming up with examples where the existing solution fails to meet the requirements.

Prevayler for .Net

Prevayler is a persistence engine that is a cool alternative to a database. It boasts performance of about 3000 x faster than MySQL (if I remember correctly).

The basic premise is that RAM is cheap (and if not today it will be tomorrow) so keep all your business objects alive in RAM all of the time. To handle server crashes you regularly make snap shots of the server. You employ a command pattern for all actions that cause changes to the state of the system. The commands are serializable, so they get logged before they are executed. If the server goes down, you load the last snapshot and then replay the commands in the log since the last save and there you have it, the server is back to the same running state.

You don't even need to stop the server to take the snapshot. You just run another copy of the prevayler (loaded from the last snap shot) get it to run up to speed using the log, then stop processing the log and save again.

Since everything is live in memory all the time, asking a customer for all his orders is as simple as accessing the Customer.Orders property.

Check out the Skeptics FAQ for more discussion.

Check out http://bbooprevalence.sourceforge.net/ for a .Net implementation.

New Ruby on Rails release!

A new version of ruby on rails just came out :) with Ajax support ...check out http://script.aculo.us/demos/shop for a demo

Also check out rails-013-225-featuresfixes-in-75-days
for full details. They have made many changes.

NMock 2 - new syntax, new features, same problem

NMock are working on a new version of their popular mocking framework.
You can now mock Properties and Events and it has a totally new syntax.

Expect.AtLeastOnce.On(joker).Method("Ha");

You are still limited to using "strings" for method names, so you still have the issue of changing your tests manually when you rename methods. (see EasyMock as an alternative)

Thanks to Roy Osherove's for highlighting NMock's latest efforts.

Comments are deodorant for code

"Code smell" is the rather evocative term used to describe an aspect of a piece of code that indicate a fundamental problem with the current design. Comments are frequently used to explain what is going on in complex code. Therefore they act like deodorant on smelly code.

Most comments I read in code are totally pointless. 'print "hello"; // this line prints hello' or worse 'print "goodbye"; // This line prints hello'. Another common use is as follows...

void someMethod()
{
   //add a new user
   ... Code to add the new user ...
   // give the user a new password
   ... Code to give the user a new password ...

   ...
}

What you have here are a whole bunch of methods all tied together. My money is that if you look elsewhere in the code you will find another method that also implements the 'add new user' code too. Methods like this make duplication much harder to spot.

Code should be self explanatory. If you have to put a comment in the code to explain some aspect of its behavior then the code is not clear enough.

There are three things you are trying to get across to the reader of your code:
1/ What is it doing?
3/ How is it doing it?
2/ Why is it doing it?

Here is how to address each of these concerns.

What is it doing?
The name of the method answers this question.

How is it doing it?
The body of the method should be an easy to read list of steps.

Why?
Very occasionally reading the 'How' of a method will leave you wondering 'why is it done this way? Usually this is time to refactor. Sometimes, however, this is not the case. Maybe the operations are order dependent or apparently superfluous steps are required for someone API to work correctly. Explaining these situations is what comments are for. It is also a good idea to have unit tests to verify these conditions remain true.

Situations where comments are require should be rare!

So... Next time you are adding a comment to explain some code, ask yourself the question "Is this comment explaining What? Why? or How?" if its not "why?" then it shouldn't be a comment!