Re: D dropped in favour of C# for PSP emulator

[Andre Artus]

On Saturday, 12 May 2012 at 03:42:10 UTC, Ary Manzana wrote:

On 5/12/12 3:40 AM, Mehrdad wrote:

On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:

That's definitely an example of something that depends on your
background. std.algorithm.any does _exactly_ what it would do 
in a

functional language.


Well, I know some FP (Scheme/newLISP) but they don't have an 
"any"
function. I don't know about F#, but my guess would be that it 
would do

the same thing as C# would (for obvious reasons).

Are you thinking of a language in particular that has D's 
behavior? Or

is this just a guess?


Ruby has any?:

http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F

And it's the best of the two worlds: given a block (a lambda) 
it works like D. Give no lambda and it just returns true if the 
enumerable has any elements.


Ruby wins again. :-P


This is in fact the exact behaviour of .NET's Any (on 
IEnumerable). This is a library thing, not a language thing.

Re: D dropped in favour of C# for PSP emulator

[Andre Artus]

On Friday, 11 May 2012 at 23:51:47 UTC, Mehrdad wrote:

On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:
I know that haskell has such a function, and there were a 
number of complaints previously that we _didn't_ have an any 
function which does exactly what std.algorithm.any now does. 
It's a very functional approach to use predicates like that 
and I get the impression that it's common in other functional 
languages based on other's comments. The only one off the top 
of my head that I _know_ has such a function though is haskell.



Again, I know enough FP to know what predicates are, and of
course, this is common in functional languages.

Even Scheme has a 'there-exists?' function just for this 
purpose.


I wasn't saying having "such a function" is weird -- I was just
asking if you know of any languages in which the NAME is 
"any()",

since I would've imagined it to be something more intuitive like
"exists()" or "contains" or "has" or whatever.
(I was giving C# as an example, because C# uses "Any()" to mean,
"are there any elements in this list?", NOT with the meaning D
uses.)


In .NET 3.5, and later, 'Any()' has an overload that takes a 
predicate so it behaves identical to 'any' in Haskell and D.


public static bool Any(
this IEnumerable source,
Func predicate
)

The Exists method is an older construct with a more limited 
application (List vs IEnumerable)

Re: D dropped in favour of C# for PSP emulator

[Jacob Carlborg]

On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:

I know that haskell has such a function, and there were a 
number of complaints
previously that we _didn't_ have an any function which does 
exactly what
std.algorithm.any now does. It's a very functional approach to 
use predicates
like that and I get the impression that it's common in other 
functional
languages based on other's comments. The only one off the top 
of my head that I

_know_ has such a function though is haskell.


Ruby has a function like that as well. It works like the Haskell 
version if you pass a predicate. If you don't pass an argument it 
works like the one in C#.


--
/Jacob Carlborg

Re: D dropped in favour of C# for PSP emulator

[bearophile]

soywiz:


D didn't had a good IDE allowing refactoring by that moment


That's mostly a tools/ecosystem problem, but perhaps the language 
design could help a little to perform the refactoring. How can a 
language help refactoring?



Compilation times were huge. I was using lot of compile-time 
code generation and at least at that time, that code was 
interpreted or not enought fast for me.


This is a known problem, it can be solved, people are working on 
it, and I think eventually it will be partially solved.



Also I needed a needed to chaneg the emulator to perform 
dynamic recompilation instead of just interpreting. With C# I 
could do portable dynarec very easily. In the case of D I would 
have to creaet a emitter per supported platform (mostly x86, 
x64 and ARM).


I think this is mostly a library problem.

Bye,
bearophile

Re: D dropped in favour of C# for PSP emulator

[soywiz]

I just replied here with my motivations:
https://github.com/soywiz/pspemu/issues/1

"D is just fine to create an emulator. The problem was that I was 
doing emergent design, so I was refactoring a lot. And design 
flaws caused the refactorings to be massive. D didn't had a good 
IDE allowing refactoring by that moment (not sure about that 
now). That was the main reason for me to change the technology. 
Also there was minor flaws:
Compilation times were huge. I was using lot of compile-time code 
generation and at least at that time, that code was interpreted 
or not enought fast for me. Also I didn't get incremental 
compilation working, it failed everytime probably because that 
compilation-time stuff causing the compilation to take stuff like 
1 entire minute. And that was unacceptable too for me. I needed 
to run it lots of times to doing research. Also I needed a needed 
to chaneg the emulator to perform dynamic recompilation instead 
of just interpreting. With C# I could do portable dynarec very 
easily. In the case of D I would have to creaet a emitter per 
supported platform (mostly x86, x64 and ARM).


And my decission to use C# was not because I didn't like D. In 
fact, I liked D a lot, that much that I started an emulator using 
it."

Re: D dropped in favour of C# for PSP emulator

[Alex Rønne Petersen]

On 30-05-2012 17:30, Bruno Medeiros wrote:

On 20/05/2012 15:19, Timon Gehr wrote:

No, you misunderstand.

- Time spent starting up the IDE is lost time that could be spent doing
something productive instead. Hardware is fast. There is simply no
excuse for poor start up times/poor responsiveness.


I am not misunderstanding. No one is saying there is no value in saving
that start up time. But you listed that as *more* important than many
other features that actually help a lot (and thus save time a lot) when
you code, or debug programs.

Oh and there are excuses for poor start up times. I am not gonna explain
them because it would get technical and long.





I'm just going to add that Visual Studio 11 can start up in less than a 
second. Visual Studio 2010 could take well towards 10 seconds (and 
sometimes more if you have many extensions). They solved the problem 
simply by lazy-loading almost everything they could. It turns out that 
the majority of stuff that most IDEs load on startup isn't going to be 
used during a session, so it's just wasted time.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: D dropped in favour of C# for PSP emulator

[Bruno Medeiros]

On 20/05/2012 15:19, Timon Gehr wrote:

No, you misunderstand.

- Time spent starting up the IDE is lost time that could be spent doing
something productive instead. Hardware is fast. There is simply no
excuse for poor start up times/poor responsiveness.


I am not misunderstanding. No one is saying there is no value in saving 
that start up time. But you listed that as *more* important than many 
other features that actually help a lot (and thus save time a lot) when 
you code, or debug programs.


Oh and there are excuses for poor start up times. I am not gonna explain 
them because it would get technical and long.




--
Bruno Medeiros - Software Engineer

Re: D dropped in favour of C# for PSP emulator

[Bruno Medeiros]

On 19/05/2012 02:33, Jesse Phillips wrote:

On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:

So just starting up the IDE is more important than actually writing
code or fixing bugs?...


I'd like to see you do those things without starting your IDE.


Oh yeah, I'd like to see you do those things using just one hand. Or 
with your eyes closed!...


...do you understand why I made that satire above?
Yes, my productivity would take a huge hit if I didn't have an IDE. 
Coding without an IDE for me is like coding with just one hand, or 
something like that. But why would I code without an IDE? I see no point 
in adding such restrictions to my development activity, I am not the 
kind of software developer that sees value in artificial limitations to 
show off your hacksmanship or mad coding skillz (hey, I'm editing inodes 
by hand...   ...WITH MAGNETS!!!)
If you are such a developer, if you like tricks and artificial 
challenges, then that's fine, let's just call it a difference in goals. 
But my main goal and interest in software development is to produce high 
quality software in the most efficient way.


--
Bruno Medeiros - Software Engineer

Re: D dropped in favour of C# for PSP emulator

[Jerry]

Andrei Alexandrescu  writes:

> On 5/18/12 4:36 PM, Mehrdad wrote:
>> On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:
>>> I guess it is now :o).
>>>
>>> Andrei
>>
>> lol
>>
>>
>> One more thing that's also annoying about this is that it's not in
>> std.algorithms, but std.range...
>>
>> Asn't binary search an algorithm?
>
> It is, and the decision (after a good amount of deliberation) is
> arbitrary. Some rationale was that SortedRange has enough structure to make it
> an "interesting" range, so I put it in std.range. The argument could go either
> way. Now it's gone one way. Let's move on.

This is posted long after the conversation, but a partial solution to
the confusion could be handled in the docs.  Add a section in
std.algorithms referring to std.range, so that newcomers can find what
they're looking for with less confusion.

Jerry

Re: D dropped in favour of C# for PSP emulator

[Regan Heath]

On Sun, 20 May 2012 20:43:15 +0100, Timon Gehr  wrote:


On 05/20/2012 08:47 PM, Manu wrote:

It's also worth noting that this guy dropped D for C#. That's a pretty
clear indication the environment was important to him.


It is important to me as well. I would drop C#/VisualStudio for D/GNU  
Linux any day.


It really all depends on where each person is coming from.  I have used  
windows/msvc all my career and I know how to do what I want to do without  
having to think about it, or go hunting for it, etc.  If you're that  
comfortable on another OS using other tools, then I can see why you  
wouldn't want to change.  The only motivator I can see for change is if  
the existing system is broken, or a new system brings /significant/  
improvement.


I've worked with guys who had a good familiarity with GNU  
tools/environments and so requested the flexibility to switch their  
desktop/development environments from Windows/MSVC to linux/GNU or  
similar.  Permission was granted and off they went.  I can't honestly say  
they became more productive, but they were happier.  The cost was the  
downtime as they switched, and all those problems which cropped up after  
the fact - like how to get source in/out of existing systems to their new  
desktops etc.


Ultimately you'll be most productive using something which will:
a. do the job
b. in a way you're most familiar/used to

End of story.

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/20/2012 08:47 PM, Manu wrote:

It's also worth noting that this guy dropped D for C#. That's a pretty
clear indication the environment was important to him.


It is important to me as well. I would drop C#/VisualStudio for D/GNU 
Linux any day.

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 20 May 2012 17:19, Timon Gehr  wrote:

> On 05/18/2012 06:59 PM, Bruno Medeiros wrote:
>
>> On 12/05/2012 01:00, Timon Gehr wrote:
>>
>>> some essential properties:
>>> - starts up instantaneously
>>>
>> 
>>
>>> some 'nice to have' properties:
>>> - code analysis based code completion
>>>
>>  > - integrated debugger
>>
>> So just starting up the IDE is more important than actually writing code
>> or fixing bugs?...
>>
>>
> No, you misunderstand.
>
> - Time spent starting up the IDE is lost time that could be spent doing
> something productive instead. Hardware is fast. There is simply no excuse
> for poor start up times/poor responsiveness.
>
> - The current IDEs have poor support for editing and navigating text.
> Furthermore, 'pattern recognition based code completion' was on my list as
> well.
>
> - I am more efficient at bug-chasing by sending relevant data to stdout
> instead of setting breakpoints and fighting the GUI until I understand what
> is going on. (I think that one of the most useful features of eclipse is
> the built-in console.) Furthermore, in my experience, almost all bugs are
> trivial regressions and/or caught immediately by reasonably good
> assertions. YMMV.
>
> - I concur that when faced with a new code base, or just poorly written
> code not written by oneself, some of the IDE features are very useful in
> order to get up to speed. But why does this functionality have to come in a
> GUI app, fully integrated with other components that may have drawbacks
> even if they are not explicitly used?
>
>
>  Seriously, I'm never going to understand you "editor" people..
>>
>>
> I do not see how this is relevant. Is your misunderstanding of the post
> deliberate?
>

It's also worth noting that this guy dropped D for C#. That's a pretty
clear indication the environment was important to him.

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/18/2012 06:59 PM, Bruno Medeiros wrote:

On 12/05/2012 01:00, Timon Gehr wrote:

some essential properties:
- starts up instantaneously



some 'nice to have' properties:
- code analysis based code completion

 > - integrated debugger

So just starting up the IDE is more important than actually writing code
or fixing bugs?...



No, you misunderstand.

- Time spent starting up the IDE is lost time that could be spent doing 
something productive instead. Hardware is fast. There is simply no 
excuse for poor start up times/poor responsiveness.


- The current IDEs have poor support for editing and navigating text. 
Furthermore, 'pattern recognition based code completion' was on my list 
as well.


- I am more efficient at bug-chasing by sending relevant data to stdout 
instead of setting breakpoints and fighting the GUI until I understand 
what is going on. (I think that one of the most useful features of 
eclipse is the built-in console.) Furthermore, in my experience, almost 
all bugs are trivial regressions and/or caught immediately by reasonably 
good assertions. YMMV.


