My first computer was a Texas Instruments TI-99/4A. I got it just before going to college. I had been interested in computers since junior high but this was the first time I could afford one. The primary programming options were Extended BASIC and assembly. Writing interesting programs required assembly (because BASIC was too slow) so I learned TI TMS9900 assembly language. I went on to learn a few others including PDP-11 and 8080.

If you have programmed in any assembly language you know how tedious it is. There are so many details to be concerned with that have nothing to do with the problem you are trying to solve — simple instructions, addressing modes, managing registers, and maintaining the call stack to name a few. Because the instructions are so simple you write volumes to accomplish little. Often you would be dealing directly with hardware devices so at the same time as dealing with the many details of the processor’s instruction set you had to understand the idiosyncrasies of the device IO registers.

Once you got some small useful thing working like writing a character to the screen you made it into a reusable library routine so that you didn’t have to write that code again. Libraries helped but the big leap in productivity came with higher level languages. Frederic Brooks wrote in No Silver Bullet: Essence and Accidents of Software Engineering:

“Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming.”

Structured statements replaced compares and jumps. Expressions took the place of numerous instructions. The vast (well not so vast by todays standards) stretches of memory locations were replaced by data structures. The compiler took care of pushing values onto the call stack and popping them on return.

The details were interesting to a point and there was satisfaction in having the level of knowledge needed to program in assembly language. Making the switch to a language like C meant giving up some control but it was well worth it because of the productivity gain.

The switch from assembly to high-level languages didn’t happen instantaneously. Trust had to be won. Early compilers had bugs. People thought they could do better optimization than the compiler, and at first they could, but compilers got better and better. Compilers could also do something that assembly programs couldn’t — they could compile your program so it could run on different types of CPUs.

Writing web applications today reminds me of assembly language programming because there are so many details to be concerned with: HTML, CSS, JavaScript, HTTP, and browser incompatibilities and idiosyncrasies. Then there is the server side technology; pick one of Java servlets, CGI, PHP, .NET etc. and perhaps a framework or two. Also you probably need to know SQL if your application data is stored in a database. Cross cutting issues such as usability, accessibility, security, performance and internationalization add additional dimensions.

The details can be interesting and sometimes frustrating. Do I really need to know that IE make the href attribute an absolute URL when inserting an anchor into the DOM while Firefox does not? (This usually doesn’t matter since if you use the href property you always get the absolute URL but it bit me once.)

I would like to create web applications without having to worry about many of these details. When I say HTML is the assembly language of the web I’m including CSS and JavaScript. I see the Browser as the processor (CPU) and HTML, CSS, and JavaScript as the instruction set. I get the feeling that we should be programming at some higher level.

There are plenty of libraries and frameworks available that help. Some are getting to the point where you don’t need to know much about HTML or JavaScript (GWT, JSF come to mind). JavaScript libraries like jQuery or Dojo are making it much easier to write cross browser code.

So whats wrong? Like I said, some of these frameworks abstract away HTML so you can think in terms of higher level “components”. The problem is they are still just libraries (for the purposes of this article frameworks are just really big libraries). I believe that larger productivity gains are possible from languages rather than libraries. The languages may be domain specific — for creating web applications — but thats OK. The languages could be compiled or interpreted or some combination of both.

One very important thing that happened with the move from assembly to high-level languages is that one relatively small group of people were able to focus on implementing compilers that did great optimization following the best practices for the particular CPU type while another much larger group of people focused on building their applications.

Imagine if best practices like using a hidden token to protect against CSRF or using the POST-Redirect-GET pattern were built into the language.

Imagine if cross cutting concerns and decisions that usually have to be made up front were compiler switches or runtime options. Examples:

• What level of functionality do old browsers get?
• Is the back end going to be PHP or J2EE?
• Do my users have to have JavaScript enabled?
• Should session state be kept on the client or server?

There are huge opportunities for performance optimizations – on the client, over the wire, and on the server. The optimizations can improve over time independent of the applications. Imagine if css, js, and images were automatically combined, minified, and compressed such that overall response time was minimized.

Yes the abstractions will leak. It will take time for the language implementations to get good enough and for programmers to trust them. I would like to see this happen.

