There is no dangerous language only dangerous programmers

It seems the data and comments presented in "Software Failures, follies and fallacies" by Les Hatton provide support for the above mentioned comment.

We all extol the benefits of our favourite programming language whilst denigrating other languages less attractive to us.  In truth, published data from around the world of which Table 2 is a subset shows  that there is no clear relationship between programming language and the defect density of systems implemented in  that  language.    Ada,  for  example,  supposedly  far  more  secure  than  other  languages  produces systems of comparable defect density.  In contrast,  C is reviled by many  safety-related  developers and yet it is responsible for some of the most reliable systems ever written.   We  can  conclude  that programming language choice is at best weakly related to reliability.

However, I doubt his conclusion from

a  recent  study  comparing  two  similar  systems  of  similar  size,  (around 50,000  lines each), one  in  C  and  one  in  object-designed  C++,  the  resulting  defect  densities  were shown  to  be  around  the  same  at  2.4  and  2.9  per  1000  lines  respectively,

that

that language has little effect on reliability, object-oriented or not  and  that  the  massive  drive  to  object-orientation  is  another  giant  leap  sideways  in  which  the software industry appears to specialise.

It is unfair to conclude a programming paradigm is defective or fail to live up to its touted benefit from observation on a programming language. This is particularly true for C++ which actually is hybrid in nature - a better-C and Object-Oriented programming language.

From my personal development experience and reviewing code, a person using an object-oriented language, be it C++, C# or Java, does not necessary mean that the developer is apply sound OO principles to their creation. It is the use of these principles that give rise to the touted benefit. 

If they are not applied, C++ and other object-oriented language can result in system with far worse defects and undesirable features than say a procedural language like C. Lakos echos similar sentiment:

It is completely wrong, however, to think that just using C++ will ensure success in a large project.


C++ is not just an extension of C: it supports an entirely new paradigm. The object-oriented paradigm is notorious for demanding more design effort and savy than its procedural counterpart. C++ is more difficult to master than C, and there are innumerable ways to shoot yourself in the foot. Often you won't realize a serious error until it is too late to fix it and still meet your schedule, such as indiscriminate use of virtual functions or passing of user-defined types by value, can result in perfectly C++ programs that run ten times slower than they would have had you written them in C.
[...]
Unfortunately, the undisciplined techniques used to create small programs in C++ are totally inadequate for tackling larger projects. That's to say, a naive application of C++ technology does not scale well to larger projects. The consequences for the uninitiated are many.

---

"Large-Scale C++ Software Design" by John Lakos, page 2, Anddison Wesley Longman Inc. 1996

What a piece of gem

I am so glad that I have rediscovered this piece of gem titled "Good practice in software" by Les Hatton. It should be read by any aspiring or experienced developer. It is full of timeless advices and facts, like this:

Perhaps the biggest surprise in an industry awash with technology is that it doesn’t seem to make much difference. By far the biggest factor which emerges in most studies is the individual quality of the engineers who build a system and a few common-sense principles.  We have known this since the admirable book by Fred Brooks, [6] which every aspiring software producer should read. Rather than absorbing this powerful lesson, the computing industry became obsessed with the notion that the process or bureaucracy of building software was the most important part.  The evidence is to the contrary.  No matter how well- defined a process, the quality of the product still depends mostly on the quality of the engineers who build it. To this, a good process can bring consistency and accountability.

So true! People are forever darting from one language to another or from one technology to another in an escapist attitude to avoid the hard slog of learning the trade!

Using PasswordSafe in Windows 7

I am surprise to see the latest version (ver 3.25.0.4042) still does not have the embedded manifest file to tell the Windows 7 the execution level required. When you invoke the pwsafe.exe, it triggers the UAC's attention resulting in this message box:

Not nice. You can prevent this by unblocking it. To do this, you right mouse click on the program in Windows Explorer and then select the properties. On the general tab in the properties dialog box, you should see the 'Unblock" button as circled below:

Once unblocked, it will not throw up that frightening first message box.

Let's hope this annoying issue will be addressed soon.

Safe way to close down a ClientBase<T> object

