Pinderkent

Although it's not a new concept by any means, the use of JavaScript for server-side development has gotten some attention recently. This is unfortunate, as JavaScript is not the sort of technology you want to use when developing the back-end for a Web site.

Even as a client-side language, JavaScript has proven to be of a very questionable quality. I think Jonathan Edwards was correct when he described JavaScript as being "quick" and "dirty", and only just "good enough" for most users. For years now, even the major JavaScript implementations have exhibited horrible performance. Only after 15 years of use are we seeing that start to change, with faster VMs from Adobe, Mozilla and Google. As a language, JavaScript itself does very little to encourage the development of secure, high-quality code.

Server-side development calls for a more rigorous programming language and environment than JavaScript can offer. Considering JavaScript's performance problems on the client-side, it's likely they'd be magnified when it comes to server-side development. And JavaScript really doesn't offer anything beyond more traditional server-side languages like Java, C#, PHP, Perl, Python and Ruby. As is mentioned in the Ajaxian article, there is a huge amount of basic Web back-end infrastructure that will need to be built to make server-side JavaScript even barely comparable to any of the aforementioned programming languages.

What's worse, however, is the general "attitude" associated with JavaScript. It has always been a language that appeals to those who want to get their scripts written quickly, even if the quality is terrible and there are major security flaws. It has often been used by Web designers to quickly add some interactivity to the pages they have designed, without needing an extensive programming background. Indeed, this amateurish attitude becomes very dangerous on the server.

PHP is a good example of such danger. For years many PHP developers generated SQL queries directly using data sent to their script by the user, with little to no filtering. This resulted in SQL injection attacks becoming very common for PHP-based software. We still even see this sort of development happening today, in some very sad cases. Meanwhile, more mature server-side languages and environments like Java and .NET have for years provided support for parameterized SQL queries. But even the most inexperienced of Java and .NET developers know better than to not appropriately filter user input.

While there will of course be some professionals using it, and using it well, I fear that the rise of server-side JavaScript would lead to nothing but problems. Just as the PHP community is starting to get its collective act together, we might see a new generation of inexperienced, amateurish developers start with server-side development using JavaScript.

Then again, maybe that's not a bad thing. It'll guarantee a steady stream of work for those of us who have made a career out of fixing such mistakes. But it is unfortunate that we couldn't stop such problems in the first place, but using better languages for server-side development. With some work, Haskell could become very useful for server-side development where quality is concerned, while Erlang plays its part in reliable and highly-scalable systems. Regardless, the main thing we need to keep in mind is that JavaScript should be avoided for server-side development.

I read through an article today that suggested an idea for a Web site where a user can specify a task in a programming language they know, and the site tells them how to perform it in some other language.

This is an interesting idea, and no doubt could make for a useful site in some cases, but would likely run into problems creating the relationships between languages. Even something as crucial as string handling can differ significantly between different languages. C treats strings as arrays of characters. C++ treats strings similarly to C, but also has for example the std::string class for representing strings. Java treats strings as an object. Erlang treats strings as lists of integers.

So operations that are available in one language may not really have an immediate equivalent in another language. Likewise, the approach taken when using one language may be completely inappropriate, in terms of performance or memory usage, when using another language. Such a Web site would need to ensure that these differences and the potential risks were clearly stated. But otherwise, I think it might actually be useful, even if the article suggesting it was somewhat in jest.

I just finished reading this account of a developer who spent over an hour trying to track down an unexpected application crash that was eventually determined to be due to a tuple being passed to a function that was expecting a list. This incident happened while using Erlang. For certain types of systems, Erlang is a fantastic language and platform to use. In the coming years, it is likely that its model for handling concurrency will become familiar to most developers. Unfortunately, for all of its benefits, Erlang does have some drawbacks. One of the most significant is that it is a dynamically typed language.

The main problem with dynamic typing is that it allows incidents like the one described by Travis. A simple typo, in his case involving only two characters, can quickly become an hour or more of wasted time. Were static typing, such as that offered by OCaml or Haskell, being used, the problem would have been detected immediately.

Using OCaml (via its interpreter) as an example, we'll define a function that takes a list of strings, and prints each one to stdout:
    $ ocaml
        Objective Caml version 3.11.0

    # let f = List.iter (Printf.printf "%s\n");;
    val f : string list -> unit = <fun>


Next, let's see what happens when we accidentally call it with a tuple of strings:
    # f ("test", "test", "test");;
    Error: This expression has type string * string * string
        but is here used with type string list


It clearly has detected the mistake, and lets us know right away that there's a problem. Better yet, it tells us exactly what the problem is: it expects the argument to that function to be a list of strings, rather than the tuple of three strings that we passed it. Now that we have so quickly identified our mistake, we can go ahead and fix it. Passing in a list of strings has the expected result:
    # f ["test"; "test"; "test"];;
    test
    test
    test
    - : unit = ()
    #


We would have gotten similar results were we using the OCaml compiler rather than the interpreter.

Using a language that offers static typing is clearly the better route to take when we care about saving developer time, writing quality software, and detecting potential bugs and problems as soon as possible. It's unfortunate that Erlang is a dynamically typed language, as static typing would help increase the quality of code written using it even further. And it would've caught a minor mistake that has caught at least one developer over an hour of time.

It's not the end for Perl. It hasn't died. We won't see that happen for some time, if ever. But lately, it sure has lost its way. Andrew Binstock recently pointed this out in his article about Perl. Although it is very difficult to measure or quantify a programming language's popularity, we can get an overall sense of the "buzz" surrounding it.