- I concur that when faced with a new code base, or just poorly written 
code not written by oneself, some of the IDE features are very useful in 
order to get up to speed. But why does this functionality have to come 
in a GUI app, fully integrated with other components that may have 
drawbacks even if they are not explicitly used?



Seriously, I'm never going to understand you "editor" people..



I do not see how this is relevant. Is your misunderstanding of the post 
deliberate?

Re: D dropped in favour of C# for PSP emulator

[Era Scarecrow]

On Saturday, 19 May 2012 at 20:42:13 UTC, Manu wrote:
On 18 May 2012 19:59, Bruno Medeiros 
 wrote:



On 12/05/2012 01:00, Timon Gehr wrote:


some essential properties:
- starts up instantaneously




 some 'nice to have' properties:

- code analysis based code completion


> - integrated debugger

So just starting up the IDE is more important than actually 
writing code or fixing bugs?...


Seriously, I'm never going to understand you "editor" people..



No, writing code and fixing bugs is more important than sitting 
around and operating your computer. I can hit F7 or F5 way 
faster than I can type a full line of some command on the 
shell. I can tap tab and instantly complete typing the crap I 
waste time typing repeatedly (typing almost all identifiers 
become just 1 or 2 key strokes). I can hit ctrl-space and have 
the documentation for a function appear INSTANTLY much faster 
than I can swap out and refer to some reference manual. I can 
step and debug and inspect the value of variables, deep in 
structures containing a heap of indirection way faster than I 
can operate GDB. I will seriously never understand anyone who 
will try and honestly say typing shit on a command line, 
feeding commands to GDB manually, and looking up references in 
some external manual can possibly be faster... under ANY 
circumstances... ever.


 Perhaps to be a hard-core hacker? I've done a GUI-less 
programming before, using GDB, typing the commands, all that 
jazz. But it's about the same as jogging to work every day that's 
say 15 Miles away; you 'COULD' do it, but if there's a better way 
like a bike or a car or segway, then why continue to do it the 
longer more busy route?


 With a good editor and having data 10-50x faster and more 
available, you can get more work done, and thereby fix more bugs 
and program more. You'd have to actually use a decent IDE (like 
eclipse for java) to realize how useful it can be. Course if you 
have an awesome memory then perhaps it isn't quite as important; 
but honestly I have a horrible memory.

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 18 May 2012 19:59, Bruno Medeiros  wrote:

> On 12/05/2012 01:00, Timon Gehr wrote:
>
>> some essential properties:
>> - starts up instantaneously
>>
> 
>
>  some 'nice to have' properties:
>> - code analysis based code completion
>>
> > - integrated debugger
>
> So just starting up the IDE is more important than actually writing code
> or fixing bugs?...
>
> Seriously, I'm never going to understand you "editor" people..


No, writing code and fixing bugs is more important than sitting around and
operating your computer.
I can hit F7 or F5 way faster than I can type a full line of some command
on the shell. I can tap tab and instantly complete typing the crap I waste
time typing repeatedly (typing almost all identifiers become just 1 or 2
key strokes). I can hit ctrl-space and have the documentation for a
function appear INSTANTLY much faster than I can swap out and refer to some
reference manual. I can step and debug and inspect the value of variables,
deep in structures containing a heap of indirection way faster than I can
operate GDB.
I will seriously never understand anyone who will try and honestly say
typing shit on a command line, feeding commands to GDB manually, and
looking up references in some external manual can possibly be faster...
under ANY circumstances... ever.

Re: D dropped in favour of C# for PSP emulator

[Era Scarecrow]

On Saturday, 19 May 2012 at 01:33:55 UTC, Jesse Phillips wrote:

On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
So just starting up the IDE is more important than actually 
writing code or fixing bugs?...


I'd like to see you do those things without starting your IDE.


Seriously, I'm never going to understand you "editor" people..


My oversimplification of it is, IDEs like the fundamental 
component of writing software. A text editor. Sure it has this 
text insertion thing, but it just looks like they forgot about 
it.


 I'll have to agree. You can skip the editor entirely and use 
nothing but cat, or Joe but I personally have not; I make too 
many mistakes on a single pass usually.


 Having a good base working environment that is both easy to use, 
and combines everything you need in one spot is actually quite 
crucial; and this does include an editor which may (hopefully) be 
part of an IDE. True I can probably do all the C/C++/D 
programming I want in notepad++, but doing all the extra work 
manually or only being able to rely on the language reference 
without any intellisense or something does leave a bit of a 
problem.


 The biggest deterrent to using D/D2 up to now was lacking a good 
debugger. With VisualD around I have just enough in the VS IDE to 
write and use my own code; True it has a lot of work to be done 
on it, but It's usable.  An improved IDE and debugger later will 
greatly speed up not only bug fixing but programming in general 
using D.

Re: D dropped in favour of C# for PSP emulator

[Andrew Wiley]

On Fri, May 18, 2012 at 6:33 PM, Jesse Phillips
wrote:

> On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
>
>> So just starting up the IDE is more important than actually writing code
>> or fixing bugs?...
>>
>
> I'd like to see you do those things without starting your IDE.
>
>
>  Seriously, I'm never going to understand you "editor" people..
>>
>
> My oversimplification of it is, IDEs like the fundimental component of
> writing software. A text editor. Sure it has this text insertion thing, but
> it just looks like they forgot about it.
>

I don't know about you, but for me, a few second IDE startup time is
negligible compared to the several hours I'll spend using it in a single
stretch. Why, then, is the startup time more important than the
functionality it provides?

Re: D dropped in favour of C# for PSP emulator

[Jesse Phillips]

On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
So just starting up the IDE is more important than actually 
writing code or fixing bugs?...


I'd like to see you do those things without starting your IDE.


Seriously, I'm never going to understand you "editor" people..


My oversimplification of it is, IDEs like the fundimental 
component of writing software. A text editor. Sure it has this 
text insertion thing, but it just looks like they forgot about it.

Re: D dropped in favour of C# for PSP emulator

[Mehrdad]

On Friday, 18 May 2012 at 22:18:35 UTC, Andrei Alexandrescu wrote:
It is, and the decision (after a good amount of deliberation) 
is arbitrary. Some rationale was that SortedRange has enough 
structure to make it an "interesting" range, so I put it in 
std.range. The argument could go either way. Now it's gone one 
way. Let's move on.


Andrei


Okay; only pointed it out because I remembered it was also the 
subject of another one of my SO questions 
(stackoverflow.com/questions/6975670).

Re: D dropped in favour of C# for PSP emulator

[Brad Anderson]

On Fri, May 18, 2012 at 5:06 PM, H. S. Teoh  wrote:

> On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote:
> [...]
> > Also, I think std.algorithm could use a mini-FAQ.  std.range is long
> > overdue for an entire article explaining ranges but that's a well
> > known omission that pretty much everyone agrees on.
>
> What about the latest prerelease docs for std.range? I did clean up a
> lot of stuff there and tried to explain the basic idea of what a range
> is, and included a link to Andrei's article that describes the idea of
> ranges in-depth.
>
> Or is that still not good enough? How can we improve the docs further?
>
>
> T
>
> --
> Computers aren't intelligent; they only think they are.
>

I like it.  Looks like it's already up on the website and was included with
2.059 unless there are further changes beyond what's on
http://dlang.org/phobos/std_range.html

It's very clean now and the link to Andrei's article definitely helps.
Also, good thinking linking to the print version instead of the difficult
to read and confusing non-print version. People I link to Andrei's articles
on InformIT sometimes don't realize there is more than one page.

It's a great improvement to the documentation. I do agree with Jonathan,
though, that a official article on dlang.org like Steven's arrays article
would be a nice addition but what you've done helps enormously.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Friday, May 18, 2012 16:06:41 H. S. Teoh wrote:
> On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote:
> [...]
> 
> > Also, I think std.algorithm could use a mini-FAQ. std.range is long
> > overdue for an entire article explaining ranges but that's a well
> > known omission that pretty much everyone agrees on.
> 
> What about the latest prerelease docs for std.range? I did clean up a
> lot of stuff there and tried to explain the basic idea of what a range
> is, and included a link to Andrei's article that describes the idea of
> ranges in-depth.
> 
> Or is that still not good enough? How can we improve the docs further?

Making improvements to the docs is great and definitely a good idea (I don't 
think that I've looked what you've done yet though, so I can't comment on the 
specifics of what's there), but we really should have an in-depth article on 
ranges in D and Phobos similar to Steven's article on arrays. Solid 
documentation is a good starting point, but I don't think that it would be 
appropriate to go as in-depth with the documentation as a good article would.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[H. S. Teoh]

On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote:
[...]
> Also, I think std.algorithm could use a mini-FAQ.  std.range is long
> overdue for an entire article explaining ranges but that's a well
> known omission that pretty much everyone agrees on.

What about the latest prerelease docs for std.range? I did clean up a
lot of stuff there and tried to explain the basic idea of what a range
is, and included a link to Andrei's article that describes the idea of
ranges in-depth.

Or is that still not good enough? How can we improve the docs further?


T

-- 
Computers aren't intelligent; they only think they are.

Re: D dropped in favour of C# for PSP emulator

[Brad Anderson]

On Fri, May 18, 2012 at 3:36 PM, Mehrdad  wrote:

> On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:
>
>> I guess it is now :o).
>>
>> Andrei
>>
>
> lol
>
>
> One more thing that's also annoying about this is that it's not in
> std.algorithms, but std.range...
>
> Asn't binary search an algorithm?
>

I fairly often get confused about whether to look in std.range or
std.algorithm for something.  filter is in algorithm but recurrence is in
range, for instance. I can see why but I still sometimes go to the wrong
module's documentation to look something up. There should probably be a lot
more cross referencing between the two in the documentation.  Also, I think
std.algorithm could use a mini-FAQ.  std.range is long overdue for an
entire article explaining ranges but that's a well known omission that
pretty much everyone agrees on.

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/18/12 4:36 PM, Mehrdad wrote:

On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:

I guess it is now :o).

Andrei


lol


One more thing that's also annoying about this is that it's not in
std.algorithms, but std.range...

Asn't binary search an algorithm?


It is, and the decision (after a good amount of deliberation) is 
arbitrary. Some rationale was that SortedRange has enough structure to 
make it an "interesting" range, so I put it in std.range. The argument 
could go either way. Now it's gone one way. Let's move on.


Andrei

Re: D dropped in favour of C# for PSP emulator

[Mehrdad]

On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:

I guess it is now :o).

Andrei


lol


One more thing that's also annoying about this is that it's not 
in std.algorithms, but std.range...


Asn't binary search an algorithm?

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/18/12 4:11 PM, Peter Alexander wrote:

On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu wrote:

On 5/17/12 11:52 AM, Peter Alexander wrote:

On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:

I agree binarySearch is more precise, but I also think it's a minor
issue not worth the cost of changing at this point. Improving names of
things in the standard library is a quest that could go forever, make
everybody happy we're making progress, and achieve no substantial gain.


No need to change anything, just add something:

bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}

(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).


I don't see much benefit in this - just lateral walking. As long as
the keyphrase "binary search" is present in the documentation, that's
all that's needed as far as newcomers discoverability is concerned.


It's not just for newcomers discoverability, it's also for readability.
Reading the assumeSorted version, it's not clear that a binary search is
done.


I guess it is now :o).

Andrei

Re: D dropped in favour of C# for PSP emulator

[Peter Alexander]

On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu 
wrote:

On 5/17/12 11:52 AM, Peter Alexander wrote:
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu 
wrote:
I agree binarySearch is more precise, but I also think it's a 
minor
issue not worth the cost of changing at this point. Improving 
names of
things in the standard library is a quest that could go 
forever, make
everybody happy we're making progress, and achieve no 
substantial gain.


No need to change anything, just add something:

bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}

(constraints, predicates and the myriad of 
qualifiers/decorations

omitted for clarity).


I don't see much benefit in this - just lateral walking. As 
long as the keyphrase "binary search" is present in the 
documentation, that's all that's needed as far as newcomers 
discoverability is concerned.


It's not just for newcomers discoverability, it's also for 
readability. Reading the assumeSorted version, it's not clear 
that a binary search is done.

Re: D dropped in favour of C# for PSP emulator

[Alex Rønne Petersen]

On 18-05-2012 18:59, Bruno Medeiros wrote:

On 12/05/2012 01:00, Timon Gehr wrote:

some essential properties:
- starts up instantaneously

.

some 'nice to have' properties:
- code analysis based code completion

 > - integrated debugger

So just starting up the IDE is more important than actually writing code
or fixing bugs?...


