Pinderkent

Towards the end of his "On programming language design" article, which does a very good job of pointing out the benefits and necessity of statically-typed and statically-checked programming languages, Andrej Bauer writes the following:

There are situations in which a statically checked language is better, for example if you're writing a program that will control a laser during eye surgery. But there are also situations in which maximum flexibility is required of a program, for example programs that are embedded in web pages. The web as we know it would not exist if every javascript error caused the browser to reject the entire web page (try finding a page on a major web site that does not have any javascript errors).

This opens the door for some interesting speculation. One thing to consider is whether successful languages meant for embedding within Web pages need to be dynamic. Another thing to consider is how the current situation would differ if browser-based languages were more static than JavaScript is.

Anyone who has worked extensively with languages like Haskell, SML, and OCaml will be aware that a more static-oriented mindset itself typically doesn't negatively limit the development of an application. It may make certain software development techniques more difficult, but usually this is just a case of those techniques being a bad idea in the first place, regardless of the language being used.

A good example of such functionality is JavaScript's eval function, which allows for a string to be executed at runtime as if it were code. It's the sort of functionality that's abused far more than it's ever used appropriately. Some of the JavaScript community's more enlightened individuals have recognized this. Douglas Crockford, for instance, appropriately describes eval as "the most misued feature of JavaScript." His advice to "avoid it" makes perfect sense. Wladimir Palant has also written an article about eval. His article is very practical, giving five real-world abuses of eval. In the end, he concludes that there really aren't that many valid reasons for using eval.

So just because a language allows for certain dynamic techniques to be employed, often they're not what is wanted. The natural way of obtaining the same outcomes using static languages like Haskell, Standard ML and OCaml may require slightly more work on the part of the developer, but the end result is typically much safer and much more reliable than the dynamic language's equivalent. In short, using a static language for code embedded within Web pages shouldn't prevent any legitimate and sensible programming activity from being performed.

There's nothing about static languages that would prevent them from being embedded, in source form, into a Web page. Hugs and GHCi are good examples of how Haskell, for instance, can be be used in a manner similar to that of many interpreted scripting languages.

We'll have to resort more to speculation when considering how things would be different today and tomorrow were static languages, rather than JavaScript, more widely available for embedding within Web pages. One of the most significant changes, I think, would be the performance of such code. Until this past year, the performance of most JavaScript implementations can best be described as horrible. Even then, it took the initiative and involvement of Google with their Chrome Web browser, and Apple with Safari, before we even began to see reasonable performance.

Much of JavaScript's performance problems arise from its dynamic nature. This inherently makes the development of optimizing implementations difficult. Of course, this isn't a problem associated just with JavaScript. Other dynamic languages, like Perl, Python, and especially Ruby offer poor performance, as well. Being an embedded, interpreted language doesn't help JavaScript, either. Static languages, on the other hand, allow for implementations to safely perform a greater amount of analysis and optimization, which can lead to better performance than we'd see out of dynamic languages for the same task.

Greater reliability and increased security are other areas where static languages tend to excel. Andrej's article mentions a number of the common language features that help with this. In essence, static languages help eliminate techniques that are known to typically lead to flaws, and they usually provide greater syntax and type checking to catch human errors more readily. The developer mindset one develops by using such languages also inherently helps encourage the development of better software.

Many have touted JavaScript's accessibility as a key to it being widely used. That is indisputable, of course. Its shortcomings as a language have made it widely usable by people who probably shouldn't be using it. Many Web developers who can do a fine job designing a page that looks good have gotten away with using it (along with PHP, another poor language) to perform programming tasks with which they don't have as much experience and knowledge. These are the sort of users who typically create code rife with security holes and other problems. So aside from the natural ability of static languages to encourage higher-quality applications, making programming slightly more difficult may bring additional benefits, by weeding out users who probably shouldn't be performing programming-related tasks.

It's unlikely that we'll see a static language like Haskell, or one of the languages from the ML family, available within all popular browsers any time soon. Even today, Web developers spend an inordinate amount of time dealing with cross-browser issues when writing JavaScript code. Instead, we'll likely see the current trends continue, with JavaScript still having relatively poor performance even after much work funded by powerful industry backers, with JavaScript still being used to develop poor-quality and insecure software, often by developers who have little real programming knowledge or background.

I read an article today about whether higher-level programming languages like Python, Perl and C# are really that much more productive than a comparatively lower-level language like C. This is not a new line of discussion, by any means. But we're getting to the point where we've been using such higher-level languages for over a decade, and thus have had more of an opportunity to observe and analyze how successfully (or not) they've been used.

In my view, that article comes to the general conclusion that many of the popular claims regarding the benefits of high-level languages versus low-level languages don't hold true. It's suggested that languages like C do indeed have aspects that hamper developer productivity, but high-level languages bring their own, albeit different, set of problems. While a C developer may run into problems with pointers, a Perl programmer might lose a similar amount of time optimizing regular expressions.

I think the conclusions of that article are correct to some extent, but I also think that the greater picture may have been missed. The real impact of languages like Python, Ruby, Perl, JavaScript and PHP isn't that they allowed expert programmers to be marginally more productive. Their greatest "benefit" (or arguably their greatest disadvantage) is that they have allowed average and even poor programmers to accomplish things they couldn't have reasonably done in C.

