HC: Before going any further, Jeff, I guess we ought to clarify what exactly is meant by a ’dynamic language’...

JH: The two variants are generally referred to as ’dynamic languages’ (Perl, Python, PHP, Ruby, Tcl, ...) and ’systems languages’ (C/C++, Java, C#, ...). Dynamic languages are high-level languages generally characterized by dynamic typing and are generally interpreted. They typically have more built-in data types, automatically do all memory management, and require no compile step. High-level languages aim to require less from the human programmer and more from the computer.

In comparison, a systems language has strong static typing and a compile step which allow for improved performance but can reduce portability and definitely reduces flexibility.

HC: Dynamic languages seem to be very much in vogue just now. Why is that? Is it purely due to their suitability for interactive Web applications or are they also generating interest for other types of development?

JH: There are many possible interpretations for this (there is an interesting one from O’Reilly, for example).

Dynamic languages are well suited to a variety of tasks, and this certainly includes the dynamic nature of the web and web applications. You will find them used across all industries, from gluing together backend systems to network-aware applications to desktop and web user interfaces. You will find them in embedded devices and controlling large manufacturing systems.

HC: In spite of the current fashion for dynamic languages, the fact of the matter is they’ve been around for a long time, haven’t they – I mean, you only have to think back to Lisp, Prolog, Smalltalk and others. Is there any real difference between those languages and the current generation?

JH: I wouldn’t put Prolog in the same class of languages, although it is similar. For Lisp, Smalltalk and others, there is not that much difference. Indeed, they have their own niches, but it comes down to libraries and frameworks. Those are what make the language. You will still find people willing to push the boundaries with their own preferred languages (which is why new frameworks appear). Smalltalk is used by the startup DabbleDB in fact.

HC: So what led ActiveState to choose to support a particular group of languages in the Komodo IDE but omit all those others?

JH: We have chosen to support that which we know primarily, extending ourselves in a few cases. It takes an in-depth knowledge of each language to provide proper support in an IDE.

HC: What are the special problems which have to be addressed by an IDE for dynamic languages?

JH: An IDE for dynamic languages should have similar features as that for any other language. The dynamic nature of these languages is a key advantage as well as a disadvantage. Since dynamic languages lack a compile step which typically does static analysis, an IDE can help users deal with this.

ActiveState’s Komodo IDE in particular has edit-time syntax checking for the main dynamic languages. This allows users to be aware of possible errors before testing occurs. When it comes to web development in particular, developers often find themselves dealing with multiple languages (e.g., PHP on the server and JavaScript on the client). Komodo again excels here by providing extensive support for web development languages and browser-side technologies. For example, you can simultaneously edit and publish server and client code, then debug both sides using Komodo.

HC: Let’s consider a few of the best known of these languages - PHP, Python, Perl and Ruby. What are the real differences between them? If I were to choose one for some specific project, should I just pick the one whose syntax I happen to like the look of? Or are there bigger differences that I need to be aware of?

JH: Personal preference is a strong factor between these languages when it comes to core qualities. They all add, subtract, divide and fetch URLs for you. While they all have similar capabilities, the structure and style of the code does vary. Some languages do have features that make them more suited for particular tasks, but the bigger differences often come in the libraries and frameworks (quantity and quality) that are available for the language. A developer must weigh their project needs against the available frameworks, along with their personal preferences. Ruby on Rails is a good example of a framework targeted at web application development, using a core language that is easy to come to from multiple language backgrounds.

HC: Your own special interest is Tcl. It seems to me that this languages doesn’t have as high a profile as the others I mentioned just now. Is there any reason for that? For what sort of applications would Tcl be especially well suited?

JH: I have been personally involved in the Tcl community for over a decade, but I also program Perl and Python. As with the other languages, Tcl is used in a variety of fields, but to a lesser extent on the web, which has seen the largest growth in visibility and users. Areas in which Tcl is commonly used are test automation, the EDA industry and, along with Tk, for user interfaces.

HC: Ruby, on the other hand, seems to be generating a huge amount of interest. Is this all just hype or are there really solid reasons why people should be thinking of undertaking the development of serious projects in Ruby?

JH: It is strongly based on Ruby on Rails. It could be said that Rails made Ruby popular, but there are many web frameworks. Ruby is however a full fledged programming languages and certainly capable of being used in serious projects.

HC: One of the strange paradoxes of a dynamic, object oriented languages like Ruby is that the dynamic features make it possible to, in a sense, ’break’ some of the object oriented features - by changing the structure of classes at runtime, for example. Some people might think that’s just asking for trouble. Seductive as these abilities may sound, in a big and complex project aren’t they simply too dangerous?

JH: Not at all. This flexibility can be dangerous, but more often than not it is an advantage to the developer. It allows for faster application development in general. In a world where the CPUs are shrinking and development tasks increase in complexity, and "time to market" is key, it is more important to optimize for developer time than CPU time. Runtime flexibility is one of the primary reasons "dynamic" languages got the moniker, and it corresponds to faster turn-around time for developers.

HC: People who program in Ruby, Python and other dynamic languages often say that one of the great attractions is that those languages are more ‘fun’. Are they really? And, if so, should commercial developers be suspicious of programmers who are motivated by the idea of having fun rather than producing solid, maintainable applications?

JH: Ha ha, that is a good question. I find programming myself for fun sometimes. I don’t think it matters what language you use as much as what you are doing with it. This is really where you can see personal preferences take hold. Certain languages may have base characteristics that are more in tune with a developer’s personal programming style, and they will then have more fun using it. Having fun programming is not antithetical to producing solid, maintainable applications.

Jeff Hobbs is Languages Lead at ActiveState Software. He is the Tcl Tech Lead, has maintained the TK Usage FAQ since 1996 and is a program committee member for the USENIX Tcl/Tk Conference. Jeff is also responsible for product management and direction for other languages at ActiveState.

For more on dynamic languages, see ActiveState’s white paper:
Dynamic Languages — ready for the next challenges, by design.