I shouldn't have to keep my IDE open all the time when I'm not using it. 
I should be able to just open it at any point where I need it and close 
it immediately when I'm done.




Seriously, I'm never going to understand you "editor" people..



--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: D dropped in favour of C# for PSP emulator

[Mehrdad]

On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:

On 12/05/2012 01:00, Timon Gehr wrote:

some essential properties:
- starts up instantaneously



some 'nice to have' properties:
- code analysis based code completion

> - integrated debugger

So just starting up the IDE is more important than actually 
writing code or fixing bugs?...


Seriously, I'm never going to understand you "editor" people..


Latency vs. Throughput.


Both of them matter.

Re: D dropped in favour of C# for PSP emulator

[Bruno Medeiros]

On 12/05/2012 01:00, Timon Gehr wrote:

some essential properties:
- starts up instantaneously



some 'nice to have' properties:
- code analysis based code completion

> - integrated debugger

So just starting up the IDE is more important than actually writing code 
or fixing bugs?...


Seriously, I'm never going to understand you "editor" people..

--
Bruno Medeiros - Software Engineer

Re: D dropped in favour of C# for PSP emulator

[Peter Alexander]

On Thursday, 17 May 2012 at 18:46:11 UTC, Jonathan M Davis wrote:

On Thursday, May 17, 2012 18:00:40 bearophile wrote:

Andrei Alexandrescu:
> I agree binarySearch is more precise, but I also think it's a
> minor issue not worth the cost of changing at this point.
> Improving names of things in the standard library is a quest
> that could go forever, make everybody happy we're making
> progress, and achieve no substantial gain.

Names are very important, they are the fist and most important
part of an API, they are the first handle for human programmers
and their minds. The amount of care Python development group
gives to the choice of names is visible and it makes a 
difference

in Python usability.
Important names can't be chosen by a single person, because
single persons have quirks (they overstate how much common a 
word
or concept is, etc etc). So important names are better chosen 
by

groups, that allow to average out those quirks.
I suggest to stick somewhere inside Phobos a name like
"binarySearch".


Yes, names are important, but you'll also never get people to 
agree on them.
They're a classic bikeshedding issue. Unless a name is patently 
bad, if
changing it is going to break code, then you usually shouldn't 
change it - not
when we're talking about a public API (_especially_ when it's 
the standard
library of a language). All of the changes that we made to make 
Phobos'
function names actually follow Phobos' official naming 
conventions were

disruptive enough as it is.

We're really trying to read language and library stability, so 
breaking
changes need greater and greater justification for them to be 
worth it, and
simply renaming a function generally isn't going to cut it 
anymore - not

without a _very_ good reason.

- Jonathan M Davis


As far as I'm aware, no one has proposed any breaking changes. 
It's just a new function.

Re: D dropped in favour of C# for PSP emulator

[Philippe Sigaud]

On Fri, May 18, 2012 at 3:01 AM, Andrei Alexandrescu
 wrote:

>> I should read it anew, really, and complete the missing parts. Do not
>> hesitate to write an issue on GitHub if you see any mistakes.
>
> You may want to set up scripts that extract and compile code samples.

I did, as per your advice, and a very good one at that (levelled
dozens of bugs in my examples). About 200 samples get extracted from
the doc, compiled and logged. They all passed for 2.058, I don't think
2.059 changed anything that could affect my samples.
That was that extracting and compiling work that pushed me to write a
parser generator, btw.

The problem is not so much the code I show as what DMD now allows. For
example, I offer a poor man's UFCS mixin  in an example somewhere. But
now that DMD integrates UFCS, there is no real need for this mixin.
And so on.

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/17/12 5:44 PM, Philippe Sigaud wrote:

On Thu, May 17, 2012 at 7:00 PM, Marco Leise  wrote:


Your PDF is my reference manual on templates for quite a while. Thanks for 
putting it up!


Glad to hear it :-)
*Sigh* It's only 2-3 months old and is already lagging behind the
current D spec. Things like is(T t = U!(Args), Args...) are now
possible (I say otherwise in the appendix). The 'Args...' part is new.
Also, UFCS.
I should read it anew, really, and complete the missing parts. Do not
hesitate to write an issue on GitHub if you see any mistakes.


You may want to set up scripts that extract and compile code samples.

Andrei

Re: D dropped in favour of C# for PSP emulator

[Philippe Sigaud]

On Thu, May 17, 2012 at 7:00 PM, Marco Leise  wrote:

> Your PDF is my reference manual on templates for quite a while. Thanks for 
> putting it up!

Glad to hear it :-)
*Sigh* It's only 2-3 months old and is already lagging behind the
current D spec. Things like is(T t = U!(Args), Args...) are now
possible (I say otherwise in the appendix). The 'Args...' part is new.
Also, UFCS.
I should read it anew, really, and complete the missing parts. Do not
hesitate to write an issue on GitHub if you see any mistakes.

Re: D dropped in favour of C# for PSP emulator

[Marco Leise]

Am Mon, 14 May 2012 10:19:40 +0200
schrieb "Jakob Bornecrantz" :

> On Saturday, 12 May 2012 at 23:27:15 UTC, Alex Rønne Petersen
> wrote:
> >
> > You know, my project consisting of 130-ish source files and 
> > 24.000-ish lines of code compiles from scratch in ~20 seconds 
> > on my machine, building one file at a time... I honestly have 
> > not managed to come up with a build system for D that is 
> > actually slow, if compared to C/C++.
> 
> Try using GDC the compiler that can actually produce good code,
> or using -inline -release flags.
> 
> Debug build (GDC, multi invocation, 3 threads)
> real  0m42.452s
> 
> Release build (GDC, multi invocation, 3 threads)
> real  1m0.140s
> 
> Debug build (GDC, single invocation)
> real  0m22.151s
> 
> Release build (GDC, single invocation)
> real  0m54.960s
> 
> $ find src/ -name "*.d" | xargs wc -l | tail --lines 1
>  46057 total
> 
> Cheers, Jakob.

This is true. Once you decide to use GDC for whatever reason (chances of 
inclusion into GCC, better optimization, ...) you are also about 1 revision 
behind the DMD release. I usually assume that GDC 2.057 code will compile on 
DMD 2.059, but not the reverse. So I never actually use DMD any more to 
remember how fast it compiles. He could have made a similar experience.

Also I see a lot of you compare D with C/C++ compilation times, whereas the 
author was finally deciding for C#. I believe he used that language before and 
it probably has a compiler with comparable speed to DMD (e.g. much faster than 
GDC). After all a C# compiler can compile to simplistic byte code for a VM with 
much less real world constraints. Often compilers for VM languages come with 
the compiler integrated into the standard library, allowing for easy 
integration into IDEs and further optimizations of the compile time. I remember 
Delphi (not as a VM language) had the compiler and linker integrated into the 
IDE which made single file rebuilds practically instantaneous.

-- 
Marco

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/17/12 11:52 AM, Peter Alexander wrote:

On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:

I agree binarySearch is more precise, but I also think it's a minor
issue not worth the cost of changing at this point. Improving names of
things in the standard library is a quest that could go forever, make
everybody happy we're making progress, and achieve no substantial gain.


No need to change anything, just add something:

bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}

(constraints, predicates and the myriad of qualifiers/decorations
omitted for clarity).


I don't see much benefit in this - just lateral walking. As long as the 
keyphrase "binary search" is present in the documentation, that's all 
that's needed as far as newcomers discoverability is concerned.


Andrei

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Thursday, May 17, 2012 18:52:26 Peter Alexander wrote:
> On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu
> 
> wrote:
> > I agree binarySearch is more precise, but I also think it's a
> > minor issue not worth the cost of changing at this point.
> > Improving names of things in the standard library is a quest
> > that could go forever, make everybody happy we're making
> > progress, and achieve no substantial gain.
> 
> No need to change anything, just add something:
> 
> bool binarySearch(Range, Value)(Range range, Value value)
> {
> return assumeSorted(range).contains(value);
> }
> 
> (constraints, predicates and the myriad of qualifiers/decorations
> omitted for clarity).

Yeah, but then we've added a function which adds no real functionality, and we 
generally try to avoid that. So, it _might_ be reasonable to add it, but it
tends to go against how we're trying to function.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Thursday, May 17, 2012 18:00:40 bearophile wrote:
> Andrei Alexandrescu:
> > I agree binarySearch is more precise, but I also think it's a
> > minor issue not worth the cost of changing at this point.
> > Improving names of things in the standard library is a quest
> > that could go forever, make everybody happy we're making
> > progress, and achieve no substantial gain.
> 
> Names are very important, they are the fist and most important
> part of an API, they are the first handle for human programmers
> and their minds. The amount of care Python development group
> gives to the choice of names is visible and it makes a difference
> in Python usability.
> Important names can't be chosen by a single person, because
> single persons have quirks (they overstate how much common a word
> or concept is, etc etc). So important names are better chosen by
> groups, that allow to average out those quirks.
> I suggest to stick somewhere inside Phobos a name like
> "binarySearch".

Yes, names are important, but you'll also never get people to agree on them. 
They're a classic bikeshedding issue. Unless a name is patently bad, if 
changing it is going to break code, then you usually shouldn't change it - not 
when we're talking about a public API (_especially_ when it's the standard 
library of a language). All of the changes that we made to make Phobos' 
function names actually follow Phobos' official naming conventions were 
disruptive enough as it is.

We're really trying to read language and library stability, so breaking 
changes need greater and greater justification for them to be worth it, and 
simply renaming a function generally isn't going to cut it anymore - not 
without a _very_ good reason.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Marco Leise]

Am Fri, 11 May 2012 21:02:40 +0200
schrieb Philippe Sigaud :

> On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh  wrote:
> 
> > If newbies had the proper introduction to the concept of templates
> > (instead of being dunked in the deep end of the pool with signature
> > constraints that use templates, nested templates, etc., with no prior
> > warning), they wouldn't have such a hard time with them.
> 
> I wrote a tutorial on templates, any comment is welcome:
> 
> https://github.com/PhilippeSigaud/D-templates-tutorial
> 
> Direct link to the pdf:
> 
> https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true
> 
> I need to get back to it, I was side-tracked by other projects and
> still have things to add to the doc.
> 
> 
> Philippe

Your PDF is my reference manual on templates for quite a while. Thanks for 
putting it up!

-- 
Marco

Re: D dropped in favour of C# for PSP emulator

[H. S. Teoh]

On Thu, May 17, 2012 at 06:52:26PM +0200, Peter Alexander wrote:
> On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:
> >I agree binarySearch is more precise, but I also think it's a
> >minor issue not worth the cost of changing at this point.
> >Improving names of things in the standard library is a quest that
> >could go forever, make everybody happy we're making progress, and
> >achieve no substantial gain.
> 
> No need to change anything, just add something:
> 
> bool binarySearch(Range, Value)(Range range, Value value)
> {
> return assumeSorted(range).contains(value);
> }
> 
> (constraints, predicates and the myriad of qualifiers/decorations
> omitted for clarity).

Great minds think alike. ;-)


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

Re: D dropped in favour of C# for PSP emulator

[Peter Alexander]

On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu 
wrote:
I agree binarySearch is more precise, but I also think it's a 
minor issue not worth the cost of changing at this point. 
Improving names of things in the standard library is a quest 
that could go forever, make everybody happy we're making 
progress, and achieve no substantial gain.


No need to change anything, just add something:

bool binarySearch(Range, Value)(Range range, Value value)
{
return assumeSorted(range).contains(value);
}

(constraints, predicates and the myriad of qualifiers/decorations 
omitted for clarity).

Re: D dropped in favour of C# for PSP emulator

[H. S. Teoh]

On Thu, May 17, 2012 at 10:26:18AM -0500, Andrei Alexandrescu wrote:
> On 5/17/12 4:00 AM, Peter Alexander wrote:
[...]
> >I'd have to read the documentation to find out which of these uses
> >binary search. In fact, I'd probably have to read the Phobos source.
> >
> >If I just used binarySearch then I would be 100% guaranteed that it
> >will use a binary search. I don't have to second guess the compiler
> >-- I just *know*.
> 
> I agree binarySearch is more precise, but I also think it's a minor
> issue not worth the cost of changing at this point. Improving names
> of things in the standard library is a quest that could go forever,
> make everybody happy we're making progress, and achieve no
> substantial gain.
[...]

Why not just add something like this then:

E binarySearch(R,K)(R range, K key)
{
return assumeSorted(range).contains(key);
}

