Pinderkent

Lately, there has been a trend towards using the Web browser as a general application development platform. This is unfortunate in many ways, namely due to the poor nature of the browser for such a purpose. A system inherently designed for displaying documents and allowing for navigation between them has been perverted into something more. Unfortunately, it's not even a remotely decent platform. All of the efforts so far have basically been very poor reimplementations of what we've already had for years.

In terms of programmability, we're basically limited to using JavaScript. While JavaScript may be usable for minor scripting tasks, it is not the sort of programming language that should be used for developing more complex software. I've written before about some of the problems with JavaScript, as have many others. Needless to say, it's not good to be isolated just to JavaScript for browser-based Web applications, as we currently are. Compared to more traditional software development, we're handicapped significantly by the current situation.

When it comes to actually displaying stuff to the user, we've experienced nothing but problems. We're essentially limited to using CSS, along with JavaScript. Anyone who has had to write even a moderately complex cross-browser stylesheet knows that it's nothing but a huge hassle. And even today, there's still much disagreement about whether CSS is even acceptable for layout. I summarized some of the CSS versus HTML tables arguments the last time that debate flared up. Regardless of one's stance, I think it has to be agreed that the mere act of rendering text, images and other information to the screen is much more of a problem for Web applications than it probably should be. Even then, it doesn't offer the flexibility we can get from traditional software development platforms and techniques.

While it's been noticed that there are significant problems in these core areas, the remedies are less than suitable. A good example of this is the canvas element that has been implemented by several browsers. It essentially provides a drawing surface, much akin to what we've had available on so many other platforms for decades now. But unlike these non-Web-based platforms, the canvas element is primitive. A developer using the canvas element is typically forced into writing a lot of code that would already be provided as part of the more mature platforms.

We've seen an even further step backwards recently with respect to the HTML5 Web Storage specification. So not only will we have a crippled programming environment in terms of JavaScript, and a poor rendering environment in terms of HTML, CSS and the canvas element, but now we may also have a half-baked implementation of a relational database, as well as the interface to access it, available for abuse.

There's been a lot of disagreement lately about this browser-based storage. And I'm not talking about healthy disagreement such as whether it's a bad idea or not. Most of the disagreement is with the nature of the data store itself. That draft specification suggests a very SQL-oriented approach. Others suggest that a JSON-based approach would be better. Some suggest an approach akin to CouchDB, with this already being experimented with.

Based on the current draft of that spec, I think we're looking towards a world of pain. It essentially outlines a very poor reimplementation of what we've had for years in technologies like JDBC, ADO.NET and Perl's DBI module. It's looking much like a case of us getting a small fraction of what we can already do, without any real benefits, improvements or innovation.

It makes little sense to try to build a platform for the future in the Web browser. All we've managed to do so far is reproduce a lousy, stripped-down version of the existing platforms that we've had for decades. But what makes it worse is the monoculture that has developed. We're stuck using JavaScript for programmability. Any form of display must essentially be done using HTML, CSS and the canvas element. Data storage may be done in a form similar to that of the proposed HTML5 Web Storage spec, but even if different it will still likely be very lacking. And given that the platform is provided by the Web browser, it's not like we can really go back and correct all of these deficiencies at the core with ease. We instead have to try to reproduce what we've had for years outside of the browser using JavaScript, which so far has been an absolute failure. We can't make any real forward progress if we're going to be continually trying to bring ourselves up to the level we were at back in the 1990s.

Today I read an article that discussed a variety of issues relating to Microsoft Windows today, including the general disappointment surrounding Windows Vista, and the apparent lack of interest in Windows 7, especially in the enterprise. It goes on to suggest that Microsoft themselves are responsible for this, and Apple will gain the most from this situation.

I don't think we're really seeing Microsoft tarnishing the Windows brand. In some sense, it's not even possible for them to do that. Many people, and not just Mac users, have an extremely low opinion of Windows to begin with, along with many of Microsoft's other software products. Although the NT-based systems typically don't suffer as badly from the chronic crashes and security flaws that plagued Windows 95, Windows 98 and Windows ME, users of those earlier versions will forever associate the names "Microsoft" and "Windows" with poor-quality software. Even today, I rarely meet people who outright like Windows. Most of its users just seem to tolerate it.

If anything is causing Windows to become more irrelevant, it's the widespread move towards Web-based applications. This isn't a novel observation, by any means. It has been obvious for some time now that many applications that were formerly desktop apps have been replaced by Web-based alternatives for a large number of people. People using Web-based email services like Microsoft's own Windows Live Hotmail and GMail instead of desktop mail clients is one significant example.

The move towards Web-based applications is a trend that has been common within enterprise software development for years now. More and more companies are replacing what were traditionally desktop applications with Web-based alternatives. Now this often isn't a good idea; there are some applications that are much better left as standalone apps. But in many domains, the software the users are interacting with is solely browser-based, and thus the underlying desktop operating system is essentially irrelevant.