PHP and JavaScript are good examples of this. As anyone who has used them knows, they are very unremarkable languages. Conceptually and syntactically, they're much like C in many ways, but without some of the aspects of C that average developers often find bothersome. They aim to eliminate manual memory management, for instance. They offer slightly nicer string handling. Their execution environments aren't as tied to the native hardware. But otherwise, the core PHP and JavaScript languages generally offer the same basic functionality that C offers.

By eliminating some of the more difficult aspects of C, even if they're not as flexible or as powerful in many ways, they've made programming accessible to people who otherwise would not have been able to handle it. I've had the misfortune of working with people like this. They can understand the concepts of variables, constants, loops, conditionals, functions and even the basics of OO to some extent. But they're totally unable to understand some of the basic, yet essential, concepts of C. Pointers, for some reason, is a common one. But luckily for such average developers, languages like PHP and JavaScript make their lives easier by getting rid of such constructs and functionality.

So we soon enough see these average developers using languages like PHP and JavaScript to develop applications. In many cases, there's little to nothing preventing the same application from having been developed using C, aside from the inability of the average developer or developers to use C. Anyone who has worked in the industry knows why businesses opt to go with such solutions. Sometimes it is cheaper and easier to hire several PHP and JavaScript developers, instead of just one or two expert C developers. Other times it's because inexperienced or unknowledgeable managers just don't know any better, or have bought into hype and marketing. Regardless, the outcome is typically a system that just barely works, assuming it's not outright broken. Whatever costs might have been saved initially end up becoming far more costly in the long run.

Had those JavaScript and PHP developers been forced to use C, it's likely that we wouldn't have seen any sort of a software system be produced at all. They would've still been struggling with significant memory leaks, segfaults, and sometimes even just getting their code to compile. So we can see the actual main benefit of such higher-level languages; they've reduced the complexity of an otherwise difficult skill down to something that is more palatable to non-experts.

Now, we need to ensure that we don't lump high-level languages like Haskell, Erlang, and Common LISP in with other high-level languages like PHP and JavaScript. They are clearly very different. Haskell, Erlang and Common LISP, for instance, use abstraction to empower the developer. They offer advanced features and techniques that expert developers can build upon to great benefit. This is very different from languages like PHP and JavaScript, which clearly took the C model of computing, and stripped out the parts that make C more awkward for the less-skilled programmers.

Even thought they are significantly higher-level languages than C, languages like Erlang, Haskell and Common LISP haven't become as popular because they still require a high level of knowledge and expertise to use for even the most basic of tasks. So they highlight the important difference between a language being "high-level" and a language being "accessible". Functional languages increase expert programmer productivity with more powerful abstractions; PHP and JavaScript increase average programmer productivity via simplification.

The whole debate with respect to whether high-level languages are better than low-level languages will likely rage for many more years. There are some tasks that just can't be done in languages like JavaScript and PHP, so we will surely see C remain around for a long time. But we likely will see languages like PHP and JavaScript remain around for a similar reason. Unfortunately, that reason won't be about allowing good developers to develop more advanced software more quickly, but rather about letting poor developers continue to put out just barely suitable software systems.

Today at Reddit there was a posting about a simple 2D bouncing ball physics simulation written in JavaScript. This is the latest example of a simple JavaScript demo that, for some inexplicable reason, gets many people excited.

Thankfully, there are some other people who see these JavaScript demos for what they truly are: something to not get excited over! One of the best replies to that Reddit posting points out how it ought to be easier to make such demos in JavaScript than in other programming languages. And that poster also correctly points out that there's no need to get excited over such trivial applications.

Another reply pointed out the demo's extreme similarity to Pong, a game from the early 1970s. It's also somewhat similar to Breakout, a game from the mid-1970s. Indeed, many of these JavaScript demos are often no more original than what we had over 30 years ago. Mind you, the equivalents from 25 or 30 years ago ran on computers with a small fraction of the processing power and memory of a typical desktop PC today. The developers back then actually had significant hardware constraints, unlike those behind the JavaScript demos of today.

Several others noted just how poorly this demo performs, even on modern systems when using modern Web browsers. One such user reported that it could animate at most five balls on his laptop with an Intel Atom processor before it became unusable. Although Atom processors aren't the most powerful by any means, they should be more than sufficient for the computation necessary to perform basic 2D collision detection and animation.

One user reported that it lagged in Firefox 3 on Mac OS X. Another reported performance problems while using Firefox on Linux.

As usual, we can't have a discussion about JavaScript demos or games without mentioning the unreasonable memory requirements of these demos. I think that poster's claim of 200 MB of RAM usage is, unfortunately, quite realistic. Using Firefox 3.0.5 on Linux, just starting up Firefox resulted in a process that was using 456 MB of virtual memory (as reported by top), with a resident size of 75 MB. Drawing a slightly downward sloping horizontal line, which allowed for approximately three balls to be on the screen simultaneously at the default drop rate, bumped the virtual memory usage up to 523 MB, with 176 MB resident. And extending that line somewhat longer, to allow about eight simultaneous bouncing balls at the default drop rate, bumped the memory usage up to a whopping 587 MB virtual, with 204 MB resident. After leaving the demo running for several minutes, it had stabilized at that point.

