Choosing a Language
Posted by Evan at 12:10 pm on August 9th, 2009
Earlier this summer, while doing some work for the Career Services department at LeTourneau University, the idea of automating the work I was doing (which was being performed almost entirely by hand - as it has been done for many years in the department) came up and the possibility of actually building a system to accomplish the automation came closer to realization than it ever has before. Once I was given the go-ahead, I began to work on prototyping the program but one of the first hurdles I discovered I would have to contend with was choosing a language.
This was, for the most part, a new conundrum for me. For school assignments the language is almost always specified by the professor, or else the professor's personal preference (or the default language of the computer science department - yes, that's how small the CS department at LeTourneau is) holds sway and the majority of students just work in that language; when it came to personal projects I would generally approach development from the perspective of languages I already knew how to work with, unless the purpose of the project was to help me learn a new language, thus saving time by avoiding needing to spend the little free time I had learning a new language with all its intricacies and irregularities.
Though I hadn't had to deal with this particular development issue before, it's an important consideration. It affects your development environment, your coding efficiency (depending on how familiar you are with the language), your available libraries, the platforms and operating systems your final product will be able to run on, and a host of other details. So when I realized I could actually choose the language I wanted to write this application in...I was a little overwhelmed! The main languages I was considering using were Java and C#: so similar, and yet so different!
In terms of ease of use (in the short-term, anyway) Java was by far the favored choice: I've been programming Java applications for many years and LeTU uses Java extensively in its computer science courses. C#, on the other hand, was unknown to me. I knew the syntax was C++/Java-ish, but there would be an initial period of "tripping over my own code" and frequent references to documentation as I learned the nuances of the language. An interesting note about C# is that while it is not used by the computer science courses at LeTU (well, none that I've taken anyway), it is used by LeTU's IT programmers - which means that, since what I'm developing will be a "university" application, there's a chance that a problem with it might be more easily diagnosed by IT if the application were written in C# than if it were written in Java. The same conclusion applies with respect to the computer science department (and its students) and writing in Java, however.
Programming in Java would also provide the ability to run the program on any operating system with a Java Virtual Machine. But the need for the JVM to be installed on the client machine presents a stumbling block. Since the program would be used (primarily, if not exclusively) on LeTU's computers where most users are handicapped and unable to "permanently" install software, requiring the JVM where the JVM might not be installed by default would render the program virtually unusable to the user. In addition, the target users for this program would be on those same almost-exclusively-PCs-running-Windows university machines, so cross-platform access is very low on the priority list and C#'s .NET Framework requirement is satisfied.
Early on during the research phase of choosing a language I investigated the availability of libraries for each language to enable the code to interface with a Microsoft Access database. (The decision to work with Access databases was also an issue which needed to be thought through, but that process deserves its own post instead of being cursorily dealt with here.) Both languages have libraries which can enable a program to connect with Access, Java through JDBC and C# through OLE DB, but the degree of connectivity provided is rather different: both provide standard CRUD functionality, naturally, but C# also allows the developer to interact with some of Access' "deeper" commands (such as the oh-so-annoying-yet-oh-so-necessary "Compact and Repair Database" option). In my years of working with Access regularly at Career Services, I've found that every so often it becomes necessary to compact a database in order to reduce the database file's size; since the system in development will likely put an even larger strain on Access, it makes sense that the database will need to be compacted even more regularly and, hopefully, that can simply be dealt with programmatically. I haven't found anything that says JDBC can compact and repair an Access database (which isn't too surprising) and so this issue lands quite strongly in C#'s favor.
Another point in C#'s favor is that in my research I learned that if I were to develop in Java I wouldn't be able to (easily) connect with an Access database file stored on a remote file system, but that C#
There were a few other language characteristics I took into account but the ones I've discussed above were the primary points on which I eventually based my decision. And while I dislike the idea of working with a language standardized by Microsoft, C# appears to me to be the best candidate for this project - so that's what I've been doing my prototype development in.
There is 1 comment.
| 1 |
Leave a comment
September 8th, 2009 at 1:38 pm