Nobody says we have to change the names of existing code. Adding a
wrapper with a nice name works just fine, and doesn't break any existing
code, etc..


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

Re: D dropped in favour of C# for PSP emulator

[bearophile]

Andrei Alexandrescu:

I agree binarySearch is more precise, but I also think it's a 
minor issue not worth the cost of changing at this point. 
Improving names of things in the standard library is a quest 
that could go forever, make everybody happy we're making 
progress, and achieve no substantial gain.


Names are very important, they are the fist and most important 
part of an API, they are the first handle for human programmers 
and their minds. The amount of care Python development group 
gives to the choice of names is visible and it makes a difference 
in Python usability.
Important names can't be chosen by a single person, because 
single persons have quirks (they overstate how much common a word 
or concept is, etc etc). So important names are better chosen by 
groups, that allow to average out those quirks.
I suggest to stick somewhere inside Phobos a name like 
"binarySearch".


Bye,
bearophile

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/17/12 4:00 AM, Peter Alexander wrote:

On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote:

How about users who don't know what binary search is. binary search is
an intuitive concept for people who have good programming experience
but assumeSorted(r).contains(x) is more intuitive to higher level users.


If you don't know about binary search, you won't write
assumeSorted(r).contains(x) you'll just write r.contains(x) because you
have no idea that binary search exists. Why would you bother typing
extra characters for a benefit that you are unaware of?

If you do know that binary search exists then the obvious algorithm name
is binarySearch. If I use .contains to coax a binarySearch then I'm
relying on a little bit of faith. In what situations does it give a
binary search?

[1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is sorted?


Doesn't compile.


iota(10).contains(5); // is iota implicitly a sorted range?


Doesn't compile.


assumeSorted([1, 2, 3]).map!(x => x + 1).contains(3); // does Phobos
know that the map is order preserving?


Doesn't compile, this would:

assumeSorted([1, 2, 3].map!(x => x + 1)).contains(3)

(which is quite a trick; map figures the input is a random-access range 
and exposes a random-access interface as well. Good luck doing that in 
other languages.)



assumeSorted([1, 2, 3]).filter!("a & 1").contains(2); // does Phobos
know that filters always preserve order?


Doesn't compile, and couldn't because filter() cannot preserve random 
access.



I'd have to read the documentation to find out which of these uses
binary search. In fact, I'd probably have to read the Phobos source.

If I just used binarySearch then I would be 100% guaranteed that it will
use a binary search. I don't have to second guess the compiler -- I just
*know*.


I agree binarySearch is more precise, but I also think it's a minor 
issue not worth the cost of changing at this point. Improving names of 
things in the standard library is a quest that could go forever, make 
everybody happy we're making progress, and achieve no substantial gain.



Andrei

Re: O.T. Re: D dropped in favour of C# for PSP emulator

[Regan Heath]

On Thu, 17 May 2012 09:50:44 +0100, Lars T. Kyllingstad  
 wrote:



On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote:

Al 17/05/12 03:32, En/na Walter Bright ha escrit:

On 5/16/2012 12:29 AM, bearophile wrote:

Then why is Andrei using the name std.algorithm.schwartzSort?

 May the schwartz be with you.



Very appropriate :-)
On 27 May is the 35 anniversary of the first released film from the  
Star Wars series.


Walter's quote was from "Spaceballs". :-)


Ahh.. I see your schwartz is as big as mine :p

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: D dropped in favour of C# for PSP emulator

[Peter Alexander]

On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote:
How about users who don't know what binary search is. binary 
search is an intuitive concept for people who have good 
programming experience but assumeSorted(r).contains(x) is more 
intuitive to higher level users.


If you don't know about binary search, you won't write 
assumeSorted(r).contains(x) you'll just write r.contains(x) 
because you have no idea that binary search exists. Why would you 
bother typing extra characters for a benefit that you are unaware 
of?


If you do know that binary search exists then the obvious 
algorithm name is binarySearch. If I use .contains to coax a 
binarySearch then I'm relying on a little bit of faith. In what 
situations does it give a binary search?


[1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is 
sorted?

iota(10).contains(5); // is iota implicitly a sorted range?
assumeSorted([1, 2, 3]).map!(x => x + 1).contains(3); // does 
Phobos know that the map is order preserving?
assumeSorted([1, 2, 3]).filter!("a & 1").contains(2); // does 
Phobos know that filters always preserve order?


I'd have to read the documentation to find out which of these 
uses binary search. In fact, I'd probably have to read the Phobos 
source.


If I just used binarySearch then I would be 100% guaranteed that 
it will use a binary search. I don't have to second guess the 
compiler -- I just *know*.

Re: O.T. Re: D dropped in favour of C# for PSP emulator

[Lars T. Kyllingstad]

On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote:

Al 17/05/12 03:32, En/na Walter Bright ha escrit:

On 5/16/2012 12:29 AM, bearophile wrote:

Then why is Andrei using the name std.algorithm.schwartzSort?


May the schwartz be with you.



Very appropriate :-)
On 27 May is the 35 anniversary of the first released film from 
the Star Wars series.


Walter's quote was from "Spaceballs". :-)

-Lars

O.T. Re: D dropped in favour of C# for PSP emulator

[Jordi Sayol]

Al 17/05/12 03:32, En/na Walter Bright ha escrit:
> On 5/16/2012 12:29 AM, bearophile wrote:
>> Then why is Andrei using the name std.algorithm.schwartzSort?
> 
> May the schwartz be with you.
> 

Very appropriate :-)
On 27 May is the 35 anniversary of the first released film from the Star Wars 
series.

-- 
Jordi Sayol

Re: D dropped in favour of C# for PSP emulator

[Walter Bright]

On 5/16/2012 12:29 AM, bearophile wrote:

Then why is Andrei using the name std.algorithm.schwartzSort?


May the schwartz be with you.

Re: D dropped in favour of C# for PSP emulator

[Tobias Pankrath]

It is. That's why there's no contains with linear complexity.

Andrei


I missed that. However SortedRange needs better documentation.
Before I wrote this, I tried to look it up and it took some time,
because I was looking in std.algorithm but SortedRange resides in
std.range.

The only reference to SortedRange from std.algorithm I could
find, was the use of assumeSorted (with no link).

So I think the first line of the description of
std.algorithm.find should be sometihng like: for binarySearch
look at SortedRange. Or include SortedRange in the table at the
top, but link to std.range.

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/16/12 9:47 AM, Tobias Pankrath wrote:

Andrei you are against an in-operator for array, because it would
provide a uniform interface for arrays and AA with different complexity.
Is contains with different complexity for ranges and for SortedRange not
the same?


It is. That's why there's no contains with linear complexity.

Andrei

Re: D dropped in favour of C# for PSP emulator

[Alex Rønne Petersen]

On 16-05-2012 17:28, Steven Schveighoffer wrote:

On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath  wrote:


Andrei you are against an in-operator for array, because it would
provide a uniform interface for arrays and AA with different
complexity. Is contains with different complexity for ranges and for
SortedRange not the same?


No it's not the same.

It all depends on what the function advertises as its complexity.

It's OK for a function that advertises O(n) complexity to be applied to
a type that's optimized into O(lgn) complexity.

But it's NOT OK for a function that advertises O(lgn) complexity to be
applied to a type that requires O(n) complexity.

It all depends on what the existing situation is. Generic code is
written against the documentation, because it doesn't know what's
actually going to be implemented underneath.

-Steve


People aren't using 'in' in generic code at all, so I'm not sure this 
comparison makes sense anyway.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: D dropped in favour of C# for PSP emulator

[Steven Schveighoffer]

On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath  wrote:

Andrei you are against an in-operator for array, because it would  
provide a uniform interface for arrays and AA with different  
complexity.  Is contains with different complexity for ranges and for  
SortedRange not the same?


No it's not the same.

It all depends on what the function advertises as its complexity.

It's OK for a function that advertises O(n) complexity to be applied to a  
type that's optimized into O(lgn) complexity.


But it's NOT OK for a function that advertises O(lgn) complexity to be  
applied to a type that requires O(n) complexity.


It all depends on what the existing situation is.  Generic code is written  
against the documentation, because it doesn't know what's actually going  
to be implemented underneath.


-Steve

Re: D dropped in favour of C# for PSP emulator

[Tobias Pankrath]

Andrei you are against an in-operator for array, because it would 
provide a uniform interface for arrays and AA with different 
complexity.  Is contains with different complexity for ranges and 
for SortedRange not the same?

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/16/12 2:29 AM, bearophile wrote:

Kirill:


How about users who don't know what binary search is. binary search is
an intuitive concept for people who have good programming experience
but assumeSorted(r).contains(x) is more intuitive to higher level users.


Even if you don't know the name "binary search" (something that all CS
students learn very early in their studies, a concept that is also
taught in "Unplugged CS" to little children) how can you be sure that
"assumeSorted(r).contains(x)" will perform a "fast search" like when you
search people names in a sorted sequence?



So in short, I support that Andrei aims for larger audience.


Then why is Andrei using the name std.algorithm.schwartzSort? For every
20 CS students and programmers that know what a "binary search" is, you
probably get only 1-4 that know what a "Schwartz Sorting" is. So I think
your explanation of Andrei aim doesn't hold water.


Just trying my best to do the right thing by everyone. Not much else to 
read into it.


Andrei

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/16/2012 09:29 AM, bearophile wrote:

Kirill:


How about users who don't know what binary search is. binary search is
an intuitive concept for people who have good programming experience
but assumeSorted(r).contains(x) is more intuitive to higher level users.


Even if you don't know the name "binary search" (something that all CS
students learn very early in their studies, a concept that is also
taught in "Unplugged CS" to little children) how can you be sure that
"assumeSorted(r).contains(x)" will perform a "fast search" like when you
search people names in a sorted sequence?



By assuming the library writer is sane, or by reading the documentation.




So in short, I support that Andrei aims for larger audience.


Then why is Andrei using the name std.algorithm.schwartzSort? For every
20 CS students and programmers that know what a "binary search" is, you
probably get only 1-4 that know what a "Schwartz Sorting" is. So I think
your explanation of Andrei aim doesn't hold water.



I agree, that the explanation does not hold water, not because of other 
parts of the API, but simply because binary search is such a basic 
concept that I wouldn't trust a programmer who does not understand it.

Re: D dropped in favour of C# for PSP emulator

[Mehrdad]

On Wednesday, 16 May 2012 at 07:05:29 UTC, Anders Sjögren wrote:

For carefully profiled code, that can be a disadvantage


Either that, or just the plain algorithm. Then the issue isn't 
profiling -- it's the time complexity.


e.g. You can't simply "pretend" it's doing the best thing 
possible, because libraries never get it right *all* the time. So 
IMHO saying /how/ to do it is a lot more useful than /what/ to 
do, since it lets you choose whether your algorithm is O(log(n)) 
vs. O(n) vs. O(1).


(Yes, this means I don't like C++'s std::map or 
std::unordered_set either, because they tell you nothing about 
the time complexity. Java did it correct there.)

Re: D dropped in favour of C# for PSP emulator

[bearophile]

Kirill:

How about users who don't know what binary search is. binary 
search is an intuitive concept for people who have good 
programming experience but assumeSorted(r).contains(x) is more 
intuitive to higher level users.


Even if you don't know the name "binary search" (something that 
all CS students learn very early in their studies, a concept that 
is also taught in "Unplugged CS" to little children) how can you 
be sure that "assumeSorted(r).contains(x)" will perform a "fast 
search" like when you search people names in a sorted sequence?




So in short, I support that Andrei aims for larger audience.


Then why is Andrei using the name std.algorithm.schwartzSort? For 
every 20 CS students and programmers that know what a "binary 
search" is, you probably get only 1-4 that know what a "Schwartz 
Sorting" is. So I think your explanation of Andrei aim doesn't 
hold water.


Bye,
bearophile

Re: D dropped in favour of C# for PSP emulator

[Anders Sjögren]

Since this post is about inuition, I'll raise my voice even 
though I'm a total D newbie (with background in C++, C#, Haskell, 
etc.).


From my point of view, the AssumeSorted way makes sense, but 
without getting a hit on it when searching for BinarySearch it's 
a bit cryptic. On the other hand, with search hits on the subject 
in the documenation, anyone should be able to use it. It's a 
matter of choosing if you want to express what should be done or 
how it should be done.


