July 11, 2005
Finding a New Programming Language
I'm looking into changing to a new language for our web development. We're using Perl for everything; Perl modules for data access and business logic and Mason (Embperl in old code) for templating. As we've attempted to find Perl programmers to fill open positions, we have a hard time finding developers with solid Perl experience, or developers who are interested in working in Perl. This has prompted a lot of discusson about leaving Perl for a language that will give us a larger pool of people to work with.
The question is almost more about the longevity of a language than about it's technical merits, but we need to look at both. There's also an element of interoperability in that we'd like to be exchanging data with other schools and potentially bolt our system together with others. That suggests we'll need to look at language adoption trends etc.
I've started digging around a bit to see what other languages might be a good fit for our application. We've got 400+ Perl modules, and around 650 presentation pages (including Mason, Embperl, XSLT and CSS stylesheets). 104,648 lines of presentation code and 99,770 lines of object code. Java has been suggested many times over many years, and I suspect that upper management will push us in that direction unless we find something more compelling.
I ran across an article from the Journal of Defense Software Engineering and liked a few paragraphs that talked about system languages and scripting languages:
System programming languages (C, Ada, Java, C++, etc.) are designed to develop applications from scratch with the help of a few class libraries. Scripting languages assume the existence of the necessary components and quickly and easily join those components together to form a larger application. System programming languages have high overhead in terms of their structure (try writing a Hello World! program in Java). Scripting languages can do quite a lot with just a few lines. A single line of scripting code may execute hundreds of machine code instructions where a system language may only execute tens of machine code instructions.
Scripting languages will never replace system languages, as scripting languages are not very good at programming complex algorithms and complex data structures, or for manipulating large data sets. However, scripting languages have their own strengths, including easily connecting pre-existing components, robustly manipulating a variety of data types from a variety of sources, rapidly developing GUIs, straightforward text manipulation, and creating and executing code on the fly. Scripting languages are the duct tape of the programming world.
Scripting languages are still very young compared to system languages. In all likelihood, many more evolutionary improvements will be made to them to make their strengths even greater. We predict that the easy work of complex algorithms, elaborate data structures, and brute force processing of large data sets will continue to be accomplished by system programming languages. More and more reusable components and services will be constructed using systems programming languages. However, the more difficult part of programming, that of developing a robust, easy-to-use application that is easily extended and modified as requirements change and the operational environment varies, will become more and more the job of scripting languages. Both types of languages will continue to evolve, but toward their strengths.
So what kind of language do we need? In addition to finding something that will facilitate organization of our code base, we need the following functionality:
- HTML building and delivery (duh)
- XML parsing/building
- XSLT processing
- Excel file building
- Database connectivity
- Database abstraction
- Image Processing (reseze, annotate, overlay)
- LDAP (secure)
- HTTP communication
- System calls
More to come . . .
Posted by mike at July 11, 2005 3:09 PM