On Fri, May 11, 2012 at 08:05:57PM +0200, Mehrdad wrote: > On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote: > >Complicated language structure? Long compilation times? > > > >wat. > > I'd have to agree... > > Several things in D are really hard to understand if you don't already > have a C++ background: > > 1. "templates": they seem to take in just about anything, and return > just about anything. They can be pretty confusing, especially when you > have to worry about overloading vs. specialization vs. constraints, > or types vs. aliases...
Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something. Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing. > 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very > confusing if you don't happen to suddenly "get" them. Again, the problem is lack of proper introductory documentation for them. Actually, I find that to be a consistent problem with much of the current D docs. They appear to be written for people who already know what the thing is, and as such is very unhelpful to a newbie. > 3. Ranges aren't confusing, but USING them certainly is. > > Don't believe me? > > Consider: In C#, you say Array.BinarySearch(arr) to search an > array. > It's VERY straightforward. > In D, it's VERY CONFUSING -- there *is* no way to do this > directly! > Which led me to ask this question: > http://stackoverflow.com/questions/4622377 > and the solution indeed was NOT something I would've found by > myself > without spending hours on it (which I already had partially > done). Again, this is due to poor (or lack of) introductory docs. Really, things like Ali's excellent D book need to be put in a prominent place on dlang.org, rather than relegated to a secondary source. Most of the stuff on dlang.org is written as reference material rather than tutorial material. It does serve its purpose -- it's there for reference when you need to look something up. But it's very unhelpful for someone trying to get started with the language. > 4. is(typeof(foo) U) is very confusing; it's completely unintuitive > > 5. For that matter, is() is completely unintuitive is() syntax is a horrible mess. Walter has said that he'd like to redesign it eventually... but it's not going to happen in the near future because it's a breaking change. > 6. The 'in' operator returns a pointer (instead of a boolean). Which > is fine, except that it's not what you'd expect in any languages > other than C/C++. i.e. Non-intuitive Actually, that is a WAT even for somebody coming from C/C++. > 7. __traits() are confusing [...] But they are advanced stuff that you generally don't need until you're familiar with the language. I don't see this as a problem. T -- Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