The concern I can see is about the difference in contract. 
BinarySearch explains how the operation is being performed and 
_promises_ to do a binary search. Contain does not promise how 
it's performed (that's the whole point, right?) and you're at the 
mercy of the library writer. For carefully profiled code, that 
can be a disadvantage, since any implementation change could lead 
to hidden changes in performance characteristics. Then you might 
want the control over exactly how the operation is performed.


The way I see it, both AssumeSorted.Contains and BinarySearch are 
overlapping in functionality (i.e. a fast search) but not 
equivalent in contract.

Re: D dropped in favour of C# for PSP emulator

[Kirill]

On Monday, 14 May 2012 at 10:31:47 UTC, Simen Kjaeraas wrote:
On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander 
 wrote:



On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:

Andrei Alexandrescu:


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.


It's self-explanatory if the name there contains something 
like

"binarySearch". Otherwise it is NOT self-explanatory, I can't
assume it will use a binary search.
So it's surely not intuitive.

Bye,
bearophile


100% agree with this.

How anyone can possibly think that using 
assumeSorted(r).contains(x) to do a binary search is more 
self-explanatory than just writing binarySearch(r, x) is 
beyond me. It's mind-boggling.


It is not intuitive, I agree. It is, however, documenting. 
You're not
calling binarySearch on any old array, you assume it is sorted, 
*then*

search it.

Perhaps it would be better to have a binarySearch function, 
which can
only take a SortedRange, and gives an explanatory error message 
when used

with a NonSortedRange.


How about users who don't know what binary search is. binary 
search is an intuitive concept for people who have good 
programming experience but assumeSorted(r).contains(x) is more 
intuitive to higher level users. see how many searches you get 
with binary search on google and how many with contains and 
sorted. I'm not a developer, I do quantum chemistry and write 
based on formulas and algorithms in papers, not on libraries. I 
would prefer people to write code in more general concepts so 
it's easier for me to understand and learn. And if you know 
binary search, it's not that much harder to change your style to 
assumeSorted(r).contains(x); in comparison, to a newbie learning 
binary search. Also having multiple ways of doing the same thing 
makes usage more confusing, so it should be avoided unless really 
needed.

So in short, I support that Andrei aims for larger audience.

Re: D dropped in favour of C# for PSP emulator

[Simen Kjaeraas]

On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander  
 wrote:



On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:

Andrei Alexandrescu:


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.


It's self-explanatory if the name there contains something like
"binarySearch". Otherwise it is NOT self-explanatory, I can't
assume it will use a binary search.
So it's surely not intuitive.

Bye,
bearophile


100% agree with this.

How anyone can possibly think that using assumeSorted(r).contains(x) to  
do a binary search is more self-explanatory than just writing  
binarySearch(r, x) is beyond me. It's mind-boggling.


It is not intuitive, I agree. It is, however, documenting. You're not
calling binarySearch on any old array, you assume it is sorted, *then*
search it.

Perhaps it would be better to have a binarySearch function, which can
only take a SortedRange, and gives an explanatory error message when used
with a NonSortedRange.

Re: D dropped in favour of C# for PSP emulator

[Peter Alexander]

On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:

Andrei Alexandrescu:


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.


It's self-explanatory if the name there contains something like
"binarySearch". Otherwise it is NOT self-explanatory, I can't
assume it will use a binary search.
So it's surely not intuitive.

Bye,
bearophile


100% agree with this.

How anyone can possibly think that using 
assumeSorted(r).contains(x) to do a binary search is more 
self-explanatory than just writing binarySearch(r, x) is beyond 
me. It's mind-boggling.


We have proof that it is not intuitive: the fact that people 
frequently ask how to do a binary search in std.algorithm. If it 
was intuitive, they wouldn't need to ask. If it was 
self-explanatory, it wouldn't need to be explicitly mentioned in 
the documentation. Needing documentation is precisely the 
opposite of self-explanatory.


Andrei, you are a reasonable person. What evidence would it take 
to convince you that this design for doing binary searches is bad?

Re: D dropped in favour of C# for PSP emulator

[Jakob Bornecrantz]

On Saturday, 12 May 2012 at 23:27:15 UTC, Alex Rønne Petersen
wrote:


You know, my project consisting of 130-ish source files and 
24.000-ish lines of code compiles from scratch in ~20 seconds 
on my machine, building one file at a time... I honestly have 
not managed to come up with a build system for D that is 
actually slow, if compared to C/C++.


Try using GDC the compiler that can actually produce good code,
or using -inline -release flags.

Debug build (GDC, multi invocation, 3 threads)
real0m42.452s

Release build (GDC, multi invocation, 3 threads)
real1m0.140s

Debug build (GDC, single invocation)
real0m22.151s

Release build (GDC, single invocation)
real0m54.960s

$ find src/ -name "*.d" | xargs wc -l | tail --lines 1
46057 total

Cheers, Jakob.

Re: D dropped in favour of C# for PSP emulator

[Jacob Carlborg]

On 2012-05-11 22:20, Jonathan M Davis wrote:


That's definitely an example of something that depends on your background.
std.algorithm.any does _exactly_ what it would do in a functional language.
How intuitive an API is depends a lot on how much the person writing the API
thinks like you. It's definitely something to strive for, but the best that you
can generally do is hit the majority of your target audience. You can never
hit everyone.

- Jonathan M Davis


This one exists in Ruby as well. But in Ruby the block/lambda is 
optional. If it's not passed it will return a bool indicating if the 
collection is empty or not, just as Mehrdad expected.


--
/Jacob Carlborg

Re: D dropped in favour of C# for PSP emulator

[H. S. Teoh]

On Sun, May 13, 2012 at 08:36:23PM +0200, Simen Kjaeraas wrote:
> On Sat, 12 May 2012 08:05:26 +0200, Paulo Pinto
>  wrote:
> 
> ˙ʇsod-doʇ ʇou op ǝsɐǝlԀ
> ˙uʍop-ǝpısdn sı ʇsod ɹnoʎ ǝʞıl sɯǝǝs ʇı ʇnq 'noʎ ɯɹɐlɐ oʇ ʇoN
[...]

rotflmaobbq... epic use of the unicode IPA block!


T

-- 
"I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, 
Iraqi Minister of Information

Re: D dropped in favour of C# for PSP emulator

[Simen Kjaeraas]

On Sat, 12 May 2012 08:05:26 +0200, Paulo Pinto   
wrote:


˙ʇsod-doʇ ʇou op ǝsɐǝlԀ
˙uʍop-ǝpısdn sı ʇsod ɹnoʎ ǝʞıl sɯǝǝs ʇı ʇnq 'noʎ ɯɹɐlɐ oʇ ʇoN


Your 'nice to have' features are for my type of
work 'must have' features, otherwise I could as
well just use Notepad++.

Having used GUI environments since the early MS-DOS
days, I don't have any issue with my mouse friend. :)

--
Paulo

Am 12.05.2012 02:00, schrieb Timon Gehr:

On 05/11/2012 07:39 PM, 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


Well, those are not reasons for me.

 > The lack of a good IDE,

Properties of a 'good IDE', as I see it:

some essential properties:
- starts up instantaneously
- uses the screen space efficiently
- supports editing text efficiently
- accepts keyboard input as given by the user.
- reasonable support for auto-indentation
- supports searching the code for some text efficiently
- keeps all code _readable_, especially the one that has been written
recently
- pattern recognition based code completion

- ... by default!

some 'nice to have' properties:
- code analysis based code completion
- navigate-to-declaration
- for those languages that require it: automatic generation of  
boilerplate.

- integrated debugger
- useful refactoring tools
- visualization of compilation errors (but please don't nag me)
- actual support for detecting semantic errors as they happen (extremely
difficult to do properly)
- any other argument that is commonly used to advertise IDEs

- ... _responsive_ on halfway recent hardware!

some anti-features:
- splash screen
- cannot run code if there is no 'project/solution file'
- sometimes messes up those files
- build fails - restart IDE - build works
- fancy GUI
- requires pointing device
- accidental hit of obscure keyboard combination ...
=> permanent, extremely annoying configuration change
=> no way to tell what happened
=> no undo operation
- termination of the debugged program kills the output console


As long as IDEs fail to satisfy every single point in the 'essential'
category and strive to have all of the stated anti-features, they don't
have much value for me anyway.

 > the complicated structure of the D language,

Cannot really comment on that, I think getting work done in D is simple,
and with DMD, just slightly harder than that.

 > the horrible compilation times,

wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of
horrible? Otherwise he might have hit a bug there.

 > caused that it taked too much time for everything, and made it
 > impossible to refactoring the code without days or weeks of work.

I'd have to know what kind of refactorings he carried out to be able to
comment on this.

Re: D dropped in favour of C# for PSP emulator

[Simen Kjaeraas]

On Fri, 11 May 2012 22:17:07 +0200, Nick Sabalausky  
 wrote:



"Mehrdad"  wrote in message
news:ynstshvzpaiusjyyo...@forum.dlang.org...

On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:

Templates are stencils for generating code. There's nothing confusing
about that.



"Stencils for generating code"? _This_??! :O



Geez, I think I need a vacation: My mind parsed that as a ternary  
operator

expression. Only when it tried to apply semantics did reality snap into
focus.


What did your mind do to the trigraph?

Reminded me of the WTF operator: ??!??!

Re: D dropped in favour of C# for PSP emulator

[bearophile]

Andrei Alexandrescu:


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.


It's self-explanatory if the name there contains something like
"binarySearch". Otherwise it is NOT self-explanatory, I can't
assume it will use a binary search.
So it's surely not intuitive.

Bye,
bearophile

Re: D dropped in favour of C# for PSP emulator

[H. S. Teoh]

On Sun, May 13, 2012 at 07:34:19AM +0700, Ary Manzana wrote:
> On 5/13/12 4:13 AM, Andrei Alexandrescu wrote:
> >On 5/11/12 10:38 PM, Ary Manzana wrote:
> >>Add a binarySearch(range, object) method that does all of that?
> >>
> >>I mean, I don't want to write more than a single line of code to do a
> >>binarySearch...
> >
> >assumeSorted(range).contains(object)
> >
> >is still one line, safer, and IMHO more self-explanatory.
> >
> >Andrei
> 
> Ok. When more people start saying that they can't find a
> binarySearch method... will you change your mind? :-)
[...]

Things like this just needs to be properly documented. Just because it
isn't called "binarySearch" doesn't mean anything. We aren't trying to
reinvent C#.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before 
which you can't deliver after.

Re: D dropped in favour of C# for PSP emulator

[Ary Manzana]

On 5/13/12 4:13 AM, Andrei Alexandrescu wrote:

On 5/11/12 10:38 PM, Ary Manzana wrote:

Add a binarySearch(range, object) method that does all of that?

I mean, I don't want to write more than a single line of code to do a
binarySearch...


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.

Andrei


Ok. When more people start saying that they can't find a binarySearch 
method... will you change your mind? :-)


(but let's first wait until that moment comes)

Re: D dropped in favour of C# for PSP emulator

[Alex Rønne Petersen]

On 13-05-2012 00:20, Nick Sabalausky wrote:

"Paulo Pinto"  wrote in message
news:jojish$2cm2$1...@digitalmars.com...


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



(Heh, now that Time Warner is no longer destroying GitHub for me and I can
actually *see* that page...)

"The lack of a good IDE, the complicated structure of the D language, the
horrible compilation times, caused that it taked too much time for
everything, and made it impossible to refactoring the code without days or
weeks of work."

That almost sounds like he's talking about some completely different D
programming language. And I know it's been discussed here already, but
seriously, "horrible compilation times"? What hell is he smoking?

Hmm, actually, you know what? I bet he was probably trying to do the C/C++
thing and compile one...source...file...at...a...time. THAT would certainly
do it. You can easily get nearly-C++-level speeds that way. Or maybe using
rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow
compared to say, rdmd.


You know, my project consisting of 130-ish source files and 24.000-ish 
lines of code compiles from scratch in ~20 seconds on my machine, 
building one file at a time... I honestly have not managed to come up 
with a build system for D that is actually slow, if compared to C/C++.




LOL, *or*...He didn't say "horribly SLOW compilation times", he just said
"horrible compilation times". Maybe he just hates fast compiles? Not even
enough time to go grab a coffee, let alone catch a movie and dinner. ;)




--
- Alex

Re: D dropped in favour of C# for PSP emulator

[Nick Sabalausky]

"Paulo Pinto"  wrote in message 
news:jojish$2cm2$1...@digitalmars.com...
>
> 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
>

