Sunday, August 07, 2005

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.

GitHub Projects