Pain and Glory from the Trenches of the IT World

I read today a blog article about the greatly-increased complexity of ECMAScript 4, relative to earlier versions. Indeed, the number of features is quite staggering. And the first thing it made me think of was C++.

C is a relatively small language. That’s understandable, considering it was initially developed for system-level programming on computers with rather minimal resources. Soon enough, Stroustrup and others developed C++, adding a variety of higher-level constructs to C. Over time, C++ has grown to be a rather complex beast.

In some cases, this was not at all a bad thing. The STL, for instance, delivered C++ developers with powerful, reusable and standard classes for many common tasks. While it takes some time to learn to use the STL effectively, one’s productivity will likely increase greatly once it is used.

It takes a typical developer a number of years of continual use to truly master C++. On the other hand, the time necessary to master a language like C can usually be measured in months for most developers. We might see a similar situation developing with ECMAScript 4. It was easy enough for a typical developer to become quite proficient with JavaScript or earlier versions of ECMAScript in a short amount of time. But it sounds to me like it will start taking years of effort to move towards the mastery of ECMAScript 4.

In the “real world”, where applications need to be developed quickly and efficiently, we usually don’t have years upon years to master various languages. So as we saw with C++, most users will only ever learn the subset of the language that applies most often to their needs. This is usually not a problem when it comes to develping whole applications. But when developing libraries, not knowing how to effectively use a particular language feature can easily lead to shoddy workarounds and code bloat. This, in turn, will directly affect other developers using the library, often complicating their lives and efforts. We may see this sort of thing now begin to happen with ECMAScript-based libraries.

Another major lesson we need to learn from C++ is that the more complex a language is, the longer it will take implementors to implement, the lower the quality of the implementations will be, and the number of implementors will be significantly fewer.

It has taken nearly a decade to get decent support for the 1998 C++ standard from the major compiler vendors. There are still areas, such as the export keyword, that are poorly handled. It does little good to have language features standardized, but not actually implemented by any language implementations for many years.

We may very well see the same thing happen with ECMAScript 4. Although there is the ECMAScript 4 reference implementation, the fact that it’s implemented in Standard ML may completely hinder its usage in existing products. It may be quite a while before we see full support of the ECMAScript 4 language from other developers and vendors. Even at that point, the implementations may not be of a very good quality.

Web browser-based JavaScript implementations have always tended to be quite poor. One of the biggest problems is poor resource usage and management. It’s not unusual for a JavaScript script to consume 100% of a system’s CPU resources for several seconds or more upon the loading a Web page. Keep in mind that these are implementations of a language that is much simpler than ECMAScript 4. When we add in the extra features of ECMAScript 4, implementation effort and difficulty will no doubt rise significantly. We will probably experience far buggier and poorly-performing EMCAScript 4 implementations for a number of years to come.

With the unfortunate trend of application development becomimg so Web-centric, ECMAScript 4 might just end up bringing in more trouble than it helps alleviate. Poor, partial implementations of the language, coupled with developers who don’t have the time nor inclination to learn all of the advanced language features, may very well lead directly to the development of low-quality software. Many current JavaScript-based Web applications have numerous and obvious flaws. Unfortunately, it seems that ECMAScript 4 will perhaps only make the problems worse.

This entry was posted on Sunday, October 28th, 2007 at 4:21 pm and is filed under C++, Development, JavaScript, Software, Web Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.