Recently a good friend of drew my attention to a situation I consider a bad disposable object implement and pointed me kindly to an MSDN article offering some words of advice and work around. This saved me considerable research effort. I will address the bad disposable object implementation later.

The problem is that when using the using statement to dispose a ClientBase(of T) object, the base class of WCF proxy stub, you can run into a problem where leaving the using scope the exception thrown in the Dispose() can mask out application exception that causes the execution to leave the scope in the first place. This denies the client the knowledge of the application exception.

The MSDN article explains this phenomenon very clearly and provides an excellent recommendation to handle this problem. The recommended work around places higher value on the application exception as compared to the one that is likely to happen when the Dispose(), or rather Close(), is called. The recommendation uses a multi-level of catches and then use either ClientBase(of T).Close() or its no-throw equivalent ClientBase(of T).Abort() strategically.

While the work around code presented in the article is written in a style that shows clearly how to tackle the problem, it is rather clumsy to use in real life. It expects too much from developer to know when to called Abort() and when to call Close(). Furthermore, it changes the shape of the code drastically to a somewhat awkward and unfamiliar form. It therefore leaves room for improvement and a simple class designed to meet the following objectives is described below:

• Perform automatic closure of the ICommunicationObject using the same elegant form of the using statement.
• Prevent the application exception, the one that is thrown inside the using statement scope, from being masked and passing it to the client unhindered.
• If no application exception, it allows exception that can be generated during the disposable of the ICommunicationObject to pass to the client.

I want to use a pattern like this:

