October 28, 2015

The Need for a New Programming Paradigm

I recently had the pleasure of tutoring a new programmer through a college programming class. The class covered some intermediate constructs from both Python and CPP, but overall wasn’t very in depth with either. For the final project in Python, the student chose to write a simple script that would would read in a year’s worth of image files depicting the ice changes on Greenland and spit out a value quantifying those changes, effectively calculating the level of melt the continent has been experiencing over the year. It was a good idea for a coding project and had everything needed to produce a good program that would cover many different concepts: Loops, counters, functions, lots of variables, all coming together to produce a good grasp of program control. The program was written and submitted with my guidance and all went well, but during the process I realized something important about modern code craft: Programming languages suck.

Despite the fast pace that technology seems to evolve at, the languages that drive it tend to evolve at a much slower pace. Consider Perl. A language from the 80s, Perl version 5.0 was released in 1994. Now, some 21 years later, Perl 6.0 was finally announced as being nearly production ready (it has been in production as a sister project for some time, but not actively part of the code core). In short, a child could have been born and raised to the drinking age all within the lifespan of a single version number for Perl. And yet, Perl is wildly popular. A successful mix of the low level C language with shell scripting languages and AWK, Perl has long been considered somewhat of a duct tape language, capable of doing a little bit of everything whenever needed in whatever form wanted. Despite a loyal following, though, Perl has also long been criticized for its ugliness and steep learning curve. Yet this sort of acceptance of ugliness in programming is rather commonplace, and Perl is by no means an exception when dealing with languages.

The dream of the 80s is alive and well in the circles of native programming and in some cases, this dream extends back even further. FORTRAN and COBAL are both still in use in research circles and even though they are slowly being replaced by the venerable R language, even it is 22 years old (though thankfully updated at a more brisk pace than Perl seems to be). C is still king of the languages, spawning numerous offshoots that never quite seem to dethrone it entirely and it’s a language from the 70s. It’s more modern (some 17 years young) cousin CPP is still riddled with painful memory constructs that harken back to the era of the nibble, when kilobytes were the future and stacks of floppy disks where needed to install software. In my search for a truly modern programming language, I failed to really find anything of note beyond Apple’s Swift which is showing great promise, so long as it can overcome its initial history of platform specificity. I’m optimistic that perhaps Swift will do for native programming what WebKit did for the web, but this is very much a glass half full view of things.

Look at the following code snippet.

def log_output():
    of = open("log.txt", "a")
    of_size = os.path.getsize("log.txt")

    if of_size >= 327680000:

This was taken from the finished project I aided in (with permission) and is written in Python 3. This particular block does very little of note, slimming down a log file if it becomes too large, but that is precisely the point. It does so little, and yet you wouldn’t really know that at a glance, especially if you weren’t seasoned in reading code. To most, it would probably look impressive. Despite Python being described as human readable” and hailed as bridging the gap between scripting languages and OOP (a concept that I feel a bit blasphemous toward myself), it is decidedly really not that human readable at all, and really just looks like gibberish.

For fun, I decided to write this simple block in several other languages to compare. Here it is again, doing the same truncation process on a file, in CPP:

int logOutput(const string &file)
  ifstream of(file.c_str(), ifstream::in | ifstream::binary);
  of.seekg(0, ios::end);
  int of_size = of.tellg();

  if (of_size >= 327680000)
    ofstream of;
    of.open(file, ofstream::out | ofstream::trunc);

Compared to Python, CPP is even worse and basically unreadable without a decent level of how to read the language. At least with Python a casual glance can yield a general sense of what’s happening (a file is opened, size is taken and something is obviously truncated) but with CPP, the details are much more obscured. Part of that is the exactness with which CPP must be punctuated.

So what is the solution? Is there one? Perhaps. There is great hope in the web languages right now. As the web becomes more powerful, old native coding is starting to die a slow (very, very slow) death and instead is being replaced with a hybrid where web languages act native. JavaScript with it’s incredible frameworks and libraries that are in constant development is looking very promising to a certain extent (I need not mention React or Electron to my readers), but then again I fear JS is close to falling into the same trap that has plagued CPP: To become a language heralding from another time that has been stitched together to support modern standards rather than update the core language itself. There is a case to be made these days that no one ever just sits down anymore and writes HTML, CSS and JavaScript. Instead, they use prebuilt frameworks, sugared syntax and ready to use libraries to whip something up…and often times, it turns out good, but many times it also turns out…odd. Although these new alchemies have allowed a whole new generation of coders to spring up overnight, they also do little for extensibility and compatibility. Instead, they create a situation where everyone is using a slightly personalized syntax that everyone else has to learn. Consequently, it would seem as though there is no web language right now that’s quite right to take the place of a native language (and that’s assuming they had all the power of a language like C which they do not).

Now don’t get me wrong; I’m not suggesting that we fix what isn’t broken or try and reinvent the wheel. But I do think that new languages are needed to keep up with the developing pace of technology. The on boarding process for a new native language, whether it be structured, objective, functional or anything else is just too long for new programmers and the learning curve is often too steep. Going back to the student I tutored, she often found herself struggling with even simple concepts of CPP like operators and variable declarations. And she should be! We’ve all been there one time or another, trying to learn the difference between a double and a float only to be let down with the introduction of the long. To a seasoned programmer, such constructs are cake. To a new programmer, they’re off-putting and dated and they are far more likely to just pick up a web language rather than put in the time needed to develop enough real skill for native development.

This is what’s killing the native environment, at least on desktops. It isn’t necessarily that the web is better, but it is easier and programmers are lazy; new programmers even more so. It’s difficult to justify writing apps in Python or CPP and worrying about things that should be simple like distribution, when you could write a working web version that does what you need. And that’s great! I’m all for the rise of the web app. The web has become a powerful platform and it’s only going to get bigger. I love it. But it’s not quite there yet…not quite ready to replace a good native app. Native apps are far more stable, faster to use and integrate with their OS in ways the web has yet to master. It’s close, and wASM may push those boundaries to their limits, but we aren’t there yet and in the mean time we are left with a dry spell of withering native apps and poor web substitutes.

A new language, then, is really needed to bridge that gap and bring us into the modern era of native development. How that will look, I don’t really know. How it will be developed, I have no idea. Swift has the most potential, and I’d love to see developers on all platforms embrace it wholeheartedly. But in the end, we’ll just have to wait and see.

Previous post This is a place of musings. Technology and security. Fashion and couture. Philosophy and politics. This is a place for thought and free thought. A Next post A Defense of the Premium Apps Recently the music discovery service Bop.fm was purchased by LifeLock in a completely unexpected deal earlier this week. Unless you closely follow