Menu

Programming Languages and Subjectivity

August 16, 2013 - .NET, Programming

Discussions about programming and programming languages are frequent. They can get heated. One interesting notion is the notion of language “prettiness”; what makes it interesting is that it is heavily subjective. For example, a Programmer may say (hopefully with hyperbole) that “BASIC makes my eyes bleed”; while another programmer could easily say the same thing about C.

I’ve give nthis topic some notional thought, and I thought I would share some of the conclusions on this matter. First, it’s clear that the notions are entirely subjective. This is clear because if they were in fact objective, there would be some strong factual basis and measurement for “code beauty” or “prettiness”. Since there isn’t one, and since not everybody agrees on what is or is not pretty, it’s subjective.

Let’s consider a very short program, written in a few languages. This isn’t anything as complicated as the Anagrams Search Program that I’ve written about before for various languages; this one will simply count from one to 100 and print out every 6th even number. Let’s start with Minimal BASIC, which is a restricted subset of BASIC. We’ll ignore the fact that we could simply get the same output by counting by 12.

What can we say about that? Early Programming languages such as those that would require this Limited subset were from an earlier time. A lot of the focus of Software was simply getting things to work; we didn’t yet have the luxury of fancy structured programming techniques, OO techniques, or anything of the sort. We had to get by with what we had; sort of like primitive humans had a vocabulary of guttural noises and thus didn’t have the verbal dexterity to express themselves accurately, or purvey certain nuances; of course we still have that with modern languages, but we can do a lot better at expressing our thoughts than with a series of grunts now. As such the Logic here is basically lowest common denominator; this was a dialect that lacked even IF…THEN, FOR…NEXT, WHILE…WEND; in the above, loop and IF block functionality is “emulated” using GOTO. I added comments in a few locations but that doesn’t help completely. Another problem is that in those early implementations, all Lines had to be numbered, so we had the issue where if you had to insert lines of code between two other lines, you needed to either renumber every single line and every single GOTO that referred to those lines from that line downward, or you used a lax line numbering mechanic that allowed lines of code to be added later. Most conventions go with 10, I went with 100 for no particularly strong reason.

Let’s upgrade this to a more Modern dialect- Structured BASIC programming:

It’s hard to argue that this is not more clear and easier to read and understand than the previous example. BASIC- even in the form of Visual Basic or Visual Basic.NET Today- get’s something of a stigma associated with it. Part of this is due to Edsger Dijkstra’s “Goto Considered Harmful”. However, I think it’s fair to point out that the dialects of BASIC often mentioned with such chagrin are typically what the original creators of BASIC refer to as “Street” BASIC. What this means is that they aren’t truly the type of language the creators had in mind. When many people consider old versions of BASIC, some of the first things they think of are things like Line Numbers and excessive GOTO usage, but this was not the vision the creators had. It’s simply what ended up becoming a “standard”.

As we move forward through different Programming Languages, we see that they all modernize in different ways. Like a evolutionary tree, some languages die off; others find their own evolutionary niche and prosper there. Still others are able to expand and “dominate” the general programming consciousness, simply because of their reliability and general purpose applications.

A good example would be to show the above example written in C#:

Arguably, this isn’t even easier to read than the original BASIC version. Though in practice it is slightly easier to follow, once you understand the functions and constructs being used in each. In this case, it uses LINQ (Language-Integrated Query) which I believe I’ve used liberally in my other blog posts covering C# topics. Here the code uses Enumerable.Range() to create a sequence of elements from 0 to 100; then it uses the Where() extension method to transform that sequence into a sequence that only returns every 2nd element; then it calls Where() again on that result to take every 6th element.

When it comes to programming language analysis, one will find that the languages they currently know (to a reasonable, functional degree) will heavily influence both their opinions on other languages as well as how they try to learn those languages. This is something that needs to be taken into account when looking at Programming languages and trying to come to a reasonable description and analysis. This post itself was primarily inspired by a forum post I saw that decried another user for using FreeBASIC. Their argument consisted primarily of “it’s ugly”; but that’s purely subjective. I’ve seen others issue complaints about languages being ugly because they lack square brackets, or vice versa. I would argue that such a consideration and analysis- steeped heavily in one’s own experiences- needs to be combatted at the rational level. For example I work primarily with Java, and C#, but I also started with Visual Basic. Therefore, I can understand the considerations on each end. When I was using VB I thought C-style language and block statements were ugly; when I first started using C# the main thing that cropped up was I wasn’t putting semicolons at the end of statements. Now, when I go back to VB.NET or VB, the lack of semicolons and braces can be weird; instead of End If I will try to put in a }, for example; or I accidentally insert semicolons at the end of statements without thinking.

Even so, I can still see the capabilities and interesting design decisions that went into Visual Basic, VB.NET, and languages like FreeBASIC, and try to capitalize on their strengths. The big problem when it comes to people learning new programming languages appears to be as a result of them trying to write their favourite language style into that new language. This is a refusal to adapt to that new language, trying to cling to their familiar language idioms by translating them into the new language without actually understanding the specific capabilities that new language gives.

In conclusion- don’t be a single-language programmer, and don’t restrict yourself to some specific set of languages. Always look to expand the language understandings you have as well as seek out new programming languages to study and learn from. You can bring a lot of the things you learn into the languages you already know. I ironically learned a lot about C# by learning a bit about Scala and F#, for example.

Have something to say about this post? Comment!