I'd just like to say thanks for D

[H. S. Teoh]

On Sun, Mar 10, 2013 at 01:30:26PM -0700, H. S. Teoh wrote:
[...]
> After programming in D, I just find C/C++ (which I have to use at
> work) really painful. I keep finding myself wishing that some piece of
> code was written in D, and thinking that if that buggy piece of code
> were only written in D, things would be a lot different. :)
[...]

<anecdote>

Case in point: just today, I wanted to add some simple caching to a
compute-intensive C++ program in order to improve performance on large
data sets. I needed to map a particular combination of indices (in this
case, 3 ints) to a cached value, so I thought, this is the perfect use
case for unordered_map, so I'll just make a struct of the 3 ints to
serve as key. Easy, right?  I immediately ran into a series of obstacles:

- First, unordered_map instantly gave me a compile error: "you didn't
  specify -std=c++11", said the compiler, "which is still 'experimental'
  so we didn't enable that for you by default, and so this header called
  unordered_map that you #included can't be compiled". Right, now I
  remember. STL before C++11 was so ridiculous as to NOT have a standard
  hash type. And now it's 2013 and g++ is still defaulting to the *old*
  C++?! Sigh. OK, no problem, they finally got their act together, so
  stick -std=c++11 into the build script. No problem, right?

- Ahem. Next, the compiler complains, "you wrote a template name with no
  parameters; that's illegal!" Perfectly legal complaint, but the line
  concerned read:

	std::unordered_map::iterator it = fcache.find(key);

  Fixing the compiler error required me to change this already-verbose
  line to:

	std::unordered_map<cache_key_type, vertex_set>::iterator it = fcache.find(key);

  Argh! What is this, Java?! How I miss D's type inference... The only
  way to make this *not* painful was to use a typedef. I feel like
  applying layers of bandages just to fix an underlying, deeply wrong
  language maldesign.

- Next problem: due to the lack of a GC, vertex_set was originally
  implemented to automatically deallocate its memory upon destruction,
  so the only way I could return the cached value was to copy it, which
  offset some of the benefit of caching in the first place. Since this
  was very old code which I'm slating for replacement with a D version
  anyway (yay!), I wasn't going to bother with implementing reference
  counting, etc.. So I said, let's leave it for now, even if we're
  wasting cycles/memory to copy the cached value, it should still be
  faster than recomputing it from scratch every time.

- And then another roadblock: the compiler says, "hey, buddy, std::hash
  hasn't been specialized for cache_key_type yet, so it doesn't know how
  to compute the hash value of the key, and so I can't instantiate that
  template for you!".

At this point, I threw up my hands and said, forget it, I'm done with
this nonsense. I had intended this to be a quick fix, to fix a
performance issue with the old program until the new D version is ready
for general use. But now I have to write my own hash function just to
use a struct of ints as key?! Seriously, in D, this change would have
taken just a few lines of code. For all their bugs and flaws, even D's
current broken built-in AA's could handle structs as keys without
requiring additional user effort. In C++, I have to do the above baroque
dance, only to get an inferior solution (copying of vertex_set because
of no GC). What a total waste of time! I'd rather be spending all that
effort to work on the D replacement instead!!

Sigh. D may have its warts, but it's already so awesome that it has
totally spoiled me for other languages.

</anecdote>


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind
should be open at both ends, like the food-pipe, with the capacity for
excretion as well as absorption. -- Northrop Frye