AnalogClock






Wednesday, February 18, 2009

Your Fancy Language is Burdensome and Dangerous

I found this quote about the PL/I language in Wikipedia to be very poignant today. The quote's sentiment and the PL/I language are from the 1960's.
PL/I is considered by some to be a turning point where it was found that large languages with a lot of complexity that allow programmers to do almost anything (such as coerce types with no semantic relationship to one another) are burdensome and dangerous rather than "more powerful."

It echoes my low opinion of most of the toy languages that seem to be escapees from a Compiler 101 college course masquerading as the cure for the inability of some people to program. I find it to be very relevant to the object oriented mass hysteria and popularity of the latest scripting languages of the moment.

My opinion of C++ with the STL and templates and generic algorithms and iterators and iostreams is lower than my original opinion of C++ before it became standardized. What problem does all that junk solve. More to the point, what problem did object oriented programming ever solve beyond speed to delivery?

Object oriented programming is a morass and a tar pit. It's the all promise and no delivery. It eats up 90% of your programming time forcing you to write witty little programming ditties when you should be writing elegant, concise solutions that aren't 90% object oriented overhead.

Object oriented code hides not only the method invocation but also confuses the issue as to which method is actually called. Multiple inheritance in C++ and other languages demonstrated that the only part of multiple inheritance worth saving in other new object oriented implementations was the interface definition which is basically a template which is basically a macro. It saves you the onerous task of cutting and pasting. In C it's called a macro and it's frowned upon because it obfuscates what the final code does and looks like.

In summary. First write code quickly using only 10% of your programming time. Second scratch head and guesstimate what your code actually does and what are it's unintended consequences. Third hope there aren't any bugs that make your invisible untraceable code do something you didn't intend and use more resources then are necessary to do it.

I'm not saying I don't appreciate Python, Ruby, Perl, C++, Java, and the like. I'm just saying it's not that hard to write the little bit of code it takes to implement most software projects. Especially since the main benefit of most new languages is their extensive built in libraries. Not that you couldn't do the same thing in C by including the proper headers and linking in the proper libraries.

To be brutally honest I think in assembler so even C seems a bit like unnecessary overhead and a bunch of macros hiding the actual code.

I've been reading up on a couple of APL like programming languages J and K but after reading some of the original code for the original J implementation all I see it a bunch of nested for loops creating everything on the stack and avoiding calls to the C standard library to allocate memory.

Now I like APL and I hope to write my own version of it one day because it solves a real programming problem through it's expressiveness. The problem it solves is how to communicate complex and simple vector and matrix operations programmatically to a computer without having to jam a for loop into your equation. The analogy would be the poor man's version tacked on to most of the recent programming languages with list comprehensions and regular expressions. Which are not the same thing.

There are some nice examples of K and J at Wikipedia. I'm not recommending checking out APL as anything other than an educational exercise. I could kick myself for not learning it sooner as it shows how a well thought out programming language was written way back in time that blows the doors off all the fancy flavor of the year languages which waste our time by forcing us programmers to learn an unending stream of new syntax with exceptions that can't even express programming logic as simply and concisely as the A language, APL(A Programming Language) could more than half a century before.