Java Namespaces Suck Big Time

I had a name clash in the framework I’m working on. I defined a class Rectangle, and then needed to use it together with java.awt.Rectangle. Java, instead of helping me resolve this clash, made my life difficult. In frustration I wrote this short text.

Davos

I’ll be in Davos from today until February 3^rd. I’m not sure if I’ll be checking my e-mail. Call me at +381-63-346-121 if you need to reach me.

Visual Studio.NET and STLPort

If you try to compile a Managed C++ program while using STLPort, you’ll get a bunch of errors.

The problem is that STLPort uses a parameter named __value in a number of interfaces, but __value is a keyword in Managed C++.

The fix is to do a search & replace in the STLPort directory and replace of all instances of the string __value with __somevalue.

STLPort is the guilty party here, not Visual C++. Names starting with an underscore are reserved for compiler writers.

Java Speed, Again

I wrote some time ago that the Java object model is simply not built for speed. Now I stumbled upon some benchmarks that seem to demonstrate how serious the problem is.

No std::round?

This is weird. I included <cmath>, and then attempted to use std::round in my program. The compiler flagged that as an error saying that std::round does not exist.

I fired up MSDN and, lo and behold, there is no round in <math.h> or its namespaced counterpart <cmath>.

That’s weird. I would expect that a function like that would be useful to a lot of people. Both the Java Math class and the CLR Math class have a round function.

Visual C++.NET

I just tried compiling the following function:

template <typename T, std::size_t count>
size_t getLength (T array [count]) {
    return count;
}

And when I passed it an array of 10 integers the compiler gave me the following error message:

error C2784: ’size_t getLength(T [count])’ : could not deduce template argument for ‘ []‘ from ‘int [10]‘

Pffft. Microsoft.

CASE Tools Debunking

For years I’ve maintained that CASE tools suck. Those who use them successfully basically use them as overpriced diagramming tools. Those who try to use them for “round-trip engineering” and “reverse engineering” are simply wasting time.

Now finally someone has articulated views about CASE tools that are an exact replica of mine. Read this great article by Allen Holub.

Misc. Recommendations

Here’s some programming stuff worth checking out:

• If you liked books like Writing Solid Code, Code Complete, Debugging the Development Process or Rapid Development, do read Writing Secure Code.
• Here’s a good text on mixing managed and plain C++ code. It touches some of the issues that I had to deal with while doing it.
• Both CVS and Source Safe have poor support for two-step version tracking. I want to have a local repository on my machine, and a central repository on the server. When I work on a piece of code I want to have the ability to check code into the local repository at certain times during development, and then, when I’m satisfied with the code I want to check it into a central repository. AccuRev does this. It also does away with many other warts of other version control systems due to a superior architecture.

Nigel Perry E-mail

I e-mailed the authors of the Mondrian text a link to my Quick Sort weblog entry. I try to make it a principle to e-mail people if I comment on their work, good or bad, provided that I can fish out their e-mail address.

Nigel was kind enough to reply. He says that sorting is a standard example that Microsoft uses to demo the languages.

There is also an interesting reply to my claim that type inference doesn’t mix well with overloading:

“BTW type inference and overloading do go together – internally the Hope+C type-checker is inference based and supports overloading and parametric polymorphism.”

Thanks Nigel.

Functional Quick Sort

I spent some time today checking out Mondrian. It’s a functional language based on Haskell that works under .NET and integrates into Visual Studio.NET. For a quick overview check out this DDJ text found via Lambda the Ultimate.

One thing that strikes me as wrong about most functional language blurbs is that they all seem to use Quick Sort to demonstrate the superiority of functional languages.

It goes something like this: first they give you a Quick Sort algorithm written in C. It’s long and it’s ugly. Then comes a functional version which is short and clean. Ta-da.

There are two problems with this. First, the C version is Hoare’s version of Quick Sort that does sorting in-place. This makes it much faster and less memory intensive than the functional version. Second, if one doesn’t care about speed and memory than a similarly short function can be written just as easily in a non-functional language like C++.

You don’t believe me? Here’s the proof. To level the playing field, I first created head, tail and filter C++ template functions that operate on list<T>. Then I overloaded the operator + to concatenate lists with other lists or list elements. Those functions are part of the standard Mondrian prelude, and the operators are built into the language. In addition to that I defined template versions of the comparison operator that produces a functor objects bound to an argument.

Armed with those, here is the Quick Sort algorithm written in C++:

template <typename T>
list<T> qsort (list<T> input) {
  if (input.empty ()) return list<T> ();
  else {
    T pivot = head (input);
    list<T> before = filter (tail (input), arg < pivot);
    list<T> after = filter (tail (input), arg >= pivot);
    return qsort (before) + pivot + qsort (after);
  }
}

For reference, here is the Quick Sort from the DDJ Mondrian text:

qsort = compare -> l ->
  switch(l) {
    case []: [];
    case (pivot::t):
      let
        before = filter (x -> compare x pivot) t;
        after = filter (x -> not (compare x pivot)) t;
      in
        (qsort compare before)
        ++ (pivot :: (qsort compare after));
  };

Not a big difference, is is? The Mondrian version is still a bit cleaner, IMO, because of type inference, but not enough to make this a good example of functional programming. (Not to mention that type inference doesn’t mix well with function overloading.)

Also, my example uses list containers as a list data type, while Mondrian, in effect, uses iterators. But this is just me being lazy to create a functional list data type and using containers instead.

All in all, Quick Sort is a bad example of the superiority of functional languages. Something with lambda functions and function composition that cannot be done easily in traditional imperative languages would be much better.