On Fri, May 11, 2012 at 09:01:25PM +0200, Chris Cain wrote: [...] > I really have to disagree on this. I programmed in C++ for awhile > and templates were always a huge stumbling block for me. The syntax > didn't sync up for me and they were extremely difficult to implement > well, which made any generic programming I attempted feel > half-hearted (IMO).
Yeah, I remember when I first read about template metaprogramming and expression templates and stuff, and I was all riled up about finally being able to write matrix expressions in an intuitive way and still have peak performance... until I actually sat down to code the thing. Let's just say I didn't get very far before I got completely lost in deep jungle that is C++ template syntax. > When I started looking at D's templates, I was _afraid_ that it > would be as much of a pain in the ass. After putting it off and > shying away from it, I decided to dive in and discovered that they > were significantly easier to work with ... and more importantly, it > was nearly straightforward to implement them _well_. It's absolutely > no problem specifying that data type with certain properties should > use this function and everything else should use this other > function. In C++, you have to learn complicated, arbitrary idioms > such as SFINAE to get any serious work done at all ... and it looks > like all of it was written in another language when you're done, > making maintenance a nightmare. Yeah, one of the biggest problems with C++ template syntax is that it looks like an alien language. I remember going, "wait, you have to type *that* to achieve what can written as a simple loop in normal C++ code?!" I couldn't tell you how delighted I was when I saw D's much cleaner and clearer template syntax. I mean, it looks just like normal, non-template code! Gee, what a concept! > It's not surprising that entire C++ books are dedicated to teaching > the absurd complexities of C++ templates. If anything, my experience > with C++ templates hindered me. Or the absurdity of C++ itself. What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions. [...] > There's definitely not enough info on how to get stuff done with > ranges. I knew about assumeSorted and the fact that std.algorithm.sort > returns a sorted range, but only because I carefully combed through > the libraries looking for stuff like that. Again, helpful tutorials like Ali's book really need to be on the forefront of D. Newbies *need* to read that stuff before they get dunked into the deep end of the pool that is the current dlang.org docs. > That said, the D way is actually very well designed once you > discover it. Like Andrei said, the code clarifies its intentions. > > Hilariously, this style also makes the code look more magical. You > want to say something is unique and, thus, can be legitimately made > immutable? assumeUnique. Oh, you want to have a memoized version of > funct? memoize!funct. I leave my friends wondering how D knew how to > do all this stuff just by being "told" to. Magic API, that's how. +1. Sufficiently advanced programming language syntax is indistinguishible from magic. ;-) T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