(Heh, now that Time Warner is no longer destroying GitHub for me and I can 
actually *see* that page...)

"The lack of a good IDE, the complicated structure of the D language, the 
horrible compilation times, caused that it taked too much time for 
everything, and made it impossible to refactoring the code without days or 
weeks of work."

That almost sounds like he's talking about some completely different D 
programming language. And I know it's been discussed here already, but 
seriously, "horrible compilation times"? What hell is he smoking?

Hmm, actually, you know what? I bet he was probably trying to do the C/C++ 
thing and compile one...source...file...at...a...time. THAT would certainly 
do it. You can easily get nearly-C++-level speeds that way. Or maybe using 
rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow 
compared to say, rdmd.

LOL, *or*...He didn't say "horribly SLOW compilation times", he just said 
"horrible compilation times". Maybe he just hates fast compiles? Not even 
enough time to go grab a coffee, let alone catch a movie and dinner. ;)

Re: D dropped in favour of C# for PSP emulator

[Walter Bright]

On 5/12/2012 1:13 AM, Ary Manzana wrote:

On 5/12/12 12:14 PM, Nick Sabalausky wrote:

"DUE FOR TOMORROW"?!?

That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!


Hilarious :-)


Due-be-due-be-due! -- Sinatra

Re: D dropped in favour of C# for PSP emulator

[Dejan Lekic]

On Friday, 11 May 2012 at 19:02:50 UTC, Philippe Sigaud wrote:
On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh 
 wrote:


If newbies had the proper introduction to the concept of 
templates
(instead of being dunked in the deep end of the pool with 
signature
constraints that use templates, nested templates, etc., with 
no prior

warning), they wouldn't have such a hard time with them.


I wrote a tutorial on templates, any comment is welcome:

https://github.com/PhilippeSigaud/D-templates-tutorial

Direct link to the pdf:

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true

I need to get back to it, I was side-tracked by other projects 
and

still have things to add to the doc.


Philippe


Philippe, I have already went through that draft 3/4 times.

Even though I am in the D world for a decade, I always learn
something new about D templates and related.

Amazing work! Thank you!

Re: D dropped in favour of C# for PSP emulator

[Andrei Alexandrescu]

On 5/11/12 10:38 PM, Ary Manzana wrote:

Add a binarySearch(range, object) method that does all of that?

I mean, I don't want to write more than a single line of code to do a
binarySearch...


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.

Andrei

Re: D dropped in favour of C# for PSP emulator

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.657.1336847061.24740.digitalmar...@puremagic.com...
>
> Regardless, unfortunately, I don't remember why Walter doesn't want ref 
> local
> variables. You'd have to get him to explain that. I just remember that he
> doesn't want them and I don't think that it wasn't really up for 
> discussion.
> Maybe you can find an argument to convince him. I don't know. But from 
> what I
> recall, there isn't much chance of that.
>

IIRC, this was also explained in the big discussion on the dmd beta mailing 
list.

Re: D dropped in favour of C# for PSP emulator

[Nick Sabalausky]

"Manu"  wrote in message 
news:mailman.647.1336819289.24740.digitalmar...@puremagic.com...
> On 12 May 2012 13:13, Jonathan M Davis  wrote:
>
>> They just have to sort out how to avoid the issues that C++
>> has due to allow const& to take rvalues (which is why const ref in D
>> doesn't
>> currently take rvalues). So, there's a good chance that the situation 
>> will
>> improve considerably sometime soon.
>>
>
> What are these issues I keep hearing about? I'm not aware of any
> fundamental problem with ref in C++...
> Can you show an example of the problem the design is trying to avoid?
>

There was a big discussion of recently on the dmd beta mailing list . One of 
Andrei's posts there explained it all. (Sorry, I don't have a link handy 
ATM. Shouldn't be too hard to find, though.)

Re: D dropped in favour of C# for PSP emulator

[Nick Sabalausky]

"SomeDude"  wrote in message 
news:icvpcsajlyvsubowp...@forum.dlang.org...
>
> Indeed, and Timon forgot the best feature of IDEs for bytecode compilers 
> imho: they compile in the background, so that errors are detected while 
> you type. There is no annoying "write-correct" cycle as compile-time 
> errors are shown in real time. That's a *huge* productivity boost.

I find the sluggish text-editing that inevitably implies to be MUCH more 
destructive to my productivity than an occasional few seconds compiling 
after I'm done typing. The former interferes with my mental processes, the 
latter does not.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 15:17:22 Manu wrote:
> On 12 May 2012 14:03, Jonathan M Davis  wrote:
> > On Saturday, May 12, 2012 13:39:54 Manu wrote:
> > > Awesome, although it doesn't end there. Local references are also very
> > > important.
> > 
> > Never going to happen. Walter doesn't like them (they also cause issues
> > with
> > the proposal to let ref take rvalues in D IMHO), but I don't remember the
> > details. Regardless, I'd be shocked if they were ever introduced into D.
> 
> So what's the work around then?
> Using pointers pollute your usage with pointer assignment problems,
> and leads to many redundant instances of &, *, and parentheses all over the
> place.
> 
> Another scenario to consider:
> given: ref X someFunc();
> 
> ref X t = someFunc(); // fail
> 
> Without ref locals, there is no way to hold a local reference to something
> returned by a function, which defeats the purpose...
> And if ref is not a type constructor, auto and templates will never work
> properly either.

I believe that you can do it with a pointer.

auto t = &someFunc();

And as long as you don't try to increment the pointer, it's @safe. It doesn't 
even require different semantics when calling member functions, unlike C++ 
(though you'd still have to dereference it if you want to copy it, so the code 
would still differ somewhat from what you want in terms of syntax).

Regardless, unfortunately, I don't remember why Walter doesn't want ref local 
variables. You'd have to get him to explain that. I just remember that he 
doesn't want them and I don't think that it wasn't really up for discussion. 
Maybe you can find an argument to convince him. I don't know. But from what I 
recall, there isn't much chance of that.

> Well, while I'm sure that your use cases are very important and may be
> 
> > normal
> > in your industry, I don't think that they're normal in the programming
> > world
> > in general.
> 
> I've never met a C++ programmer (other than yourself apparently) that
> doesn't pass structs/classes by ref.
> That's generally considered absurd. And if you want evidence, just look at
> the STL, Boost, or any other C++ library you care to pick.

C++ is not D. The semantics of passing arguments are not the same (thanks 
primary to postblit vs copy constructors). D creates fewer copies than C++. 
And actually, with C++'s move constructors, as I understand it, the advice is 
to no longer use const& for passing objects because it screws up the 
compiler's ability to optimize out temporaries (and the C++11 situation is 
much closer to D's situation than C++98 was).

But regardless, I was never advocating that you _always_ pass structs by 
value. I was pointing out that for smaller structs (those with only a few 
members), it generally works just fine - except maybe in cases where you're 
worrying about absolutely every CPU cycle.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 14:03, Jonathan M Davis  wrote:

> On Saturday, May 12, 2012 13:39:54 Manu wrote:
> > Awesome, although it doesn't end there. Local references are also very
> > important.
>
> Never going to happen. Walter doesn't like them (they also cause issues
> with
> the proposal to let ref take rvalues in D IMHO), but I don't remember the
> details. Regardless, I'd be shocked if they were ever introduced into D.
>

So what's the work around then?
Using pointers pollute your usage with pointer assignment problems,
and leads to many redundant instances of &, *, and parentheses all over the
place.

Another scenario to consider:
given: ref X someFunc();

ref X t = someFunc(); // fail

Without ref locals, there is no way to hold a local reference to something
returned by a function, which defeats the purpose...
And if ref is not a type constructor, auto and templates will never work
properly either.

Well, while I'm sure that your use cases are very important and may be
> normal
> in your industry, I don't think that they're normal in the programming
> world
> in general.


I've never met a C++ programmer (other than yourself apparently) that
doesn't pass structs/classes by ref.
That's generally considered absurd. And if you want evidence, just look at
the STL, Boost, or any other C++ library you care to pick.

Most programmers don't care one whit about registers. They want the
> compiler to be

effecient in what it does, but they don't usually worry about stuff like
> whether
> a particular variable will fit in a register or not.


That's true, and for that very reason, they were taught to ALWAYS use const
T& whenever passing any non-trivial type. I've never met a single
programmer who is an exception.
Universities teach this practise, books teach this practice, and every
major C++ library you can point at implements this practise.

This has nothing to do with my particular use case. I've never seen an
example of, or anyone advocating passing non-trivial data by value in C++.
One of my biggest criticisms of C++ is that people over-use ref's even in
the (rare) cases where they shouldn't (passing a single int/float by const
ref; relates back to my performance considerations), but that's certainly
far better/safer than passing everything by value all the time when used in
weak C++ templates (D could easily mitigate this problem).

If they were, languages like Java and C# would never have gotten
> anywhere in the first place. So, while D should definitely support what
> you're
> trying to do, it's not what the average programmer is trying to do. Most
> programmers don't care one whit about registers.They want the compiler to
> be

effecient in what it does, but they don't usually worry about stuff like
> whether

a particular variable will fit in a register or not.


They may not care, but the compiler does, and the compiler can't possibly
be efficient if it's being told to copy heaps of data around all over the
place.
There's nothing the compiler can do to magically make it go away, that's
why it's so important.

Java and C# only support my argument, they pass everything by ref all the
time, with the exception of C# structs, which behave exactly like in D. As
a result, they introduced 'ref' too, except it works as expected in all use
cases I presented above.
C# is the closest/best comparison here. C# is basically identical to D, but
with one exception, 'ref' works in all situations you expect.

Re: D dropped in favour of C# for PSP emulator

[Dmitry Olshansky]

On 12.05.2012 14:39, Manu wrote:

On 12 May 2012 13:13, Jonathan M Davis mailto:jmdavisp...@gmx.com>> wrote:

So, basically it's just the issue with neither ref nor const ref taking
lvalues.


And the local references, and the bug.

If you duplicate the functions (or use auto ref if they're templated
functions), then it's not an issue.


Yes it is. Passing by value is NOT passing by reference, it's a totally
different operation. And what about non-const ref?
'in ref' would be very nice if it worked. It would basically replace
'const ref'.

It sucks to have to duplicate stuff, but
ref works just fine as long as you don't assume that it's going to
allow you to
pass rvalues to it.


Well there's the bugs we've seen in optimised codegen.
Duplicating with non-ref is not a solution. It's not even a workaround.
The only workaround is to receive a pointer, which ruins all those cases
in terms of syntax anyway.

Personally, I almost always just have functions take
structs by value, so it's a non-issue except for stuff like
opEquals, which
requires const ref (for at least one overload anyway).


Well I think it's safe to say most people pass data structs by
reference. If I saw someone pass a struct by val, I'd consider it a
bug/typo and fix it.


Brr... most ranges are structs. And yes, they are passed by value 
(rightfully so).



--
Dmitry Olshansky

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 13:39:54 Manu wrote:
> Awesome, although it doesn't end there. Local references are also very
> important.

Never going to happen. Walter doesn't like them (they also cause issues with 
the proposal to let ref take rvalues in D IMHO), but I don't remember the 
details. Regardless, I'd be shocked if they were ever introduced into D.

> They just have to sort out how to avoid the issues that C++
> 
> > has due to allow const& to take rvalues (which is why const ref in D
> > doesn't
> > currently take rvalues). So, there's a good chance that the situation will
> > improve considerably sometime soon.
> 
> What are these issues I keep hearing about? I'm not aware of any
> fundamental problem with ref in C++...
> Can you show an example of the problem the design is trying to avoid?

Go check out the discussion in the beta list. I can never remember the details 
beyond the fact that it screws up overloading:

http://forum.dlang.org/post/4f84d6dd.5090...@digitalmars.com

> Well, in my line of work, if the cost of passing by value is greater than
> the cost of passing by reference, then the correct thing to do is to pass
> by reference. There is zero tolerance for wasting memory accesses on such a
> trivial operation.
> The only case where the cost of passing by value is ever less than by
> reference is if the struct contains a single primitive value for which the
> CPU has a dedicated register type. This is the only time we would ever
> tolerate passing by value.

