Twelve years ago the World Wide Web Consortium released a set of specifications for the Extensible Markup Language or XML.

It was designed to allow anyone to create tagged documents, with tags describing the contents and by building on the work done with other languages (particularly SGML (Standard Generalized Markup Language) it was intended to be a common platform for data exchange across the rapidly growing internet and become the lingua franca of the connected world but a lot of people find it bulky and ugly.

The same could be said of JavaScript. According to Doug Crockford, considered by many in the development community to be the JavaScript expert, it is a beautiful, elegant, lightweight and highly expressive language which lies buried under a steaming pile of good intentions and blunders.

The very good ideas he says, include functions, loose typing, dynamic objects, and an expressive object literal notation. The awful ideas include a programming model based on global variables.

“I don’t understand
a mindset that
undervalues quality.
It doesn’t help to make
it fast if you aren’t also
making it good.”

By sheer coincidence Doug also rails against XML and developed JSON (JavaScript Object Notation) a lightweight data interchange format widely used in Ajax applications, because he found XML extremely verbose and time-consuming to transmit and process on the browser.

A senior JavaScript Architect at Yahoo! Doug has been a programmer since the early 1970s when he took a punch card Fortran course in college after finding it difficult to get into television broadcasting.  Over the course of four decades he has combined computers with media and has worked for numerous companies including: Atari, Lucasfilm and Electric Communities.  A member of JavaScript 2.0 committee at ECMA, Doug is a regular speaker at conferences on advanced JavaScript topics, and prefers to think of himself as a mahatma rather than a guru.

RM:

How did you start in programming?

DC:

It was at San Francisco State University and it was a program I wrote to disassemble the runtime of the Fortran system on the timesharing system I was using. I was therefore able to read how that system worked and taught myself a lot about programming based on that model. I suppose the biggest change in the way I think about programming now compared to then, is there was probably a decade where efficiency was really important. It was in the early microprocessor era when memory was really small and the CPUs were still really slow. We’d get down into assembly language in order to do games and music and such like to make it fit and fast. We got over that eventually and so today we’re writing big applications in JavaScript that run in a browser. It’s such a profoundly inefficient environment compared to the stuff that we used to do, but Moore’s Law sort of made it okay.

RM:

How do think JavaScript could be improved?

DC:

Make it smaller. If we could just get it down to what it does really well and remove the features that add little or no value, it’s actually a better language and actually an elegant, beautiful little language. It’s not only a beautiful little language, but it’s also a powerful one, and one that is more widely deployed than any other language in the world of course.

RM:

What though are the major problems, are there too many Ajax libraries or are people reimplementing the same things over and over again which has lead to this large bloated mass?

DC:

There are too many Ajax libraries and that’s a consequence that JavaScript is so powerful and the need is so profound that they are easy to make, so for a while everyone was making them. I’ve been expecting that we’re going to have a shake-out but it hasn’t happened yet. One thing we are seeing now is that the Ajax libraries are converging. jQuery came up with a notation for using CSS selectors for getting a list of objects from the DOM and then providing methods for manipulating the objects en masse. And that turns out to be a really good idea and it’s something that JavaScipt does very effectively. There’s inefficiency there in that the interface to the DOM is horrible but they hide it all. They’ve really simplified the programming model.

RM:

You are quoted as saying that you developed JSON because XML was inexcusably ugly and inefficient but it must have its good parts. What are the particular qualities that you like about it?

DC:

The best thing about XML is what it shares with JSON, being human readable. That turns out to be important, not because people should be reading it, because we shouldn’t, but because it avoids interoperability problems caused by fussy binary encoding issues.
 
Beyond that, there is not much to like. It is not very good as a data format. And it is not very good as a document format. If it were a good document format, then wikis would use it.

RM:

What are your thoughts on ECMA approving JSON for web applications and what sort of impact do you think this will have on developers?

DC:

What ECMA did was approve an edition of ECMAScript that had built in JSON support. This is a good thing for Ajax applications because JSON operations will be faster and more reliable.

RM:

When you want to hack up an experiment quickly, do you use JSON? If not, what do you use?

DC:

When experimenting, I will hook up buttons to little scripts that simulate the server. That way I can mock up the whole application on the client. The similarity between JSON text and object literals is really helpful there.

RM:

I have a couple of unrelated questions here about quality of software. Do you think education is the answer to developing better software and that somehow we get out from the ‘we must do it first no matter how buggy it is’ way of thinking? And is this thinking innate or produced by culture

DC:

I don’t understand a mindset that undervalues quality. It doesn’t help to make it fast if you aren’t also making it good. I think this can be taught, but I don’t know why it isn’t already universally known.

RM:

A lot of people have attacked C++ saying it has become monstrously complex and bulky, difficult to understand, and likely to contain errors for ever. Can you see it remaining in use and if so why?

DC:

Once some technology gets into the enterprise, it can take generations to get rid of it. C++ will be with us for a long time still.

RM:

Do you think many people working in technology are unaware of its history and have little curiosity about where languages came from?

DC:

There are some amazing stories about where languages came from and who did what and what is now considered a mistake and what should be considered a mistake, but hasn’t yet. I think of myself sometimes as an archaeologist of software technology and over the years have accumulated a collection of under appreciated technology, things that I think were really, really good which are significantly in advance of the state of the art that we’re using now.

I keep hoping that we will somehow rediscover some of this stuff and learn to appreciate it and benefit from having done it, but it’s a really slow process. Some folks are really entrenched in the way things are working right now and it’s difficult to move.

RM:

What languages are you talking about here?

DC:

In particular Lisp and Smalltalk. That’s really brilliant stuff and we’re finally seeing those ideas being factored into modern languages, so we’re doing a lot of work now in JavaScript and trying to modernize that. It turns out that JavaScript already anticipated a bunch of that stuff; it’s got functions which are lexically scoped and first-class, which was brilliant. Now we’re trying to figure out how to get more of the goodness of Smalltalk and Scheme into this language without breaking it. You could argue that we’d be better off if we just threw out everything we’re working on now and go back to Smalltalk and Scheme and we’d probably be better off than we are, but that doesn’t appear to be an option.

RM:

One language that came out of that group is Eiffel which was beaten in the object oriented language contest by C++ of course.

DC:

I think Eiffel is a much better language than C++ and I liked the precondition, postcondition contract stuff it did. I would like to see that built into my language, whatever language I’m using, but that’s another of those ideas that hasn’t really caught on.

RM:

I want to skip to the web again and ask you about the main challenges for browsers in the next decade?

DC:

We need to solve the IE6 problem. IE6 used to be the best web browser in the world. But it has not aged well, and it is still surprisingly popular. This is a hardship for developers because it is difficult to develop applications that work well on IE6. Its popularity has been declining, but very slowly. It has been able to hang on because developers have worked hard to support it. I think we need to stop doing that, and instead recommend that the IE6 community move to one of the many superior solutions. I don’t think it is out of line to ask people to upgrade their software once a decade.

RM:

When you look back at your career on all the things you have done is there one time or a period that stands out among all the others?

DC:

When the bubble popped 10 years ago, it looked like there would be no more innovation and that we would be stuck with the web in its underdeveloped state. But things have gotten interesting again. This is a great time.