Although I have admittedly not been keeping pace with the rate of elimination of the other big tournaments this month, I like to think that the delay between updates is building at least some semblance of suspense. Even if most of my coworkers think I have already crowned a champion, I have legitimately been analyzing and researching each matchup with an open mind. After the first half of round one, the field is still wide open, so without further delay, let’s jump into the next four games.
Our opening game this blog pits the world renowned Java (the language, not the beverage) against the quirky underdog, Assembly Code. As with our previous 1 v. 8 matchup, there is little doubt in my mind as to who will probably move on, but for the sake of fairness, let’s weigh some strengths and weaknesses. Java, as you may or may not know, started off as a platform for the oft-failed idea of 90’s web TV. Despite the embarrassing origin, Java’s founding principles hit the right notes of object oriented, multithreaded, platform independent code. Throw in Java’s prevalent role in the world’s most popular mobile OS, and Java is sitting pretty. Assembly language, the language of the first few weeks of Microcontrollers 101, has none of Java’s bells or whistles. Even when programming low level embedded and microcontroller devices, it’s likely that any remotely complicated program will be written in C or C++. Despite an impressive historical resume, and the ability to expose what your processor is actually doing, assembly obviously has little to no place in the modern programming language conversation. Java, book your ticket to New Orleans, you’re going to the Elite Eight.
Going in order down the bracket, we next get to LabVIEW and VB .Net. LabVIEW’s bread and butter, without a doubt, is the stellar NI hardware to which LabVIEW is inextricably tied. As such, LabVIEW is probably ‘the best’ tool for creating applications to acquire and analyze measurement data. However, the issue comes with asking it to do the same sorts of things that applications developed in ‘enterprise’ languages do. Just like you wouldn’t typically ask a PLC to play multimedia, LabVIEW isn’t great if you need inheritance, abstraction, or an extensively customized look and feel. In contrast, I often ask myself why VB .Net exists at all. I completely understand the need for readable code, but when lined up next to C#, VB just feels ridiculously verbose. I realize why VB .Net evolved, but, despite a short list of features found in VB and not in C#, I have a hard time justifying ever choosing the former over the latter. That being said, let’s just get out of this matchup and let LabVIEW roll.
In one of our more exotic matchups, Objective C tries to defend Leon’s honor in a battle against PHP. Objective C is one of those languages that started off simple but ended up becoming one of the big dogs by getting in with the right crowd, in this case becoming the basis for Apple’s Mac OS and iOS. Objective C and the overall dev package known as Cocoa have the benefit of Apple’s unified, streamlined approach to technology, which often leads to a robust programming experience.
Objective C also supports well-loved features such as reflection and garbage collection (although this is a recent addition), and it plays very nicely with standard C code, promoting reuse of existing tools. However, missing features like namespaces and the ability to overload methods show Objective C’s age.
In contrast to Objective C, PHP is another example of a niche language, existing primarily as a web scripting tool. PHP’s differentiator is in being a server side tool, allowing dynamic content generation closer to the many data sources, such as MySQL databases. This matchup is a tough one for me to judge, but in all, I think that Objective C is a broader brush with which to paint, giving it the go ahead to round 2.
Last but not least this week, we have C++ and Fortran, two languages that have polarizing supporters. I have always viewed C++ as one of those familiar, comfortable languages, not straying far from good ole’ C, but providing the flexibility of object oriented classes, exception handling, and the like. C++’s biggest negative could be that it is sort of a middle child, stuck between older low-level languages and the flexible, dynamic languages of the present day.
This means that it becomes easy to write inefficient code, but it also gives you the freedom to create really effective code without the overhead of higher level languages. This is likely the reason that so many drivers and OS’s (including Windows) are written in C++. Fortran, like LabVIEW or Matlab, might best be described as an academic language.
To some extent, we are all indebted to Fortran for popularizing the idea of a compiler that optimizes programs into machine code from high-level, human-readable syntax. Because it is so well optimized and geared for number crunching, Fortran can be a great tool for the type of intensive calculations often encountered by engineering and science researchers (which is probably why so many in academia still swear by it). Unless you’re working on your Ph.D. though, the shortcomings of Fortran probably mean there is a better language to do what you want, but at least we don’t have to write its name in screaming caps anymore. Begging the forgiveness of anyone over the age of 35, I’m sending Fortran home and C++ on to the next round.
As much as I hate having all the higher seeds move on, that’s the way it works out sometimes. Stay tuned for round 2!
Return to Round 1, Part 1
Continue to Round 2