Well, while I'm sure that your use cases are very important and may be normal 
in your industry, I don't think that they're normal in the programming world 
in general. If they were, languages like Java and C# would never have gotten 
anywhere in the first place. So, while D should definitely support what you're 
trying to do, it's not what the average programmer is trying to do. Most 
programmers don't care one whit about registers. They want the compiler to be 
effecient in what it does, but they don't usually worry about stuff like 
whether 
a particular variable will fit in a register or not. Certain industries and use 
cases care a great deal about that sort of thing, but not your average use 
case or your average programmer. In most cases, passing around a struct with 
several member variables isn't a big deal at all - especially since the cost 
is going to be drowned out by other operations very easily. But obviously, 
things are different for you and your particular use cases.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 13:13, Jonathan M Davis  wrote:

> So, basically it's just the issue with neither ref nor const ref taking
> lvalues.


And the local references, and the bug.

If you duplicate the functions (or use auto ref if they're templated
> functions), then it's not an issue.


Yes it is. Passing by value is NOT passing by reference, it's a totally
different operation. And what about non-const ref?
'in ref' would be very nice if it worked. It would basically replace 'const
ref'.

It sucks to have to duplicate stuff, but
> ref works just fine as long as you don't assume that it's going to allow
> you to
> pass rvalues to it.


Well there's the bugs we've seen in optimised codegen.
Duplicating with non-ref is not a solution. It's not even a workaround. The
only workaround is to receive a pointer, which ruins all those cases in
terms of syntax anyway.

Personally, I almost always just have functions take
> structs by value, so it's a non-issue except for stuff like opEquals, which
> requires const ref (for at least one overload anyway).
>

Well I think it's safe to say most people pass data structs by reference.
If I saw someone pass a struct by val, I'd consider it a bug/typo and fix
it.
You might say to use a class in D, but classes aren't a pure data structure
like they are in C; I see them as being for fundamentally different
purposes, and I wouldn't use a class to express a struct.
Classes also ruin strict data layout and alignment of members. I don't
think that's a valid workaround either, it's effectively abusing the very
_concept_ of classes in D.

However, given the ridiculousness of having to duplicate functions to make
> ref
> usuable for any case where you're specifically trying to avoid a copy
> rather
> than use it to pass a value out, Andrei and Walter are looking at making
> ref
> work with rvalues.


Awesome, although it doesn't end there. Local references are also very
important.

They just have to sort out how to avoid the issues that C++
> has due to allow const& to take rvalues (which is why const ref in D
> doesn't
> currently take rvalues). So, there's a good chance that the situation will
> improve considerably sometime soon.
>

What are these issues I keep hearing about? I'm not aware of any
fundamental problem with ref in C++...
Can you show an example of the problem the design is trying to avoid?

> That's not a solution, it's not even a work around, it's a totally
> > different operation. I may not want to, or can't, pass my data by value.
>
> Whether passing by value makes sense depends on the struct. If it has lots
> of
> members, then no, passing by value doesn't work very well (though still
> not as
> badly as C++98 thanks to the fact that D can move structs far more often
> due
> to its different copy semantics). But almost all of the structs that I deal
> with only have a handful of member variables at most, so the cost of
> passing
> by value isn't high. In most cases, if I have a lot, I probably wanted a
> reference type anyway, in which case, I'm almost certainly going to use a
> class.
>

Well, in my line of work, if the cost of passing by value is greater than
the cost of passing by reference, then the correct thing to do is to pass
by reference. There is zero tolerance for wasting memory accesses on such a
trivial operation.
The only case where the cost of passing by value is ever less than by
reference is if the struct contains a single primitive value for which the
CPU has a dedicated register type. This is the only time we would ever
tolerate passing by value.

But there's no question that the situation with const ref needs to be
> improved
> (it was discussed quite a bit on the beta list during the last beta).
> Fortunately, that's likely to happen sometime soon.


That's a shame, it's been coming up every day for me the last couple of
weeks. I have workarounds in almost every source file, and some cases where
a workaround is impossible, which pollutes the code at the point of use.

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/12/2012 11:37 AM, Manu wrote:

On 12 May 2012 12:26, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On 05/12/2012 10:13 AM, Manu wrote:

On 11 May 2012 21:28, Mehrdad mailto:wfunct...@hotmail.com>
>__>
wrote:

Yes, I agree, but consider that D users should NOT have to
work with
pointers to do something so basic


I'd like to think this were true, but the fact that 'ref' barely
works
makes this almost immediately false when trying to write any
non-trivial
program.


It depends on the coding style.


If the distinction is whether one likes to have data structures in their
code or not,


Classes and dynamic arrays can be used to build data structures as well, 
so whether or not you usually use pointers is a matter of style. (FWIW, 
I use them too.)



I reckon there's a reasonably large user base in the former? :)
Once you use 'struct' you can't avoid pointers, given that ref just
doesn't work in many (perhaps most) situations.


The assertion was

"Yes, I agree, but consider that D users should NOT *have to* work with 
pointers *to do something so basic*"

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/12/2012 12:13 PM, Jonathan M Davis wrote:

On Saturday, May 12, 2012 13:03:26 Manu wrote:

On 12 May 2012 12:37, Jonathan M Davis  wrote:

On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:

On 05/12/2012 10:13 AM, Manu wrote:

On 11 May 2012 21:28, Mehrdadmailto:wfunct...@hotmail.com>>  wrote:
 Yes, I agree, but consider that D users should NOT have to work


with


 pointers to do something so basic

I'd like to think this were true, but the fact that 'ref' barely works
makes this almost immediately false when trying to write any


non-trivial


program.


It depends on the coding style.


I rarely end up passing by either ref or pointer, and the only issues that
I've ever had with ref relate to the fact that you can't pass it rvalues.
Obviously both pointers and ref have their uses, but I'd definitely have
to
concur that it depends on your coding style and what you're doing. Also, I
really don't know what's wrong with ref such that anyone could say that it
"barely works" other than the issues with rvalues and functions which take
ref
or const ref.


struct X
{
int i;

X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); }
ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return
this; }
...etc
}

ref X func(ref X x)
{
return x;
}

bool maybe()
{
return (time()&  1) != 0;
}

void test()
{
X a,b,c;
X v[];

func(a); // this is basically the only expression that works
X t = a + (b + c); // fail
a += b + c; // fail
ref X t = func(a); // fail
func(a + b); // fail
func(maybe() ? a : b); // this generates bad code:
http://forum.dlang.org/thread/cnwpmhihmckpjhlas...@forum.dlang.org
ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())];
// fail

foreach(i; 0..10)
{
ref X t = v[some + expression * involving - i]; // fail
}
}

Just a couple of extremely common usage patterns that come to mind. I'm
sure there are many more...


So, basically it's just the issue with neither ref nor const ref taking
lvalues. If you duplicate the functions (or use auto ref if they're templated
functions), then it's not an issue. It sucks to have to duplicate stuff, but
ref works just fine as long as you don't assume that it's going to allow you to
pass rvalues to it. Personally, I almost always just have functions take
structs by value, so it's a non-issue except for stuff like opEquals, which
requires const ref (for at least one overload anyway).

However, given the ridiculousness of having to duplicate functions to make ref
usuable for any case where you're specifically trying to avoid a copy rather
than use it to pass a value out, Andrei and Walter are looking at making ref
work with rvalues. They just have to sort out how to avoid the issues that C++
has due to allow const&  to take rvalues (which is why const ref in D doesn't
currently take rvalues). So, there's a good chance that the situation will
improve considerably sometime soon.

- Jonathan M Davis


I don't see why 'const' should make a difference there anyway. It is 
completely orthogonal. It could be argued that the callee might assume 
that his changes will be visible for the caller, but if the point of 
passing an rvalue by reference is to gain performance, forbidding the 
callee to use it as scratch space is just ridiculous.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 13:10:17 Manu wrote:
> That's not a solution, it's not even a work around, it's a totally
> different operation. I may not want to, or can't, pass my data by value.

Whether passing by value makes sense depends on the struct. If it has lots of 
members, then no, passing by value doesn't work very well (though still not as 
badly as C++98 thanks to the fact that D can move structs far more often due 
to its different copy semantics). But almost all of the structs that I deal 
with only have a handful of member variables at most, so the cost of passing 
by value isn't high. In most cases, if I have a lot, I probably wanted a 
reference type anyway, in which case, I'm almost certainly going to use a 
class.

But there's no question that the situation with const ref needs to be improved 
(it was discussed quite a bit on the beta list during the last beta). 
Fortunately, that's likely to happen sometime soon.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/12/2012 08:53 AM, SomeDude wrote:

On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:


I do have to say that I find it somewhat funny that this is your set of
requirements for an IDEA and yet "integrated debugger" is in the "some
'nice
to have' features" section. Doesn't an IDE _have_ to have an integrated
debugger or it's only a code editor (since it lacks the whole
integrated part
of Integrated Development Environment).

- Jonathan M Davis



Indeed, and Timon forgot the best feature of IDEs for bytecode compilers
imho: they compile in the background, so that errors are detected while
you type.


Probably I didn't express myself properly, but this was meant to be 
included at the


' - visualization of compilation errors (but please don't nag me)'

point.


There is no annoying "write-correct" cycle as compile-time
errors are shown in real time. That's a *huge* productivity boost.


* When I fail to write code that actually compiles, a few seconds of 
additional waiting time seem to be deserved. (it might be a longer time 
for eg. C++ though, so there this argument might not apply). If a 
programmer usually cannot write code that compiles, what are the chances 
that his code will be correct when it is run?


* The write-correct cycle is still there (actually it is a 
write-run-correct cycle), because current IDEs only catch trivial errors.



It's actually better than with interpreted or scripted languages,
because once you've finished writing code, it will run !
Basically, with modern IDEs, the productivity with languages like Java/C# is 
comparable
to Python.



If I have to develop in Java, emacs or even gedit usually do just fine.


Background compiling shouldn't be too hard to implement for an editor, I
guess: run the compiler in background on the current module every other
second (or only when a set of simple syntaxic conditions like
parentheses/accolades matching are matched, conditions which can easily
be checked by the editor itself), and display the error messages in semi
real time on screen where they appear.


This is too simplistic and very wasteful. The same data will be 
processed all over again. I don't know how IDEs manage to make modern 
>2GHZ quad-core systems appear slow, but it might well be that kind of 
coding.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 13:03:26 Manu wrote:
> On 12 May 2012 12:37, Jonathan M Davis  wrote:
> > On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:
> > > On 05/12/2012 10:13 AM, Manu wrote:
> > > > On 11 May 2012 21:28, Mehrdad  > > > 
> > > > > wrote:
> > > > Yes, I agree, but consider that D users should NOT have to work
> > 
> > with
> > 
> > > > pointers to do something so basic
> > > > 
> > > > I'd like to think this were true, but the fact that 'ref' barely works
> > > > makes this almost immediately false when trying to write any
> > 
> > non-trivial
> > 
> > > > program.
> > > 
> > > It depends on the coding style.
> > 
> > I rarely end up passing by either ref or pointer, and the only issues that
> > I've ever had with ref relate to the fact that you can't pass it rvalues.
> > Obviously both pointers and ref have their uses, but I'd definitely have
> > to
> > concur that it depends on your coding style and what you're doing. Also, I
> > really don't know what's wrong with ref such that anyone could say that it
> > "barely works" other than the issues with rvalues and functions which take
> > ref
> > or const ref.
> 
> struct X
> {
> int i;
> 
> X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); }
> ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return
> this; }
> ...etc
> }
> 
> ref X func(ref X x)
> {
> return x;
> }
> 
> bool maybe()
> {
> return (time() & 1) != 0;
> }
> 
> void test()
> {
> X a,b,c;
> X v[];
> 
> func(a); // this is basically the only expression that works
> X t = a + (b + c); // fail
> a += b + c; // fail
> ref X t = func(a); // fail
> func(a + b); // fail
> func(maybe() ? a : b); // this generates bad code:
> http://forum.dlang.org/thread/cnwpmhihmckpjhlas...@forum.dlang.org
> ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())];
> // fail
> 
> foreach(i; 0..10)
> {
> ref X t = v[some + expression * involving - i]; // fail
> }
> }
> 
> Just a couple of extremely common usage patterns that come to mind. I'm
> sure there are many more...

So, basically it's just the issue with neither ref nor const ref taking 
lvalues. If you duplicate the functions (or use auto ref if they're templated 
functions), then it's not an issue. It sucks to have to duplicate stuff, but 
ref works just fine as long as you don't assume that it's going to allow you to 
pass rvalues to it. Personally, I almost always just have functions take 
structs by value, so it's a non-issue except for stuff like opEquals, which 
requires const ref (for at least one overload anyway).

However, given the ridiculousness of having to duplicate functions to make ref 
usuable for any case where you're specifically trying to avoid a copy rather 
than use it to pass a value out, Andrei and Walter are looking at making ref 
work with rvalues. They just have to sort out how to avoid the issues that C++ 
has due to allow const& to take rvalues (which is why const ref in D doesn't 
currently take rvalues). So, there's a good chance that the situation will 
improve considerably sometime soon.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 12:43, Jonathan M Davis  wrote:

> On Saturday, May 12, 2012 12:37:12 Manu wrote:
> > On 12 May 2012 12:26, Timon Gehr  wrote:
> > > On 05/12/2012 10:13 AM, Manu wrote:
> > >> On 11 May 2012 21:28, Mehrdad  > >>
> > >> **> wrote:
> > >>Yes, I agree, but consider that D users should NOT have to work
> with
> > >>pointers to do something so basic
> > >>
> > >> I'd like to think this were true, but the fact that 'ref' barely works
> > >> makes this almost immediately false when trying to write any
> non-trivial
> > >> program.
> > >
> > > It depends on the coding style.
> >
> > If the distinction is whether one likes to have data structures in their
> > code or not, I reckon there's a reasonably large user base in the
> former? :)
> > Once you use 'struct' you can't avoid pointers, given that ref just
> doesn't
> > work in many (perhaps most) situations.
>
> Since structs are generally value types, it's extremely common to just pass
> them by value - so no refs or pointers are involved.


... no. structs are for storing structured data. They may be rather large,
they may aggregate smaller structs. In my entire career as a programmer, I
can count the number of times I've wanted to pass a struct by value on
perhaps one hand.

I _rarely_ need pointers
> for structs, and I don't need ref for them all that often either.


If you need pointers at all, and you want to stick with D's modern
pointers-shouldn't-appear-in-day-to-day-code idiom, then you need ref.


> And aside
> from the need to duplicate functions which take const ref so that they work
> with rvalues, I don't know what about ref you could think doesn't work.
>

That's not a solution, it's not even a work around, it's a totally
different operation. I may not want to, or can't, pass my data by value.

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 12:37, Jonathan M Davis  wrote:

> On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:
> > On 05/12/2012 10:13 AM, Manu wrote:
> > > On 11 May 2012 21:28, Mehrdad  > >
> > > > wrote:
> > > Yes, I agree, but consider that D users should NOT have to work
> with
> > > pointers to do something so basic
> > >
> > > I'd like to think this were true, but the fact that 'ref' barely works
> > > makes this almost immediately false when trying to write any
> non-trivial
> > > program.
> >
> > It depends on the coding style.
>
> I rarely end up passing by either ref or pointer, and the only issues that
> I've ever had with ref relate to the fact that you can't pass it rvalues.
> Obviously both pointers and ref have their uses, but I'd definitely have to
> concur that it depends on your coding style and what you're doing. Also, I
> really don't know what's wrong with ref such that anyone could say that it
> "barely works" other than the issues with rvalues and functions which take
> ref
> or const ref.
>

struct X
{
int i;

X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); }
ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return
this; }
...etc
}

ref X func(ref X x)
{
return x;
}

bool maybe()
{
return (time() & 1) != 0;
}

void test()
{
X a,b,c;
X v[];

func(a); // this is basically the only expression that works
X t = a + (b + c); // fail
a += b + c; // fail
ref X t = func(a); // fail
func(a + b); // fail
func(maybe() ? a : b); // this generates bad code:
http://forum.dlang.org/thread/cnwpmhihmckpjhlas...@forum.dlang.org
ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())];
// fail

foreach(i; 0..10)
{
ref X t = v[some + expression * involving - i]; // fail
}
}

Just a couple of extremely common usage patterns that come to mind. I'm
sure there are many more...

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/12/2012 08:04 AM, Nick Sabalausky wrote:

"Timon Gehr"  wrote in message
news:jok96k$l7t$1...@digitalmars.com...


Properties of a 'good IDE', as I see it:

some essential properties:
- starts up instantaneously
- uses the screen space efficiently
- supports editing text efficiently
- accepts keyboard input as given by the user.
- reasonable support for auto-indentation
- supports searching the code for some text efficiently
- keeps all code _readable_, especially the one that has been written
recently
- pattern recognition based code completion

- ... by default!

some 'nice to have' properties:
- code analysis based code completion
- navigate-to-declaration
- for those languages that require it: automatic generation of
boilerplate.
- integrated debugger
- useful refactoring tools
- visualization of compilation errors (but please don't nag me)
- actual support for detecting semantic errors as they happen (extremely
difficult to do properly)
- any other argument that is commonly used to advertise IDEs

- ... _responsive_ on halfway recent hardware!

some anti-features:
- splash screen
- cannot run code if there is no 'project/solution file'
- sometimes messes up those files
- build fails - restart IDE - build works
- fancy GUI
- requires pointing device
- accidental hit of obscure keyboard combination ...
   =>  permanent, extremely annoying configuration change
   =>  no way to tell what happened
   =>  no undo operation
- termination of the debugged program kills the output console


As long as IDEs fail to satisfy every single point in the 'essential'
category and strive to have all of the stated anti-features, they don't
have much value for me anyway.



Hear hear!

Although I'd swap the positions of "pattern recognition based code
completion" and "_responsive_ on halfway recent hardware!".


The - ... points were meant to apply to all the other points in their 
group. Eg. navigate-to-declaration is extremely annoying if after the 
click, there is a pause of multiple seconds.



In fact, I'd put "responsive" at the top of the "essential" list.



I have to agree. It could be argued that responsiveness was included in 
'starts up instantaneously'/'supports editing text efficiently'.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 12:37:12 Manu wrote:
> On 12 May 2012 12:26, Timon Gehr  wrote:
> > On 05/12/2012 10:13 AM, Manu wrote:
> >> On 11 May 2012 21:28, Mehrdad  >> 
> >> **> wrote:
> >>Yes, I agree, but consider that D users should NOT have to work with
> >>pointers to do something so basic
> >> 
> >> I'd like to think this were true, but the fact that 'ref' barely works
> >> makes this almost immediately false when trying to write any non-trivial
> >> program.
> > 
> > It depends on the coding style.
> 
> If the distinction is whether one likes to have data structures in their
> code or not, I reckon there's a reasonably large user base in the former? :)
> Once you use 'struct' you can't avoid pointers, given that ref just doesn't
> work in many (perhaps most) situations.

Since structs are generally value types, it's extremely common to just pass 
them by value - so no refs or pointers are involved. I _rarely_ need pointers 
for structs, and I don't need ref for them all that often either. And aside 
from the need to duplicate functions which take const ref so that they work 
with rvalues, I don't know what about ref you could think doesn't work.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 12:26, Timon Gehr  wrote:

> On 05/12/2012 10:13 AM, Manu wrote:
>
>> On 11 May 2012 21:28, Mehrdad > **> wrote:
>>
>>Yes, I agree, but consider that D users should NOT have to work with
>>pointers to do something so basic
>>
>>
>> I'd like to think this were true, but the fact that 'ref' barely works
>> makes this almost immediately false when trying to write any non-trivial
>> program.
>>
>
> It depends on the coding style.
>

If the distinction is whether one likes to have data structures in their
code or not, I reckon there's a reasonably large user base in the former? :)
Once you use 'struct' you can't avoid pointers, given that ref just doesn't
work in many (perhaps most) situations.

Re: D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:
> On 05/12/2012 10:13 AM, Manu wrote:
> > On 11 May 2012 21:28, Mehrdad  > 
> > > wrote:
> > Yes, I agree, but consider that D users should NOT have to work with
> > pointers to do something so basic
> > 
> > I'd like to think this were true, but the fact that 'ref' barely works
> > makes this almost immediately false when trying to write any non-trivial
> > program.
> 
> It depends on the coding style.

I rarely end up passing by either ref or pointer, and the only issues that 
I've ever had with ref relate to the fact that you can't pass it rvalues. 
Obviously both pointers and ref have their uses, but I'd definitely have to 
concur that it depends on your coding style and what you're doing. Also, I 
really don't know what's wrong with ref such that anyone could say that it 
"barely works" other than the issues with rvalues and functions which take ref 
or const ref.

- Jonathan M Davis

Re: D dropped in favour of C# for PSP emulator

[Timon Gehr]

On 05/12/2012 10:13 AM, Manu wrote:

On 11 May 2012 21:28, Mehrdad mailto:wfunct...@hotmail.com>> wrote:

Yes, I agree, but consider that D users should NOT have to work with
pointers to do something so basic


I'd like to think this were true, but the fact that 'ref' barely works
makes this almost immediately false when trying to write any non-trivial
program.


It depends on the coding style.

Re: D dropped in favour of C# for PSP emulator

[Kagamin]

On Friday, 11 May 2012 at 19:15:54 UTC, Mehrdad wrote:
Or e.g. C#'s "Any()" method tells you whether the collection is 
empty, whereas D's "any()" method takes in a predicate. I find 
C#'s *slightly* more intuitive.


I think, `Any` is one of the most unintuitive names out there.
The best association I have is mon.dll from windows.

Re: D dropped in favour of C# for PSP emulator

[Ary Manzana]

On 5/12/12 12:14 PM, Nick Sabalausky wrote:

"DUE FOR TOMORROW"?!?

That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!


Hilarious :-)

Re: D dropped in favour of C# for PSP emulator

[Manu]

On 11 May 2012 21:28, Mehrdad  wrote:

> Yes, I agree, but consider that D users should NOT have to work with
> pointers to do something so basic
>

I'd like to think this were true, but the fact that 'ref' barely works
makes this almost immediately false when trying to write any non-trivial
program.

Re: D dropped in favour of C# for PSP emulator

[Paulo Pinto]

Am 12.05.2012 08:53, schrieb SomeDude:

On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:


I do have to say that I find it somewhat funny that this is your set of
requirements for an IDEA and yet "integrated debugger" is in the "some
'nice
to have' features" section. Doesn't an IDE _have_ to have an integrated
debugger or it's only a code editor (since it lacks the whole
integrated part
of Integrated Development Environment).

- Jonathan M Davis



Indeed, and Timon forgot the best feature of IDEs for bytecode compilers
imho: they compile in the background, so that errors are detected while
you type. There is no annoying "write-correct" cycle as compile-time
errors are shown in real time. That's a *huge* productivity boost.
It's actually better than with interpreted or scripted languages,
because once you've finished writing code, it will run ! Basically, with
modern IDEs, the productivity with languages like Java/C# is comparable
to Python.

Background compiling shouldn't be too hard to implement for an editor, I
guess: run the compiler in background on the current module every other
second (or only when a set of simple syntaxic conditions like
parentheses/accolades matching are matched, conditions which can easily
be checked by the editor itself), and display the error messages in semi
real time on screen where they appear.


Even Eclipse and VS do this, to certain extent, for C and C++.

Nowadays, my use of VIM and Emacs is relegated to quick edit of 
configuration files and small scripts.


--
Paulo

Re: D dropped in favour of C# for PSP emulator

[Ali Çehreli]

On 05/12/2012 12:26 AM, SomeDude wrote:
> On Saturday, 12 May 2012 at 00:12:07 UTC, Timon Gehr wrote:
>> On 05/12/2012 01:47 AM, Ali Çehreli wrote:
>>> On 05/11/2012 02:45 PM, Timon Gehr wrote:
 On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
> I use 'in' all the time, and I never even think about it returning a
> pointer. I just do:
>
> if(foo in bar)
>
> And it just works. So I don't see a particularly big problem here.
>
>

 Try this:

 bool fun(){ return foo in bar; }
>>>
>>> Isn't that an inconsistency in the language then? Are pointer values
>>> implicitly convertible to bool or not?
>>>
>>> Ali
>>
>> if(condition) { ... }
>>
>> is equivalent to
>>
>> if(cast(bool)condition) { ... }
>>
>> i.e. this conversion is 'explicit'.
>
> I'm not sure what you're talking about, there is no implicit conversion
> to bool.
> dmd returns:
>
> bug.d(6): Error: cannot implicitly convert expression (foo in bar) of
> type int* to bool
>
> With the cast(bool), everything works fine.

Which example are you testing with?

// With dmd 2.059, this compiles:
void main()
{
int[int] aa;

if (42 in aa) {
}
}

// But this does not compile:
bool foo()
{
int[int] aa;

return 42 in aa;
}

Ali

--
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html