Updates to this page are indicated thusly [date].

Contents

• What Do Engineers Use?
• What SHOULD You Use?
• Level of Effort

Note: 'engineer' as used here implies an 'engineering graduate', as opposed to someone appropriating the engineer title without benefit of education or equivalent experience.

---

 

What Do Engineers Use?

The chart is a tabulation of data taken by the magazine Personal Engineering, January 1998 (now defunct). They asked engineers What languages do you use? Scoring was based on 0 = "never use that language" to 3 = "use it frequently."

Note that these languages are all the second choice. The engineers' first choice is a spreadsheet (Excel, Quattro, 1-2-3).

I interpret these data to show that, for the most part, engineers write "small" programs. This seems evident because only one language (C++) of these most popular languages adequately supports "programming in the large." [Note: although there have been several definitions of "large program," a consensus is difficult to obtain, so I will define it thusly: I don't know what a large program is, but I know it when I see it.] 

[ top ]

What SHOULD You Use?

When I write programs, I prefer

• C++, because of the language concepts and because of the Standard Template Library (STL) (but see below) [3-Dec-02];
• Delphi, because I have been writing Pascal for a couple of decades;
• C#, because it overcomes many of the problems of C++ [3-Dec-02]

Although I prefer these languages, this is NOT a declaration that one language is "better" than another. My  view is that ALL languages are useful, and I try to use whichever language is appropriate to the task at hand. Any evaluation involves politics, as well as estimates of time and money.  But trying to compare languages on these bases is a  trap. There has never been, and there never will be,  a direct comparison of the cost of building the same significant program using different languages. It can't be done because the conditions can never be identical. It's not the language that's important; rather, it is the people who are using the language that are the crucial element. 

Let me mention a few of the problems that must be addressed when using Visual Basic 6 as a development language:

1. Although Microsoft’s claims that VB6 is object oriented, it  is NOT, so a programmer cannot develop object hierarchies. If you are not an Object Oriented programmer, this will not mean anything to you, but I have found the Object Oriented approach to be a more robust way to develop software, and in general, I can develop programs faster using objects.
2. VB6 is not type-safe. This means that the compiler will accept code in which can you pass the wrong kind of argument to a function. The worst part is that the compiled program may actually work. This makes it extremely difficult, and therefore, tedious and expensive, to find bugs. I don't particularly like debugging.
3. Distribution of VB6 programs requires the distribution of the run-time environment also. The size of the distribution means that several 3.5 diskettes or a CD are required for the tiniest program. This seems excessive.

Drawbacks 1 & 2 are also present in Visual Basic for Applications, a "scripting language" that allows programmatic control over Microsoft Office. However, all drawbacks notwithstanding, if  one wishes to control Word, Excel, Access, Outlook, Visio, etc., knowledge of VBA is required.  The widespread use of VBA as a scripting language for  non-Microsoft applications makes it a valuable language to know.

The universal acceptance of JavaScript as a web browser programming language means that vbScript (Microsoft's web scripting language) will eventually disappear. My mistake. We're using VBS extensively in our ASP development efforts, and are developing tools to make its use 'reasonable' in view of the lack of type-safe programming [3-Dec-02]

[ top ]

Level Of Effort

In the article "Estimating Software Costs," by William Roetzheim, Software Development Magazine, October 2000, Vol 8 No 10, Roetzheim presents the following table cribbed from the work of Capers Jones. The SLOC per function point is the level of effort required to write a particular program in the corresponding language, assuming the language is suitable . These numbers are being used to estimate the cost of writing programs. SLOC is Source Lines Of Code defined to be a human written line that is not a blank, not a comment.

Of the three languages that I might prefer for a project, I find it interesting that the level of effort for Delphi is about 2/3 of the effort required for VB6. 

I also predict the C++ number will decrease over the next few years as the compilers become standard-conforming, and programmers begin to make greater use of the STL. However, C++ is so hard to learn that we are abandoning it as a primary programming tool [3-Dec-02]

It is not clear that the SLOC measure anticipates developer tools that speed up development such as our ClassBuilders for Delphi and C++, or Mark Miller's CodeRush for Delphi (among others).

[ top ]

- Peter N Roth, President, EOI