(C) 2009 Hank Wallace
PREVIOUS – Embedded System Design Library: Open Source Code
NEXT – Embedded System Design Library: Advanced Features
This series of articles concerns embedded systems design and programming, and how to do it with excellence, whether you are new to the discipline or a veteran. This article explores the way that some programming languages omit the most basic features, while going overboard on others that are either unnecessary or under used.
For example, take Java. Write once, run anywhere, right? WRONG, but I covered that in another article. The Java aspect that I want to cover here is that it has lots of glitzy features, but lacks some rudimentary capabilities which render the language almost useless.
I was writing an application that had about 475K of static data compiled into the program. This data comprised a fixed database, which data was displayed to the user in a certain graphical format. I started writing the program by declaring the static data in an array. The program grew instantly to several megabytes in size. Upon investigation, I found out that every byte in the data set and array was considered to be an ‘object’, consuming 7 or 8 bytes of memory! Gawd! What a mess. Upon further investigation, I determined that there is no way to declare static data in a 1:1 way in terms of memory space. When I started programming in BASIC and FORTRAN, there at least was the DATA statement. But in Java — NO!
So I had to store the data in a file on the server and read it into the program over the network. That raised some other questions. How do I secure the data? I could not build in encryption because the keys would be static. In fact, no method of securing the data would have any chance of working because of the next issue…
With Java, I learned, all the source code information, save for the comments, is included in the JAR file! ALL OF IT! I downloaded a Java decompiler and in about five minutes decompiled my program to produce a perfectly readable source text file.
So then I investigated encryption of Java JAR files and byte codes. There are some third party solutions which don’t work in a browser, or present difficulties for the user. There is something called ‘obfuscation’ which merely substitutes variable names with gibberish, but 100% of the numeric and algorithmic information is still totally accessible. How pathetic.
Regarding program features, I started working with the AWT user interface objects. But it appears that they have been deprecated by the newer Swing objects. Why? Java is what, 10 years old? Could the designers not design a comprehensive and usable user interface the first time out? Apparently not!
I previously discussed the lack of portability of Java. Working on this program, I had no end of grief to get it working on Macs and PCs, under various browsers.
In just one program language we have a regression of features. There is no static data storage, no portability, no code security, a confused mish-mash of multiple UI components, and many other silly design incompetencies.
With BASIC and FORTRAN, I could copy a program from one system to another and the programs just worked. Are the 20-somethings designing these new silly languages incapable of that today?
C and C++ have some of the same weaknesses, especially with the extensions under Windows. For example, let’s say you are writing a C++ program using Microsoft Visual C++. Try changing the color of the text in a static control. Is there a property for that? Under Borland C and DOS it was as easy as calling settextcolor(). One line of code. But under Windows and VC++ I have to override the paint procedure for the static control and do the text painting manually. It takes 50-100 lines to get the job done. Why?
The point of all this is to say that computer programs are generally not portable, and the features are a jumbled hybrid of miscellanea from whatever languages the designers had used in college. You cannot look at C++ or Java or VB and say that they were designed with a wholistic approach. No, they are tarballs of features, stuck on at the behest of MBAs in the marketing department or PhDs at universities, people who likely never wrote a production program.
When choosing a language for your next project, investigate all the ramifications. I chose Java for portability, never once dreaming that it lacked the ability to efficiently incorporate static data, or provide code security. Silly me. Protect yourself by never assuming that another engineer or programmer exercised his or her brain engaging in generalized thinking.
Author Biography
Hank Wallace is the owner of Atlantic Quality Design, Inc., a consulting firm located in Fincastle, Virginia. He has experience in many areas of embedded software and hardware development, and system design. See www.aqdi.com for more information.