Skip to content

Programming Language Level

by Adam on January 25th, 2005

This is a warning off the top just because everyone is biased no matter if they believe they are or not. My opinion, expressed in the following entry, is simply how I feel about programming language level and not related to studies or history or research into which is better. No flaming please.

Its my thought that there is really no way to , without bias, study this topic as each person is comfortable with whatever they learned on and uncomfortable otherwise. I am a hardcore C programmer and I have been for many years now. I find it difficult to think in object oriented style and thus I am very productive with C. If for some reason I switched to Java or C++ or Python or Rational Rose I would be unproductive for a while until I became comfortable with the new paradigm. Whether or not I would be a more productive programming using Rational Rose or C is something that in my opinion can’t be calculated.

Everybody (sorry, every programmer) has a favorite language. It is the one you default to when the problem at hand doesn’t force you a certain way. I program heavily in C but I am certainly not adversed to using Perl when the need arises. It comes in handy for CGI programs and command line applications where high level processing is needed since it has a huge library [cpan.org] of modules that perform text processing or networking, etc. C has little of this and so you must write it yourself, but why when Perl exists? I use C for OpenGL programming since that makes up the majority of my daily programming time. OpenGL is built on C and thus integrates perfectly so why not use C? (rhetorical) Of course it is possible to use any language that has included OpenGL bindings, for example here [nigels.com] is a C++ object binding for OpenGL. That favorite language is the one you are the most productive in regardless of its level. That being said what is my view on high vs. low vs. extremely high level environments?

I have worked with assembly language during a university course. It was easy to write, with very limited but powerful instructions but was difficult to design since you need to spend a lot of time on even very simple algorithms. Componentising the code into functions makes it easier to deal with the complexity but there is a lot of overhead when switching to a function and back again. You need to save your jump back point on the stack and any data in temporary registers. Then jump and when it returns you need to grab the functions result and restore the registers from the stack. Even if you are very comfortable with assembly it is difficult to be productive because of the amount of time (ie lines of code) you need to write to realize your design specification. It is defiantly true that the more lines of code you write the higher the potential for bugs. I can’t think of anybody, except maybe these guys [v20s.v2.nl], who would write entire applications in assembly, it just doesn’t make sense. Assembly does still have its place since it is very low level it is very fast. Programmers can take particularly high traffic pieces of code and write them in assembly for optimization.

Rational Rose [ibm.com] is a development environment that allows you to take your design specification in its extremely high level glory and enter it almost exactly into the environment. The program itself then takes the pieces and generates the code and executables for your project. I have used this very little so I don’t know how much effort is required in setting up your design specification within the software but I do remember having to worry about message passing, ports, connectors, aggregation, etc. which was difficult to become comfortable with. In addition generated code like this is almost never very clean and efficient. It is true with high level HTML editors and it would be extremely true of C++ or Java editors. Also I consider this a more Visual Basic like approach to programming, which is to say its powerful under the hood but too “drag and drop-centric” on top leading to inefficient programs.

Visual Basic which came up in the last paragraph is a very high level application development environment. You create your form and drag buttons and text boxes onto it until you have a GUI to your hearts desire. Then you hook up the functionality behind the scenes using simple parameter manipulation on the objects of the form. Once you get into actually trying to program an application other than a simple GUI you get into trouble and run into the limitations of the environment. This is much less true of Visual Basic .NET which is a huge leap forward for the platform. It allows concurrency to be done in an unlimited way and breaks away the networking components into object libraries. If you have not tried out Visual Basic .NET I suggest giving it a whirl you’ll be impressed. Event driven programming (the basis of VB) is a great concept and allows the user to ignore a lot of issues that dealing with things like Win32 bring in; however as soon as you give execution control away algorithms and design become much more difficult in complex applications. I lump some Java IDEs into this category as well as Visual C# .NET and the horrible MFC libraries. Try before you buy Visual Basic .NET [microsoft.com] or Visual C# .NET [microsoft.com] or Borland JBuilder [borland.com]. It is true that GLUT [freeglut.sf.net] is event driven and this does make large application programming difficult. You need different callback functions to do different animation and need to have a state machine design diagram for anything more complicated than a simple demo.

Next time C, C++ and Java

From → Uncategorized

No comments yet

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS