D dropped in favour of C# for PSP emulator

[Alex Rønne Petersen]

On 11-05-2012 20:28, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
>> On 11-05-2012 20:05, Mehrdad wrote:
>>> 1. "templates": they seem to take in just about anything, and return
>>> just about anything. They can be pretty confusing, especially when
>>> youhave to worry about overloading vs. specialization vs.
>>> constraints, or types vs. aliases...
>>
>> Right, D's template system is definitely inspired by C++, no argument
>> there. But in the vast majority of code, you really don't have to use
>> templates for everything.
>
> Not sure I agree.
>
> Templates are almost *impossible* to ignore when working with ranges.
>
>>> 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very
>>> confusing if you don't happen to suddenly "get" them.
>> I don't know about that. They seemed simple enough to me.
>
> Me too, as a matter of fact.
>
> But they definitely aren't intuitive (just judge by the number of
> questions about them that pop up on StackOverflow or elsewhere...)

True, but I think what we lack is clear and concise documentation on them.

>
>>> 3. Ranges aren't confusing, but USING them certainly is.>
>> On the contrary, I actually think we're lacking proper documentation
>> on what ranges are.
>
> Yeah probably.
>
>>> Consider: In C#, you say Array.BinarySearch(arr) to search an array.
>>> It's VERY straightforward.
>>> In D, it's VERY CONFUSING
>> Library issue.
>
> Yeah, you got me there...
> But in practice it doesn't make a difference what the cause is, so much
> as what the effect is...

True. I'm just speaking from a purely language perspective. But D is a 
batteries-included language, so if the standard library has problems, 
you could arguably say D has problems as a whole...

>
>
>>> 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
>> I've always found it very intuitive actually... and it saves me from
>> having to write extra code to do the actual lookup (speed isn't even
>> the point here, I just want concise code).
>
> Yes, I agree, but consider that D users should NOT have to work with
> pointers to do something so basic, like testing to see if something is
> in an associative array!

I agree that the fact that it returns a *pointer* is probably not ideal. 
Maybe if D had proper pattern matching, it could have returned some kind 
of Option!T type or whatever...

>
> The mere fact that it uses a pointer makes it unintuitive to a large
> number of people coming from C#/Java/Python/etc.
>
>
>> But again, most code really won't be doing all that much low-level
>> metaprogramming.
>
> That's the hope, but I keep on finding myself putting __traits(compiles,
> ...) on template conditions and such...

I've actually found that std.traits and if () constraints on 
declarations tend to work for most of my cases. But YMMV and all that.

-- 
- Alex