Tom Petrocelli's take on technology. Tom is the author of the book "Data Protection and Information Lifecycle Management" and a natural technology curmudgeon. This blog represents only my own views and not those of my employer, Enterprise Strategy Group. Frankly, mine are more amusing.

Friday, May 25, 2007

All You Need is Love!

It's true. All you need is love. So, do we really need another scripting language? Ever since Perl and Javascript showed us that we could crank out code quickly by using a simpler, non-compiled language, scripting languages have proliferated like nuclear weapons in the 1960s. Besides the old languages such as C Shell, AWK, TCL, or SED, and the middle period ones like Javascript, VBScript, Flash Actionscript, and Perl, we nowmust contend with a whole host of new ones.

In the last few years we have seen the emergence of Ruby, Python, and PHP. All have their adherents who defend them with nearly religious fervor. PHP has become one of the most deployed server side scripting languages while Ruby is often used for interfaces that provide rich user experience (in other words Web 2.0) web sites. We can also add to the mix Java Server Pages (JSP), a scripting language for Java Servlets (popular amongst the Tomcat crowd) also for user interfaces. On top of that, Javascript has been extended and integrated into the AJAX model to provide for pretty much the same purpose.

Now, we can add a couple of new languages or environments to the mix. Some have been pushing Groovy, another servlet-oriented language. Despite the obvious Java-oriented scripting language proliferation, Sun has seen fit to launch yet another scripting language, JavaFX. Microsoft has also announced its scripting effort called Silverlight, despite have ASP.Net already.

Why do we need all of these languages? My take on it is that software companies need to have an entry in this space. Most scripting languages have come from the user community, with Javascript being a notable exception. Unlike compiled languages, which typically have high learning curves and need extensive tools, scripting languages are easy to learn and implement. By creating new scripting languages, many of which are similar to proprietary compiled languages, they extend the franchise in the part of the business that makes them money and neutralizing the user scripting languages which don't. This explains Sun and Microsoft's latest announcements.

I also think the open source and hobbyist communites feel compelled to develop new scripting languages because they simply don't like something about existing ones. It usually starts out with the need to have a language that solves a very narrow problem and expands into a general scripting language. Python and Perl comes to mind here.

The result is too many languages that offer few benefits over existing ones. Most are similar to another language but not exactly the same. This leads to a large number of mistakes that actually slow down coding. Anyone who writes both PHP and Javascript will know exactly what I mean. It also makes for a confusing landscape when trying to choose the what languages to use for a project. What I want is a language that can be implemented as compiled code, client side scripting, or server side scripting. It should start with a standard computer language syntac like C++ or Java. That way I only have to learn one language and can use it for everything. I can also start junior programmers on the more stripped down client side scripting version and work them up to the full, middleware enabled, component-oriented version used in my high volume server applications. This is something for Sun to consider since they, more than anyone else, have the capable to deliver this breadth of options based on the same core language, specifically Java. Microsoft might be able to accomplish this if they standardize on C# syntax.

Scripting languages are a very good idea. They allow for rapid, iterative, development, are exceptionally useful for user interface programming in browser-enabled applications, and make it much easier to deploy small applications quickly and with few resources. They also helped recreate programming as a hobby, something that was on the verge of disappearing as professional programming became more complex. We just have too much of a good thing and need to pare it down a bit. That way we can get on with writing code and not learning new computer languages.

No comments: