The author of a D based PSP emulator just rewrote
the emulator in C#, after being disappointed with D.

https://github.com/soywiz/cspspemu

The reasons are listed here,

https://github.com/soywiz/cspspemu#created-after-4-tries

--
Paulo

On 11-05-2012 19:39, Paulo Pinto wrote:
>
> The author of a D based PSP emulator just rewrote
> the emulator in C#, after being disappointed with D.
>
> https://github.com/soywiz/cspspemu
>
> The reasons are listed here,
>
> https://github.com/soywiz/cspspemu#created-after-4-tries
>
> --
> Paulo

Complicated language structure? Long compilation times?

wat.

The language may be complicated if all you've ever done is C# or Java, but then you've barely been exposed to interesting language design at all IMHO. I can agree on it being harder to refactor things in D than in other languages, but this completely depends on how much CTFE/CT reflection magic you're using.

Now, this being said, .NET is interesting for an emulator exactly because he can just throw CIL at the runtime and it will emit native code for him at runtime. This makes portability *extremely* easy, because the CIL he emits will run anywhere Mono and MS.NET can run. Doing a similar thing with LLVM is certainly possible, but much more tedious.

-- 
- Alex

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...

2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them.

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).

4. is(typeof(foo) U) is very confusing; it's completely unintuitive

5. For that matter, is() is completely unintuitive

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

7. __traits() are confusing

8. there's more but I just can't think of them right now

On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
>    and the solution indeed was NOT something I would've found by myself without spending hours on it.


Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me.
(In retrospect, I probably should've just coded binary search myself...)
It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...

On 11-05-2012 20:05, 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...

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.

>
> 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.

>
> 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.

>
> 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).

Library issue.

>
> 4. is(typeof(foo) U) is very confusing; it's completely unintuitive
>
> 5. For that matter, is() is completely unintuitive

Definitely. is() is an abomination.

>
> 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).

>
> 7. __traits() are confusing

I have the same stance WRT __traits as I do for is(). We need a better solution to metaprogramming.

But again, most code really won't be doing all that much low-level metaprogramming.

>
> 8. there's more but I just can't think of them right now

-- 
- Alex

On 5/11/12 1:10 PM, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
>> and the solution indeed was NOT something I would've found by myself
>> without spending hours on it.
>
>
> Just a note: I believe I *had* seen SortedRange in the docs, but I'd
> never realized there's something called assumeSorted() that I was
> supposed to call... so I was searching up and down for how to search an
> *arbitrary* container, not how to search something which was already
> pre-sorted for me.
> (In retrospect, I probably should've just coded binary search myself...)
> It's very counterintuitive to have to make a new object (or struct) just
> to do binary search on an array...

At the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search works with non-array ranges, but C#'s works only with arrays (which it assumes sorted only by convention).

I think we copiously made the right call there.


Andrei

On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 11-05-2012 19:39, Paulo Pinto wrote:
>>
>> The author of a D based PSP emulator just rewrote
>> the emulator in C#, after being disappointed with D.
>>
>> https://github.com/soywiz/cspspemu
>>
>> The reasons are listed here,
>>
>> https://github.com/soywiz/cspspemu#created-after-4-tries
>>
>> --
>> Paulo
>
> Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window.  It has improved greatly, but there are still some improvements that can be made.

For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests.  It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table.  There's an outstanding issue which is similar still in bugzilla:

http://d.puremagic.com/issues/show_bug.cgi?id=4900

-Steve

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?"

On Friday, May 11, 2012 11:22:13 H. S. Teoh wrote:
> > 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++.

Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator.

- Jonathan M Davis

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...)

>> 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...


>> 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!

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...