Commonalities between Home Depot and .NET
In the last few weeks, I have been developing a couple tools in C#, half in Microsoft Visual Studio 2003 and the other half in Microsoft Visual Studio 2005. I maintain some of my initial reactions to C#, but I have begun to see why Kevlin Henney believes that C# is a more expressive language than Java. Take, for example, the following Java code:
- for ( String str : list ) {
- System.out.println( str );
- }
You would really have to know that this is a for-each statement or at least spending a couple seconds figuring that out the first time you see it. On the other hand, consider this C# example:
- foreach ( string str in list ) {
- System.Console.WriteLine( str );
- }
That is very obvious, and can be easily read aloud.
That said, however, this morning I read Billy Hollis’s How is the .NET Framework like Home Depot? and I couldn’t agree more. The .NET framework is not obvious when you do not know exactly what you are doing, and it can be daunting to find the answer.
I have witness this myself a couple times in the last week. For many things, you can simply Google and find enough hints to get you through the situation, but one problem I still have not solved. According to this MSDN Chat, you can implement an ActiveSync Service Provider using C# by implementing two COM interfaces, although he is unaware of anyone actually doing this, but I have not made major headway in this area after trying for a couple evenings (this is not particularly useful, BTW).
This is probably an extreme case (though you would think that C# would be a first-class citizen), but I regularly find myself knowing that I want a particular class or behaviour, but I am not sure what it is called. For example, the other day I was looking for the a map class, similar to Java's java.util.Map or C++’s std::map, and it was rather surprising to find out that this class named System.Collections.SortedList, a class that I would have assumed would have meant that the items in the list were sorted, not a list of key-value pairs, sorted by key.
One of the biggest issues with .NET is definitely the documentation. The documentation is generally brief or misleading. Some entries are simply filled with examples, such as when upgrading to 2005, the debugger will throw an InvalidOperationException if you attempt to perform an operation on a control that was created in another thread. When this occurs, it will refer you to How to: Make Cross-Thread Calls to Windows Forms Controls; the entry, however, does not describe the technique that you are employing, and the example is much longer and convoluted than it needs to be.
There are definitely some improvements in the newly released Visual Studio 2005, and while some of the things I have mentioned above will hopefully be addressed in future releases, some of them are not easily resolvable (like the Map-class), but at least they are going in the right direction.
Leonardo’s Laptop...
One of the books that I have recently read is Leonardo’s Laptop, by Ben Shneiderman. In some regards, this book is similar to some of the other books that I have discussed on this site, such as The Inmates Are Running The Asylum, which basically state that today’s software is, in a word, unusable. The amount of knowledge that people need to do to get a task done with a computer is still very substantial, and in some regards, this is a barrier between the user and their goals.
I have recently relocated, and with any joy of relocating comes the joy of opening new accounts. The variety and disparity of the user interfaces to accomplish the simple task of getting statements and paying bills is unbelievable. To single one out, my cell phone provider allows me to pay my bill automatically via credit card. To enroll in this service, however, it takes “one or two billing cycles to take effect.” Until this takes effect, you must pay your bill normally. Now, I find this odd on many fronts. First, why could they not add a little dialog box at the end to say, “Would you like me to charge the current amount due of $XX.XX to this card right now?” Thus it would appear that this service would take effect immediately. But because it is not this way, I must entire my information twice. It just does not make any sense.
On the same token, I have recently had to change my credit card information on this site, and I could not change it for a week. Why? Because my bill was pending be charged to my credit card. Yes, you read that correctly. Because they were about to charge my credit card, I was unable to change my credit card information for a week. Again, this does not make any sense.
We really need to take a step back, and look at the software we are writing and make sure that the underlying implementation details are not exposed. The latter example is a wonderful example of this. This is purely an implementation detail. In reality, they could have taken my new information with the caveat that the information would not take effect until the next billing cycle. Or at least, the error message would occur for at most one hour when they were actually processing my account, and not for the period of seven days.
This is the type of thing that Ben discusses in Chapter 2, “Unusable at any Bandwidth.” Like his example of the Therac-25, a device that delivered radiation treatment for cancer patients. While technologically advanced, its user interface was unusable, and caused many errors, including killing some patients. According to the book, no one could imagine that it was the Therac-25 that was causing this, especially since the logs did not indicate the issue. But many of these things were caused by incomplete documentation, poor user feedback, and error messages like “Malfunction 54”. Ben goes on with other examples similar to this.
While the book discusses these matters a bit, the majority of the book is not directly related to this. The author discusses Leonardo Da vinci’s multi-domain expertise, including technology, science, and arts, and how he was capable of using this expertise in all of his projects. For example, his accuracy and attention to detail such as the angle of lighting, natural garments disposition, and facial expressions in his paintings.
He uses this as the introduction to the idea that we should rethink the way that we create software. Instead of creating good-enough software or creating a portion of the software extremely well, really addressing every aspect of a software application, from the technology aspect, the user-interface aspect, the testing aspect, etc. The goal in doing so is to make a great piece of software that can be used by every one, regarding of ability, disability, language, experience, etc., and to create software that you can collaborate with other people. Ben spends a chapter discussing human activities and relationships and how they interact; collaboration and getting credit for things that you have done are takeaways from this chapter if you do not already believe that. One of the great misfortunes is that Leonardo did not share many of his experiments with others, and some believe that this cost the world a number of years of advancement, not to fail to mention the number of pages of his work that have gone missing through the years.
The author then proceeds to provide some ideas to get us thinking in the areas of education, business, health care, and government. I find that some of his ideas are not vastly different than what we have today; for example, he discusses the usability of Access Washington to encourage more usability like this. Other ideas are just simply outrageous, such as the idea of placing a device on each tree, which would be able to tell you what kind of tree this was, the history of the tree, and even maintains a guest book. I can only imagine the great expense of this type of project, not to fail to mention the number of these that would be vandalized in some form or another.
Some of the other ideas though simply require a lot of work in order to accomplish, and it would require a lot of people fully behind these endeavors. One of these examples is a world-wide medical database, in which the idea is that no matter where you are, no matter what language a doctor speaks or what time it is, a doctor could review your medical history, your allergies and current medicine, and from this information, be able to treat you. Furthermore, by placing all this information into a database, the information could be analyzed to find out if other doctors have successfully treated patients with a particular disease. In this case, doctors could communicate to each other to find out how this doctor was successful and what they would recommend doing. And as doctors apparently do not have a grading system, this could double as a reputation, similar to ebay’s feedback system. And this system could also give doctors instance even access to current medical outbreaks, since they currently get updates via periodicals. As you can see, such a system could easily grow out of control.
But at the heart of this is enriching our lives with technology, no matter who we are or where we are. This attention to detail is really important for a user experience. In essence, users should be oblivious to the fact that they are even using computers to accomplish their tasks. In this vein, I close with two quotes from the book:
Technical excellence must be in harmony with user needs.
Great works of art and science are for everyone.
protected in Java...
Here is an interesting question for Java developers. Consider the following classes, where class A is an abstract class that defines a protected method getInfo(), class B is a class that derives from A, and class C uses class A. In Java, is class C allowed to access the method getInfo()?
The answer may surprise some, but the actual answer is that it depends, because I have omitted one important piece of information that is required to answer this question, and that is piece of information, as surprising as it may be, is what package do these classes belong to.
If you refer to section 6.6.1 of the Java Language Specification, you will note that the definition indicates that:
Otherwise, if the member or constructor is declared protected, then access is permitted only when one of the following is true:
- Access to the member or constructor occurs from within the package containing the class in which the protected member or constructor is declared.
- Access is correct as described in 6.6.2.
Of important note here is that classes within the same package as class A from the above example can access the method getInfo().
To drive this point home a bit more, consider the following cases:
Here, we illustrate a Package A, which contains our abstract class A with the protected method getInfo(), class B which derives from class A, and class C and D which use class A and B, respectively. With this in mind, if class C instantiates an A and acquires information from it, it is OK.
- // From Package A, class C
- A a = new A();
- a.getInfo(); // OK
If class D does the same call via an object B, this is not valid:
- // From Package A, class D
- B b = new B();
- b.getInfo(); // OK
Now, if we do the above two calls in a separate package, this will not work. For example, in Package B, we have a class E, and should you attempt either of the above, this will result in a compilation error because now the two classes are not in the same package, and therefore, it is not accessible.
- // From Package B, class E
- A obj = new E();
- obj.getInfo(); // ERROR: We're not in the same package now!
In Package C, I show a new class F that is derived class from class A (from Package A); it does not, however, overload getInfo(). If class H instantiates an F via an A as follows, this will also result in an error since the compiler does not know that you are actually manipulating an F and thus treats this as an error.
- // From Package C, class H
- A obj = new F();
- obj.getInfo(); // ERROR: Maybe he compiler does not know A is really an F? Keep reading
But is that really the reason the compilation fails? Let's see. If we have another class G that accesses the F directly, you will still have a compilation error.
- // From Package C, class G
- F obj = new F();
- obj.getInfo(); // ERROR: F is not involved in getInfo()'s implementation
Interestingly enough, this is covered in the example in section 6.6.7, in which it states that this cannot be permitted since class G is not involved in the implementation of A.getInfo().
So that brings us to Package D, which defines a class I that derives from class A and overrides the getInfo() method. Now in this package, if we try what we tried in the previous example in class J, we will note that it will now work. This is because class J is involved in the implementation of getInfo.
- // From Package D, class J
- J obj = new H();
- obj.getInfo(); // Works!
This is extremely interesting, especially if you come from a C++ background where packages do not exist. It is definitely an eye opener and will change my approach to class design!
Adding Stack Traces to C++ Exceptions...
One of the features that I love
about Exceptions in Java, Python, and other languages is the stack
trace that it provides you, detailing precisely where the exception was
raised. This stack trace is invaluable when placed in log files or when
you do not have a debugger available, since you can now know how your
application got to the exception, which should give you some great
context for starting to approach the issue.
In this weeks InformIT
C++ Guide, Danny mentioned C++
exception-handling tricks for Linux
from IBM. One of the tricks mentioned in the article is how to get a
stack trace where the exception is thrown; the technique used
is well documented in the GNU
C Library Documentation.
The example code in the article demonstrates the concept well, however, displaying the stack trace in the constructor is not ideal, since this information should be made available to the code that catches the exception. At that point, a decision can be made to log a summary of the exception, the full exception, or handle it in some other fashion based on the context.
When I went to run the first application with it, I was expecting a stack trace similar to Java. The actual output, though, was:
- Something went dreadfully wrong.
- at ./TestException [0x804aaaa]
- at /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x4012cb10]
- at ./TestException(__gxx_personality_v0+0x119) [0x8048f01]
Using a GDB, you can use list *address or something similar (such as objdump) on that same executable, and with this, you can get the same information as what a Java or Python stack trace gives you, albeit with more work for you. Furthermore, this approach only works on non-Linux or HURD systems; hopefully the other operating systems you support have some mechanism similar to it.
In general, however, the most
important piece of information in the stack trace is the first entry, viz.
where the exception was thrown, and in many cases, you do not need to
dig any further than it. Because of this, we can reuse the
C/C++
defines for __FILE__
and __LINE__,
and have these passed into our constructor. By using a quick
and dirty macro,
we can then do something like this:
- MY_THROW( "Something went dreadfully wrong." );
Using this mechanism, it can now provide us with the following information:
- Something went dreadfully wrong.
- at TestException.cpp:13
- at /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x4012cb10]
- at ./TestException(__gxx_personality_v0+0x119) [0x8048f01]
And now I have all the stack
information if I need it, but I also have the filename and line number
where the exception is raised. Furthermore, the filename and line
number are available for all standard C or C++ compilers, and thus
provide a portable mechanism to provide at least the most important
information.
As such, I leave you with my
refactoring of this exception class: ExceptionWithStack.h
and ExceptionWithStack.cpp,
and an example program, TestException.cpp.
I have only provided a printStackTrace()
method similar to Java,
however, a true environment would require other methods.
My class derives from std::exception
simply to allow existing code to
be updated to this mechanism where I am planning to use this class. The
code compiles on both g++ and
Visual C++ 2003. This is a great extension; it is just too bad that it
is not part of every exception.
The Proposed New Purpose for the C++ auto Keyword...
One of the little known
keywords of C++ (or even C, at that) is the auto
keyword, and however unknown it is, it is the default behaviour for
variables. The keyword is one of the three variable storage classes,
the other two being extern
and static,
and means that the variable should be allocated on the stack. In my
more than ten years of developing in C and C++, I have seen this
keyword used probably twice, neither of which were, by any means,
required and caused more confusion than if they were not there.
According to The
InformIT C++ Guide, auto
for the People discusses how
Bjarne Stroustrup and Jaakko Järvi have a proposal for C++0x
to reuse this keyword and to add a new one, decltype.
In their proposal, the auto
keyword allows the type of a variable to be automatically discovered.
For example, consider the following segment:
- std::vector<MyClass> v;
- ...
- for ( auto it = v.begin(), end = v.end(); it != end; ++ it ) {
- ...
The attentive reader will
notice that in line 3, the type of the iterator, it,
is not declared, and rather is implied as what we would write today: std::vector<MyClass>::iterator.
Danny’s spin on this
new purpose for auto
appears focused on the number of characters to type (and while the
comments on Java may be true, I do not really feel it adds to the
article at all), and this is really where my concern is for this
feature. I think that code that exploits this behaviour will have
maintainability issues. For example, consider the following segment:
- auto v = myFunction();
- for ( auto it = v.begin(), end = v.end(); it != end; ++ it ) {
- ...
Looking at this code, I assume
that myFunction
returns some type of container that has an iterator, but this is simply
an assumption based on how the variable v
is used. During the maintenance of code, this return value could
change, and this is where I am sure that the errors generated by the
compiler can get a little odd, especially if myFunction()
is actually in a library, and the developer porting it to the latest
version is not the developer who has changed this behaviour.
Today if this problem occurred,
the error would occur right when you call myFunction(),
since there is a type mismatch, but with this new behaviour, the error
would probably occur somewhere in the for
loop where v
is actually used.
Perhaps this example is a bit
too simple since we are dealing with the standard library.
But consider
the situation where the type is not a vector. How do you know what
methods to call on this class? Is it even a class? As reminded by Code
Reading, we definitely read code
more times than we write it; is this typing convenience really worth
this ambiguity? I do not think so. There is only one place
that I can think of using it, and I will get to that in a moment.
The other keyword, decltype,
acquires the type of the variable in question, similar to the
non-standard typeof
function provided by some compilers. For example, decltype(
it ) would acquire the std::vector<MyClass>::iterator,
and unfortunately this is as detailed as Danny really gets on this
topic.
For developers who have not
delved into the world of generic programming, I do not see these
features as being useful at all. In the context of generic
programming though, both of these keywords will make generic
programming easier and far more useful. How many times have you had to
add more parameters to your generic algorithm because it used another
algorithm whose return value differs? This is a perfect application for
the auto
keyword. The declaration type also similar benefits, allowing the
return value of a generic algorithm to be dependent on some external
method, for example.
Of course, this is still a proposal and is not guaranteed to be in the C++0x standard. Nevertheless, I see as a really practical feature for generic programming. But please stay away from using it to save typing!