Some may wonder if I actually read “No Silver Bullet” or just pulled a quote from it. After all it says that languages are not a silver bullet. I’m not arguing that they are. I’m saying that they can do better than frameworks. There is enough accidental complexity in building web apps today that a domain specific language could be a big help.

So why hasn’t it happened yet? Perhaps its just that the right framework hasn’t come along yet. Thats the thinking that has given us at least 57 frameworks in Java alone. I think some believe that tools are the answer. It used to be that you could charge money for a compiler. Not so anymore. But that can’t be the problem since most of the frameworks are also free.

Perhaps it is already happening. I have not dug into Links but it sounds just like what I’m talking about.

I plan to write more on this topic in the future.

Recently I had some not so nice things to say about jQueryUI while still professing my love for jQuery. What didn’t come across in that post is that I am hopeful that jQueryUI will become as great as jQuery.

Now it seems I have good reason to be hopeful. John Resig tells us the good news that Paul Bakaus (the lead developer) now works full time on jQueryUI at Liferay and that a new release is due out soon.

Today I’m going to rant about something that really bugs me – commenting out code. Just about everywhere I have worked and in most code I have read I have found code that has been commented out. What is it that possesses people to do this? Why is it so prevalent? Is this practice actively being taught and recommended?

If code should be written as if for humans to read and incidentally for computers to translate then commented out code is worse than useless because it slows down and confuses the human reader.

Imagine reading a book or article with text crossed out like this. It would leave you wondering if you should be reading these sections or not. Why didn’t the author just get rid of the text all together?

When I see commented out code I don’t know if the person who did it was just forgetful, uncertain of what he or she was doing or doesn’t use or trust source control to do its job.

During development it can be useful to temporarily comment out some code to see the effect removing or replacing it will have but this temporary experiment should never be checked in.

Here are some things I do to make sure I don’t forget to remove or uncomment code in this situation:

• For real quick tests I’ll delete or cut the code and let the editor undo or paste buffer remember it for me. This has the risk of losing the old code if the editor or computer crashes but you can always get it back from source control if it was previously checked in.
• I always add a marker to the comment such as “todo” or three x’s so that I can easily find things I forgot to cleanup.
• Before checking in I diff all files against the head revision looking for the marker or other undesired or accidental changes

If you’re not sure of your changes keep reading and testing until you are sure. Then delete that old code. If it helps imagine that the code is cheese and wrapping it in comments is like leaving it out of the fridge. Its going to get smelly and you don’t want your code to stink do you?

You really don’t need the old code stuck in comments. Source control does a much better job of showing you what the code used to look like. It is more trustworthy and can tell you more information such as who made the change and when. Depending on the source control system the changes can be correlated with related changes over many files.

Are there any exceptions – any legitimate reasons for having code in comments? Just a few but most of what I come across doesn’t fall into these categories.

Code that enables a special debugging, testing or profiling mode can be left in to make it easy to re-enable that mode later. The code should have a comment such as “uncomment the following line to enable debugging”. Often there are better ways to do this. It may be useful to have a runtime switch to enable the code or if your language has ifdefs they can be used to create a variant of your program. AOP or code generation may also be appropriate.

Sometimes you may add some code that depends on some other code that isn’t ready yet. You can test your code with a test harness but it can’t be used until the other code is available. In this case there should be a comment such as “uncomment this block once the foo modules is ready”. Again there are sometimes better ways to handle this situation such as creating a branch in source control for the unfinished work with stubs in place.

Another possible reason for leaving in the commented code, that I don’t really agree with, is as a cautionary statement. As if to say don’t think of changing the code back to this because it used to be this way and I decided that it didn’t work out so well. In this case it is much better to replace the code with a human readable comment about what should or should not be done in this context. For example suppose you have code like this

  resourceA.lock();
  int foo = bar();
  ...

Someone finds a deadlock condition due to calling bar. So they comment out the call.

  resourceA.lock();
  // int foo = bar();
  ...

This is bad because future maintainers have no idea why that was done. The following is a little better.

  resourceA.lock();
  // this was causing a deadlock sometimes
  // int foo = bar();
  ...

But this is even better still.

  resourceA.lock();
  // be sure not to call any functions such as bar that try to lock additional resources
  ...

The bottom line is don’t check in commented out code and if you do it must have a human readable statement as to why it is being left in. All of the above apply to ifdef-ed out code as well.