Perl used to have that community "buzz". About 10 or 12 years ago, when somebody brought up Perl in a newsgroup or mailing list discussion, there was genuine excitement about what it had to offer. Mainly, that was rapid development, CPAN, powerful regular expressions, and the ability to write CGI scripts, all with little expense. We had needs, and Perl did a fantastic job of meeting them.

Times have changed. We still need to be able to develop software rapidly and with as little cost as possible. But we now have to make better use of our systems with multicore CPUs. Languages like Erlang often do this better than Perl does. Also, we need languages that allow for applications to be more easily maintained. For most sizeable, real-world development projects, Perl code can quickly become a maintenance headache.

Furthermore, the main benefits of Perl are now offered by most other mainstream languages. Python and Ruby offer very good regex support, a suitably large library, support for rapid development, a high degree of portability, and a low cost. Python, for instance, often encourages the development of more maintainable programs than Perl does.

There's very little that'll draw people specifically towards Perl. Recently, I've seen it used only because that's what the developers were most familiar with, or in numerous businesses, it's what they're stuck maintaining. Few people these days seem to choose Perl because it offers something they just can't get elsewhere.

Andrew makes some good observations in his post. One we really need to consider is how, for example, the Python community has gone out of its way to create several usable and actively-developed implementations of the language. We have the CPython implementation. There's IronPython for .NET. There's also Jython for Java. And we can't forget Stackless Python.

We just don't see that sort of activity in the Perl community. Sure, there is Rakudo. And there is also the now-stagnant Pugs implementation. But neither is really suitable for production use. Meanwhile, the different Python implementations are used successfully by many different people and companies. The Python implementations have momentum; Perl does not.

I read a number of blogs, mailing lists, newsgroups, and online forums dealing with Perl. Likewise, I talk often with people in industry who make use of Perl on a daily basis. And one thing I've noticed is that there's little excitement to be found. I think the extraordinarily long time it has taken to get anything useful in terms of Perl 6 has been extremely harmful to the Perl community. To really see a programming language prosper, it needs that raw community excitement. Python and Ruby currently have this excitement. Erlang and Haskell have it, too. Even the Common Lisp community seems more up-beat than the Perl community.

It's far too early to label Perl as "dead", or even "dying". Perl will be with us for ages. But we shouldn't deceive ourselves into thinking that it still has the same momentum that it used to, or has momentum comparable to what we see in the Python, Erlang, Ruby and Lisp communities. The action we see within the Perl community pales these days compared to what is happening in the other communities.

When the computing world moved from manually toggling input switches to machine code encoded on paper tape, there was a vast improvement in programmer productivity. Likewise, when machine code instructions were first represented with more comprehensible text-based mnemonics, we again had a major boost in programmer productivity. It was easier to write programs, and it was easier to maintain them.

Soon enough, the computing world moved on to languages like FORTRAN, COBOL, and PL/I. As had happened earlier, we had a major increase in developer productivity. What was tedious in assembly became far easier in such higher-level languages as those. Likewise, once a program was written, it was much easier for other programmers to come along later and comprehend and modify the program.

We experienced a similar productivity jump with the advent of C in the 1970s and early 1980s. Standard libraries and better portability made it far easier to move programs between two or more systems, often with drastically different architectures. Soon enough we had programmers writing far more complex software in only a fraction of the time and with only a fraction of the cost of earlier methods.

Then in the 1980s, object-oriented languages started to become mainstream. The likes of C++ and Smalltalk became widely used in industry. By the mid-1990s, we had Java. The move to such languages again brought significant productivity increases, especially in the area of graphical user interface implementation. But they also did allow for the construction of larger and far more complex systems than could be easily done in C alone.

Soon enough we entered the 2000s. Languages like Perl, Python and Ruby have started to become popular because they allow developers to perform common tasks quickly and efficiently.

Do you see the trend? Yes, it is one of ever-increasing productivity. That's not to be unexpected. After all, it's what has happened in nearly every other field and industry. It's just how the economy works; increase your productivity or perish.

We're now getting to the point where JavaScript and Web-based applications are being touted as the way we should proceed. Many are calling them the next "revolution" in software development. But I disagree. We just don't see the productivity increases materializing.

A typical AJAX-based Web application is often difficult to effectively create, even for experienced developers working with the latest libraries, frameworks and tools. A lot of developer time is wasted trying to sort out cross-browser incompatibilities. We're not talking about small differences, either. Often these differences require two or more implementations of the same JavaScript code, targeting specific browsers. That's just not effective, nor is it productive.

Debugging AJAX applications is also a terrible experience, even when using a tool like Firebug. Combined with the browser incompatibilities described earlier, it can become very difficult and time consuming to get an AJAX-based application working acceptably, let alone well.

And for the sake of your sanity, I hope you never have to maintain somebody else's AJAX application. I've seen very talented developers struggle for days on end with relatively simple problems in JavaScript-based Web applications. Part of this is because these applications are often developed very poorly in the first place. A second major struggle is the lack of mature, effective tools for mapping existing programs. All of these factors combine to cause problems.

So as you can see, JavaScript-based Web applications are clearly a step backwards. They fly in the face of what we've traditionally seen when moving to a new language paradigm. In the past we've seen clear improvements in terms of developer productivity, and in the complexity and scale of the applications that can be effectively developed. But we just don't see such things when using JavaScript in the browser.

Thankfully, some people have seen the light. They're realizing that languages like Erlang, Common Lisp and Haskell are clearly the way to go. They do deliver the developer productivity boost we've seen several times over and over again in the past. They're better equipped to handle the issues we will soon face with the rise of multicore systems in even the cheapest of desktops. In short, they exhibit an evolution of software development, rather than the devolution we see so often with JavaScript and AJAX-based Web applications.