Hammering corkscrews

One recurring question I have during class is “why is Java better than other programming languages?”. Well, I never said Java is better or worse, but since these engineering students have been using C over the last few years, they don’t understand the need for another “new” language to learn.

Personnally, I do most of my development using C and Objective-C. Java is my third language of choice, but only because I feel like I can do better with this language than with any other cross-platform API/language.

Now, I don’t think I have the talent of John Gruber, but I agree wholeheartedly with his post on API wars when he states :

So the argument here shouldn’t be that Carbon is old and Cocoa is new, or that Carbon is bad and Cocoa is good; no, the argument is that Carbon is lower-level and Cocoa is higher-level, and programmers are almost always more productive, write fewer bugs, and have more fun when working with higher-level APIs.

Note for the people who don’t know what the hell Cocoa and Carbon are : these are two different sets of APIs used to write programs for the Mac OS X Operating System. You can add the BSD libraries to the list, but it is beyond the point.

This is the whole point of choosing an API or a language : finding the most efficient way of doing your job. If you are more proficient with C, the question becomes “would it be faster to create a workaround this problem so that I can continue in C, or to switch to a language I don’t master?”

In computer theory, there are ways to prove that every language is equivalent (at least the Turing-complete ones), and as hackers all around the globe know, you can pretty much plug anything in anything, provided you spend enough time on bridging the gap, or creating the interfaces.

Basically it means that you choose whatever language and API set you see fit. It is your own choice, based on preferences, deadlines and goals.

I’ll just add a few things to take into account when you choose your language/API (level, object vs procedural, and compilation):

  • Lower-level means that you have more control. You know what’s going on under the hood, and if that is something you need to have, then it should tip the balance a bit. It helps for close-to-the-system developments, as well as for optimization. The main drawback is that you have to control everything : for complex matters, it lengthens the code, and you have statistically more bugs.
  • Higher-level means that you are free from most of the painful stuff. In that sense, you write more complex programs with less code. The key there is that you have to trust the underlying layers absolutely, because you won’t be able to do anything, should there be a bug in the code you didn’t write.
  • Procedural languages are great for linear programming. If you know that your program is basically a tree that comes from one entry point to several possible exit points, it will be easy to write functions accordingly and “chain” them in the proper order. The need for a superstructure is non-existant. Procedural languages, since they are linear, have a somewhat ambiguous relationship with function loops ( A() -> B() -> A() ) and waiting.
  • Object-oriented programs are better at data handling. All the data you have is represented by objects that interact with each other. If your program is about modules that interact with each other, and data-driven, then all you have to do is describe your world, both objects and interactions. Then “launch” your world, and watch the universe follow its rules. Since they are highly descriptive in nature, object-oriented languages tend to call for a lot of code for small usages.
  • Compiled programs are “faster”, as they are translated once in a language the computer understands naturally, thus reducing the need for dictionnary lookups. The problem is that you need to compile the program for each and every platform you wish to support.
  • Interpreted programs (whether through bytecode, or “scripting”) can run without hassle on many platforms without compilation. The end-user gets one application that will work, whatever his computer might be. However, the perpetual translation can slow down the execution, and requires someone to create the interpreter and make sure it works correctly on the desired platform.

Most of the other reasons for choosing a development set over another fall under two categories : personal taste (for the platform, language, API, or anything else), or professional obligations (targeted platforms, integration in a greater whole, …). No one criticizes you if you think in your country’s tongue, so no one should criticize you if you code in your preferred language. Just make sure you don’t choose only out of taste.

  

Leave a Reply