public void GetSomeData( .... ) {
   using( SomeHelper helper = new SomeHelper( new CalculatorClient() ) ) {
      GetData( helper.Instance() );
   }

This SomeHelper class must meet the above objectives.

Recognizing the issue at hand is how to handle the System.ServiceModel.ICommunicationObject, one of the interfaces implemented by ClientBase(of T), I construct the following disposable generic class called SafeCommunicationDisposal.

using System;
using System.ServiceModel;

namespace DisposingCommunicationObject
{
  public class SafeCommunicationDisposal<T> : IDisposable where T:ICommunicationObject
  {
    public T Instance { get; private set; }
    public bool IsSafeToClose{ get; private set; }
    public void SafeToClose() {
      this.IsSafeToClose = true;
    }
    
    public SafeCommunicationDisposal (T client) {
      this.Instance = client;
    }
    
    bool disposed;
    public void Dispose() {
      Dispose( true );
      GC.SuppressFinalize( this );
    }
    
    private void Dispose( bool disposing ) {
      if( !this.disposed ) {
        if( disposing ) {
          Close();
        }
        this.disposed = true;
      }
    }
    
    private void Close() {
      if( IsSafeToClose ) {
        Instance.Close();
      } else {
        Instance.Abort();
      }
    }
  }
}

With this class I can rewrite the naive usage of using the using statment from this:

using( CalculatorClient client = new CalculatorClient() ) {
      // use client to do work
  }

to this form which does not mask out application exception on leaving the using scope and yet closing down the communication object properly:

using( SafeCommunicationDisposal<CalculatorClient> d = 
            new SafeCommunicationDisposal<CalculatorClient> ( new CalculatorClient() ) ) {
     CalculatorClient client = d.Instance;
     // use the client to do work. If it throws exception
     // it will be passed over to the client and not masked by exception 
     // when client.Close() is executed.
     d.SafeToClose(); // This tells SafeCommunicationDisposal to use ICommunicationObject.Close()
} 

The fundamental principle is to tell SafeCommunicationDisposal what to use to close down the ICommunicationObject when execution leaves the using scope.

If it leaves by normal means, the SafeCommunicationDisposal.SafeToClose() sets a flag to tell the SafeCommunicationDisposal.Dispose() to use ICommunicationObject.Close(). If Close() throws an exception, it is then passed to the user.

If it leaves as a result of an application exception, SafeCommunicationDisposal.SafeToClose() will not be executed and SafeCommunicationDisposal.Dispose() will use ICommunicationObject.Abort(), a no-throw method to shut down the communication gracefully. This does not mask out the application exception.

If a developer forgets to call SafeCommunicationDisposal.SafeToClose(), the SafeCommunicationDisposal.Dispose() takes a more defensive route of calling the ICommunicationObject.Abort().

I believe this class can help to make the code more readable, maintainable and using a familiar using pattern to correct the  naive usage that minimize code change.  

The moral of this story is that if you are designing a disposable object, it is wise to heed the following advice "Avoid throwing an exception from within Dispose except under critical situations where the containing process has been corrupted (leaks, inconsistent shared state, etc.).". This is a well known no-no in unmanaged C++.

Caveat in using Matlab DLL in ASP.Net

I was crafting another WCF Service using basicHttpBinding that used a Matlab NE Builder generated DLL and was keep getting System.TypeLoadException on the class' constructor. This problem was reported but there was no conclusive explanation other than ASP.Net page time out being set too short. But setting that to a long value did not help and certainly did not help me.

My unit test using the DLL directly proved that the DLL was working perfectly and hence it must be environmental. Not the person easily defeated by this kind of issue, I took this up as just another challenge. There must be an explanation.

Being certain that it was environmental, I began to investigate the ASP.Net runtime infrastructure. I know when the Matlab DLL, called a deployment DLL for all the right reasons, was first used, Matlab runtime will expand the embedded scripts, albeit compiled, into a runtime folder structure under the matlab_mcr folder. This folder structure replicates the same directory structure from the root directory when the deployment DLL was built. matlab_mcr is the folder created at a nominated directory.

So if when you build your deployment DLL in say

"C:\Documents and Settings\John\My Documents\My Matlab Project"

Matlab runtime will try to create a structure like this:

[TempDirBase]\matlab_mcr\Documents and Settings\John\My Documents\My Matlab Project

where [TempDirBase] is the base directory where your run time is going to use. If it is the %Temp%, then in XP it is

"C:\Documents and Settings\John\Local Settings\Temp"

If you are like me using very verbose and easy to remember project name organized in a meaningful directory structure and using long matlab function names, the path that Matlab replicates at run time can easily approach the maximum limit of a path name.

In fact the cause of the TypeLoadException by the matlab class was exactly what I encountered when I was using NUnit to unit test code that used a deployment DLL. In NUnit I simply changed the shadow copy directory.

In the ASP.Net situation, the length of the default ASP.Net temporary directory path coupled with my build location caused the operating system to fail to recreate the matlab run time structure because the path length exceeded the maximum permissible length.

Armed with prior experience and the ability to change the ASP.Net default temporary file directory to a different location, I used a 2-prong attack to ensure that matlab's silly recreation of the directory structure will not bother me anymore.

Here is my technique to fix this problem:
1) Build the deployment DLL in a extremely cryptic and shorten path.
Build the deployment DLL in a very cryptic and extremely short path like this c:\0\1 or c:\01. I choose this pattern because I am going to have several of these deployment DLLs and so each one can grab a different number as directory name. Since this is only for run time and it is totally meaningless human, they can be very cryptic. The aim is to make it as short and as flat as one can get and.spare no mercy to Matlab.

You can even use these numbers as your extra version identifier.

This recommendation does not mean that you need to store your project that way. You should store them in as meaningful directory as you can for easy of maintenance and team spirit. By default action, when Matlab replicates this at runtime, it discloses your project organization and if you store your project in the profile area, Matlab can disclose who you are. By using a cryptic and short build path, you prevent Matlab from disclosing such information.

Since I always build these deployment DLLs with a batch file for good technical reasons, it is only a matter of adding extra batch commands to create the build directory described above, and to copy all the .m, .prj, .cs, etc. to the build directory and kick the build from that build directory.

When the build is finished, you copy the output files back to a generated output directory in my solution. The batch file can include commands to remove the build directory.

2) As an extra measure to combat this Matlab bloated directory problem, you change the ASP.Net temporary file directory, which is conveniently applicable per application using the web.config.

This can be achieved by specifying your temporary directory to a very short path name in the tempDirectory attribute of the <compilation> element.

Arm with these and a very long "ASP Script timeout" for your application, changed via the IIS console, you should have no trouble with using Matlab deployment DLL in IIS.