I don't think I'll ever understand how somebody could possibly become excited, even in the slightest, over these sorts of JavaScript demos. What they demonstrate was usually demonstrated better, using a fraction of the resources and processing power, two or three decades ago! The performance is typically terrible, even on higher-end PCs a month or two old, using modern Web browsers. It's not surprising to see 100% CPU usage, as well as hundreds of megabytes of memory being used. So in the end, all they do is exhibit essentially no innovation, poor performance, poor resource usage and prove yet again how awful JavaScript is for such simple applications. In short, there's absolutely nothing to be "amazed" or "excited" about with these JavaScript demos.

There has been a lot of hype over the past several years about RIAs, Rich Internet applications. And hype is essentially all that we've gotten. The main problem with RIAs is that they don't let us do anything truly new. In short, they don't help us solve real problems. This derives from the fact that their use and the use of the development tools used to create them has been driven mainly by marketing and evangelism, rather than by need.

Today's common RIA technologies include Microsoft's Silverlight, Adobe's Flex and Sun's JavaFX. From a technical perspective, none of them are truly remarkable or innovative. Silverlight is essentially Microsoft's .NET stack within the browser. Flex and JavaFX are somewhat worse, in that they use sub-par languages like ActionScript in Flex's case, and JavaFX Script in the case of JavaFX.

So we end up with platforms that are heavily sandboxed (that is, intentionally limited in capability) due to being browser-based, and developer productivity that is crippled by the use of languages like JavaFX Script and ActionScript. Even Java applets, available since 1995, offer a more flexible and developer-friendly platform.

Those platforms and frameworks don't really allow us to do anything that we couldn't already do with typical desktop applications or even JavaScript-based Web apps. One common use is playing streamed media, which is something that various desktop applications have offered for many years now. Otherwise, we often see them used for low-quality 2D games, which have also been available for decades. And they prove to be quite terrible for business applications, often combining the worst of Web application development with the worst of desktop application development.

Their inherent lack of technical merit is likely why we've seen them pushed more by marketing forces and stealth bundling, rather than seeing their uptake driven by them naturally providing a more productive, efficient way of solving problems using software. The whole emphasis on 100 million downloads is a good indicator of this.

Over the past several months, I've done some part-time consulting with a company that developers custom apps for a variety of clients. Unfortunately, some of their clients have requested RIAs, with most of the emphasis being placed on Flash/Flex and JavaFX. Over lunch time discussions with some of the developers, I've gotten the impression that feelings are quite mixed. The developers coming from a more traditional background of developing desktop client-side software using languages like C++, Java and C#, including myself, have a more negative opinion of these platforms. We see the regression. On the other hand, those coming from a Web development background are more likely to embrace them, because they often aren't aware that there's much beyond JavaScript and HTML.

My hope is that the development community as a whole gets over this RIA fad sooner, rather than later. We've got more pressing matters to concern ourselves with. Namely, we need to start making better use of functional languages, rather than half-baked scripting languages like ActionScript and JavaFX Script. We need to return our focus to developing practical apps that actually help make others more productive, rather than providing yet another way to play video.

Douglas Crockford's recent article suggesting the creation of a project to develop a so-called "HTML 4.2" specification makes some very good points. He is quite correct when he points out that when developing standards, "It is easy to pile features on top of features, but that ultimately produces systems that are far too complex, insecure, and unreliable." This is indeed what we have seen with HTML 5, and what we have also seen with the ES4 efforts.

It's quite good to see somebody who is so well-known and respected within the Web development community pointing out such harsh truths. But I suspect what the Web needs is more than just more sensible standards. The entire platform as a whole is badly in need of a "reset".

The Web is truly starting to show its age. After all, it has been around for nearly 20 years now. It's remarkable how well it has handled the growth and change it has experienced. But after nearly two decades, it likely is time for some serious changes.

Web browsers themselves are one area where a "reset" is needed the most. A few days back, Ian McKellar made some pointed observations about the state of the Mozilla platform. Namely, he pointed out how the current codebase is extremely complex, lacks even remotely acceptable documentation, and isn't as appealing to developers as WebKit is.

The need for browsers today to maintain so much backwards compatibility no doubt has a significant cost in terms of browser implementation complexity. Even at a very basic level, there are numerous standards of HTTP, HTML, CSS, and JavaScript that need to be supported in order to provide just an adequate browsing experience. Add into this mix the need to accept blatantly incorrect HTML markup and JavaScript code, and it's not a recipe for software that's easy to implement and test.

At some point, it will become beneficial to all to stop trying to build upon so many years of cruft, experimentation and legacy. Instead of focusing so much energy on extending what already exists, the core concepts and functionality of what makes up the Web could be consolidated and a more reasonable platform developed. In essence, the entire Web platform needs a "reset" at all levels. Trimmed-down versions of tomorrow's standards only serve to procrastinate with respect to the effort that will eventually be needed to clean this mess up.