Choosing a programming language is a bit like choosing a religion – usually, the choice is made for you. Each language has its advantages and disadvantages, but frequently developers simply learn whatever language they need to work on a project. At a startup, we have the happy luxury of making this choice more thoughtfully. So what are the factors that go into the selection?
First, there’s efficiency: what’s the language that accomplishes the task most quickly, with the least number of bugs. In my case, it was a natural step to use Google Web Toolkit (GWT) to do our client-side development since it allowed me to use Java – a language I’m pretty comfortable with.
GWT is usually divided into client-side and server-side packages. The client-side code, though written in Java, compiles into JavaScript so it can be run on a web browser. The server-side code runs as servlets. One big caveat about this – because the client-side stuff is really JavaScript, you’re limited in the libraries (and even standard Java classes) you can use. One more word about compiling into JavaScript – GWT actually makes a number of different JavaScript files that are each optimized for each of the major browsers. The title of each of these files is a hash, so whenever you deploy a new version, the user’s browser should load it without having too many caching issues.
GWT has several big advantages – one is the slick way you can set up RPC communications between client and server. Using this, it’s easy to send any serializable object back and forth, making your code much more straightforward. It takes a bit of doing to configure correctly, but once the various classes and interfaces are set up, it’s simple to add new calls.
Another beauty of using GWT is debugging – once it’s configured properly (that can take a bit of doing too), it’s very easy to simultaneously debug both client-side and server-side code. You can easily run/debug on your local machine by running GWT’s local server. When it works properly on your machine, you compile the client-side code and deploy to your servlet container simply by dropping the war directory into the proper place.
Finally, there’s a decently large and helpful user community, meaning most problems you’ll run into can be easily answered through some web searching.
The second factor for choosing a language is more psychological. A startup’s most critical resource (other than cash) is talent. Attracting the best people requires giving them the opportunity to grow professionally and play with exciting technology. Regardless of the actual advantages and disadvantages to a language, building a code base with a language people are excited about is one way of distinguishing yourself in the highly competitive market for developers. The risks of using a newer language, naturally, are the more limited number of existing libraries, more limited support and the chance the language will fall into obscurity, leaving you with a code base that’s difficult to maintain.
An interesting example of this is Scala. It (theoretically) can interface seamlessly with Java and it runs on the same Java Virtual Machine but the syntax is more succinct (though in my opinion, more opaque). The bytecode is the same – the only difference from the compiler’s point of view is the presence of the scala-library.jar.
Scala is a more pure object-oriented language than Java, in the sense that every value is an object (there are no primitives). This helps address the boxing landmine (I recently stepped on this – Float x == Float y is *not* the same as Float x.equals(Float y)).
Of course it’s biggest claim to fame is that it’s (in part) a functional language – something that hasn’t been seem much outside academia. In a functional language, methods can’t have side-effects. In other words, you put X, Y and Z into a method and get back A, without anything within the function changing anything external. The function is an iron box – you put something in, get something out, and don’t need to worry about the stuff inside the box changing anything outside. The major advantage of this is concurrency – you don’t have problems with multiple threads modifying the same variable at the same time. Similarly, functional languages can very easily adapt to multiple cores.
When choosing between one of the major languages out there, it’s really a matter of balancing pros and cons – absent a critical library or interoperability issue, there is likely more than one good choice.
Comments are closed.