When the user is interacting mainly with a Web browser, it really doesn't matter what operating system is underlying it. Mozilla Firefox and Opera alone are typically good enough for using most Web-based apps. So the need for Microsoft's software is diminished. This is why GNU/Linux has become more appealing for many enterprise users. It's not about GNU/Linux being more capable than Windows, but rather the opposite; it's easier and cheaper to strip GNU/Linux down to provide just the bare essentials for running the browser used to access the Web applications.

Microsoft saw the threat that Web-based apps posed to desktop applications, and put forth their Windows Live and Office Live initiatives. I'm not sure if these have been as successful as Microsoft would have hoped. In my experience, I've seen little to no serious adoption of these technologies in enterprise settings. This is one area where Web-based applications typically aren't as useful or acceptable. Many enterprise users want greater control over their documents, namely where they are stored and who can access them.

I think it's doubtful that Apple will truly make significant inroads into the enterprise. While some such users will likely switch to Apple's hardware and software, and others will no doubt consider it, given the current cost of Apple's offerings I don't see it happening on a wide scale. Much enterprise computing has been driven by large purchases of lower-quality and very low-cost PCs. As mentioned before, with many organizations moving towards Web-based applications, the need for overly powerful PCs is diminished. With low-end PCs still being suitable, many IT managers will need to cut costs by using GNU/Linux instead of Windows, rather than purchasing more expensive hardware/software combinations from Apple.

So we're likely looking at a more diversified computing world, with some users using desktop apps, others mainly using Web-based apps, and many using a mix of both. It's very unlikely that we'll see Apple's products, or any other company's products, achieve the same market share that Windows holds. There's just too much impetus at this time for such significant changes, even if future versions of Windows are as poor as Windows Vista was.

"Softwares" is a term that we unfortunately see used far too often. Some recent examples include the titles of the 11 Most Popular Cross-Platform And Free Softwares and Install And Update All Donation Coder Softwares Automatically articles. While this is not a major problem by any means, it does interfere with communication in some cases, as it is not what most native speakers of English would expect.

The general consensus seems to be that "softwares" is not the correct way to refer to multiple pieces of software. Multiple people pointed out in the answers to the What is the plural of software? question at Yahoo! Answers that the word "software" is a mass noun. Thus it is quantified through the use of a unit of measure. "Pieces" is perhaps the most common measuring unit for software, much akin to how somebody may have multiple "pieces of furniture" in his or her house.

Several other sources suggest that the word "softwares" is incorrect, including Wikipedia, The Grammar Logs, and a topic at the WordReference.com Language Forums.

From both the sources above and from my past dealings with native English speakers, some alternatives to the word "softwares" that are clearer include:

• Pieces of software
• Software applications
• Computer applications
• Software programs
• Computer programs
• Software packages
• Software bundles
• Software products
• Software solutions
• Kinds of software
• Types of software

Now is a good time to start avoiding the use of the term "softwares". There are a wide variety of alternatives, and their use will improve the clarity of communication.

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.

Anyone who has worked in the computing industry long enough knows that some pretty insane things happen. The Daily WTF does a decent job of bringing some of these situations to the public. Some of them you don't ever think could ever actually have happened, but then you see similar incidents yourself, and realize that as absurd as they seem, they do unfortunately occur. I've been aware of one such situation for over a week now.

One of the software development managers at a company I'm currently consulting for manages several projects in-house, along with a couple of smaller projects developed by an off-shore firm. One of these projects being developed by the off-shore firm is still in its initial stages. During a conference call with the off-shore team at the end of March, he requested that they send daily progress reports starting in April, to which they agreed.

On the first of April, the manager checked his email, and did in fact receive a progress report. Somewhat unusually, the subject of the email was "01-04-2009: Penis Report." What followed was a typical daily progress report, although the English was particularly poor.

He wasn't really sure what to make of it, so after showing some of us the email, he decided not to say anything about it to the off-shore team. He wrote it off as an unusual April Fools' prank, and figured it would be a one-time occurrence. However, it was not. He received two more daily "penis reports" that week, and they continued into this past week.

Finally, this Wednesday, he confronted the off-shore team about it. It turns out that they had understood what was meant by a "progress report" when he had requested them to send one during the conference call, but the team member responsible for actually sending the emails had a relatively poor grasp of written English. Somehow he had so badly misspelled the word "progress" that his email client had instead auto-corrected it to the word "penis", which the off-shore team member thought to be correct, for whatever reason. This poor fellow didn't even fully understand his mistake until after the manager asked him to look up the word in a dictionary.

On the bright side, the manager did receive an email on Thursday entitled "09-04-2009: Progress Report." But the off-shore team reportedly has one fewer team member due to this little incident...