www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D dropped in favour of C# for PSP emulator

reply Paulo Pinto <pjmlp progtools.org> writes:
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
May 11 2012
next sibling parent reply =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 11-05-2012 19:39, Paulo Pinto wrote:
 The author of a D based PSP emulator just rewrote
 the emulator in C#, after being disappointed with D.

 https://github.com/soywiz/cspspemu

 The reasons are listed here,

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

 --
 Paulo

Complicated language structure? Long compilation times? wat. The language may be complicated if all you've ever done is C# or Java, but then you've barely been exposed to interesting language design at all IMHO. I can agree on it being harder to refactor things in D than in other languages, but this completely depends on how much CTFE/CT reflection magic you're using. Now, this being said, .NET is interesting for an emulator exactly because he can just throw CIL at the runtime and it will emit native code for him at runtime. This makes portability *extremely* easy, because the CIL he emits will run anywhere Mono and MS.NET can run. Doing a similar thing with LLVM is certainly possible, but much more tedious. -- - Alex
May 11 2012
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen 
wrote:
 Complicated language structure? Long compilation times?

 wat.

I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases... 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them. 3. Ranges aren't confusing, but USING them certainly is. Don't believe me? Consider: In C#, you say Array.BinarySearch(arr) to search an array. It's VERY straightforward. In D, it's VERY CONFUSING -- there *is* no way to do this directly! Which led me to ask this question: http://stackoverflow.com/questions/4622377 and the solution indeed was NOT something I would've found by myself without spending hours on it (which I already had partially done). 4. is(typeof(foo) U) is very confusing; it's completely unintuitive 5. For that matter, is() is completely unintuitive 6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitive 7. __traits() are confusing 8. there's more but I just can't think of them right now
May 11 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-05-2012 20:05, Mehrdad wrote:
 On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote:
 Complicated language structure? Long compilation times?

 wat.

I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases...

Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.
 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very
 confusing if you don't happen to suddenly "get" them.

I don't know about that. They seemed simple enough to me.
 3. Ranges aren't confusing, but USING them certainly is.

On the contrary, I actually think we're lacking proper documentation on what ranges are.
 Don't believe me?

 Consider: In C#, you say Array.BinarySearch(arr) to search an array.
 It's VERY straightforward.
 In D, it's VERY CONFUSING -- there *is* no way to do this directly!
 Which led me to ask this question:
 http://stackoverflow.com/questions/4622377
 and the solution indeed was NOT something I would've found by myself
 without spending hours on it (which I already had partially done).

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

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

Definitely. is() is an abomination.
 6. The 'in' operator returns a pointer (instead of a boolean). Which is
 fine, except that it's not what you'd expect in any languages other than
 C/C++. i.e. Non-intuitive

I've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).
 7. __traits() are confusing

I have the same stance WRT __traits as I do for is(). We need a better solution to metaprogramming. But again, most code really won't be doing all that much low-level metaprogramming.
 8. there's more but I just can't think of them right now

-- - Alex
May 11 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-05-2012 20:28, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
 On 11-05-2012 20:05, Mehrdad wrote:
 1. "templates": they seem to take in just about anything, and return
 just about anything. They can be pretty confusing, especially when
 youhave to worry about overloading vs. specialization vs.
 constraints, or types vs. aliases...

Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.

Not sure I agree. Templates are almost *impossible* to ignore when working with ranges.
 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very
 confusing if you don't happen to suddenly "get" them.


Me too, as a matter of fact. But they definitely aren't intuitive (just judge by the number of questions about them that pop up on StackOverflow or elsewhere...)

True, but I think what we lack is clear and concise documentation on them.
 3. Ranges aren't confusing, but USING them certainly is.>

on what ranges are.

Yeah probably.
 Consider: In C#, you say Array.BinarySearch(arr) to search an array.
 It's VERY straightforward.
 In D, it's VERY CONFUSING


Yeah, you got me there... But in practice it doesn't make a difference what the cause is, so much as what the effect is...

True. I'm just speaking from a purely language perspective. But D is a batteries-included language, so if the standard library has problems, you could arguably say D has problems as a whole...
 6. The 'in' operator returns a pointer (instead of a boolean). Which
 is fine, except that it's not what you'd expect in any languages
 other than C/C++. i.e. Non-intuitive

having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).

Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array!

I agree that the fact that it returns a *pointer* is probably not ideal. Maybe if D had proper pattern matching, it could have returned some kind of Option!T type or whatever...
 The mere fact that it uses a pointer makes it unintuitive to a large
 number of people coming from C#/Java/Python/etc.


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

That's the hope, but I keep on finding myself putting __traits(compiles, ...) on template conditions and such...

I've actually found that std.traits and if () constraints on declarations tend to work for most of my cases. But YMMV and all that. -- - Alex
May 11 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Mehrdad" <wfunction hotmail.com> wrote in message 
news:oksltzwvkdrrjidcnqnm forum.dlang.org...
 On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rnne Petersen wrote:
 On 11-05-2012 20:05, Mehrdad wrote:
 6. The 'in' operator returns a pointer (instead of a boolean). Which is 
 fine, except that it's not what you'd expect in any languages other than 
 C/C++. i.e. Non-intuitive

having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).

Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large number of people coming from C#/Java/Python/etc.

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.
May 11 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
 "Mehrdad"<wfunction hotmail.com>  wrote in message
 news:oksltzwvkdrrjidcnqnm forum.dlang.org...
 On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rnne Petersen wrote:
 On 11-05-2012 20:05, Mehrdad wrote:
 6. The 'in' operator returns a pointer (instead of a boolean). Which is
 fine, except that it's not what you'd expect in any languages other than
 C/C++. i.e. Non-intuitive

having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).

Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large number of people coming from C#/Java/Python/etc.

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; }
May 11 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 12-05-2012 00:05, Mehrdad wrote:
 On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
 Then you do

 bool fun() { return cast(bool)(foo in bar); }

cast() scares the **** out of me

bool fun() { return !!(foo in bar); } *flees* -- - Alex
May 11 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/11/2012 11:57 PM, Jonathan M Davis wrote:
 Then you do

 bool fun() { return cast(bool)(foo in bar); }

 It's not a big deal at all.

I didn't claim it was. Still, most issues people seem to have with D are trivial syntactic ones.
 It's just that if you expect in to return bool
 rather than a pointer, you're going to be surprised at what happens when you
 write a function like that rather than use it in an if condition.
 But since the documentation clearly states that it returns a pointer, it
shouldn't
 really surprise anyone

I was surprised when I read the relevant parts of the documentation.
 - unless they failed to read either the documentation
 or TDPL and go completely off of what they _think_ the code should mean without
 actually reading anything which would teach them the language (which is a bad
 idea anyway).

Well I fully agree with that last point (having read the entire language documentation before the first attempt to install the compiler), but 1. that is perhaps not how the 'average programmer' works. it seems to be the case that many programmers who fail to rtfm blame the tool. (bringing up fuzzy terms like 'intuitive' to defend their pov) 2. 'in' is certainly a very non-descriptive name for what it does. It is similar to eg. naming subtraction '<'. 3. why are we always discussing syntax on this NG?
May 11 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/12/2012 12:05 AM, Mehrdad wrote:
 On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
 Then you do

 bool fun() { return cast(bool)(foo in bar); }

cast() scares the **** out of me

cast(bool) is peaceful.
May 11 2012
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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 -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
May 11 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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'.
May 11 2012
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/11/2012 05:12 PM, 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'.

WAT. That's an "implicit explicit" conversion, which I have never known existed! :p Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
May 11 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
May 12 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Ali ehreli" <acehreli yahoo.com> wrote in message 
news:jok8f1$k1r$1 digitalmars.com...
 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?

Like Timon said, it's a feature of "if". I agree it's weird and confusing, though. At least I'm used to it :/
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 23:45:30 Timon Gehr wrote:
 On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
 "Mehrdad"<wfunction hotmail.com> wrote in message
 news:oksltzwvkdrrjidcnqnm forum.dlang.org...
 
 On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
 On 11-05-2012 20:05, Mehrdad wrote:
 6. The 'in' operator returns a pointer (instead of a boolean). Which is
 fine, except that it's not what you'd expect in any languages other
 than
 C/C++. i.e. Non-intuitive

I've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).

Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large number of people coming from C#/Java/Python/etc.

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; }

Then you do bool fun() { return cast(bool)(foo in bar); } It's not a big deal at all. It's just that if you expect in to return bool rather than a pointer, you're going to be surprised at what happens when you write a function like that rather than use it in an if condition. But since the documentation clearly states that it returns a pointer, it shouldn't really surprise anyone - unless they failed to read either the documentation or TDPL and go completely off of what they _think_ the code should mean without actually reading anything which would teach them the language (which is a bad idea anyway). - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
 Then you do

 bool fun() { return cast(bool)(foo in bar); }

cast() scares the **** out of me
May 11 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 22:11:21 UTC, Alex Rønne Petersen
wrote:
 On 12-05-2012 00:05, Mehrdad wrote:
 On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
 Then you do

 bool fun() { return cast(bool)(foo in bar); }

cast() scares the **** out of me

bool fun() { return !!(foo in bar); } *flees*

lol
May 11 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/12/2012 10:13 AM, Manu wrote:
 On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com
 <mailto:wfunction 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.
May 12 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, May 12, 2012 12:37:12 Manu wrote:
 On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 05/12/2012 10:13 AM, Manu wrote:
 On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com
 
 <mailto:wfunction 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, 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
May 12 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/12/2012 11:37 AM, Manu wrote:
 On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch
 <mailto:timon.gehr gmx.ch>> wrote:

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

         On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com
         <mailto:wfunction hotmail.com>
         <mailto:wfunction hotmail.com <mailto:wfunction 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*"
May 12 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/12 1:10 PM, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
 and the solution indeed was NOT something I would've found by myself
 without spending hours on it.

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

At the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search works with non-array ranges, but C#'s works only with arrays (which it assumes sorted only by convention). I think we copiously made the right call there. Andrei
May 11 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/12 1:33 PM, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:18:21 UTC, Andrei Alexandrescu wrote:
 At the same time it clarifies, documents, and statistically verifies
 that you pass a sorted range. Also, D's binary search works with
 non-array ranges, but C#'s works only with arrays (which it assumes
 sorted only by convention).

 I think we copiously made the right call there.

 Andrei

Right, right, I understand all of that... But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)

Totally agreed. Intuition is supported by having seen the same or a similar pattern before. In this case D takes an unusual approach, which I think is better than the established approach. I have added a reference (https://github.com/andralex/phobos/commit/650609be9b4146db3526b 0ccfca6776fed73b51) such that searching the page std.algorithm for "binary search" will lead to the correct reference. Andrei
May 11 2012
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/12/12 1:18 AM, Andrei Alexandrescu wrote:
 On 5/11/12 1:10 PM, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
 and the solution indeed was NOT something I would've found by myself
 without spending hours on it.

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

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

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...
May 11 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 12 2012
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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)
May 12 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
May 16 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 16 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 16-05-2012 17:28, Steven Schveighoffer wrote:
 On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath <panke tzi.de> 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 alex lycus.org http://lycus.org
May 16 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 16 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 16 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 17 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 17 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 17 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 17 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 18 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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. Andrei
May 18 2012
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
May 18 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 17 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-05-2012 20:34, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Speaking of which, 'in' on arrays......... *hint hint* -- - Alex
May 11 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-05-2012 22:29, Jonathan M Davis wrote:
 On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
 On 11-05-2012 20:34, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Speaking of which, 'in' on arrays......... *hint hint*

Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis

'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO. -- - Alex
May 11 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-05-2012 23:41, SomeDude wrote:
 On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen wrote:
 Except that it would break the generally expected algoritmic
 complexity of in,
 so it'll never happen ( O(n) for arrays, whereas the worst case that
 would be
 acceptable would be O(lg n) - e.g. what a binary tree could achieve).

 - Jonathan M Davis

'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.

I think this has been discussed several times already, and you still haven't convinced any of us.

Then you probably didn't read the replies to the other (sub-)thread about it. -- - Alex
May 11 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/11/2012 10:29 PM, Jonathan M Davis wrote:
 On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
 On 11-05-2012 20:34, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Speaking of which, 'in' on arrays......... *hint hint*

Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis

The main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... } And here the counter-argument cannot apply, because the operation is in O(1).
May 11 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/12 5:43 PM, Timon Gehr wrote:
 On 05/11/2012 10:29 PM, Jonathan M Davis wrote:
 On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
 On 11-05-2012 20:34, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Speaking of which, 'in' on arrays......... *hint hint*

Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis

The main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... } And here the counter-argument cannot apply, because the operation is in O(1).

Yes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time. Andrei
May 11 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/12 9:55 PM, jerro wrote:
 Yes, "in" for statically-sized arrays does make sense because the
 complexity if bound at compilation time.

 Andrei

But complexity is not the only problem with the proposed operator in for arrays. That operator does not represent the same operation as operator in for associative arrays.

That's a good argument, but then you may think of the array as a small set, which would have the same semantics. Andrei
May 11 2012
prev sibling next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Mehrdad" <wfunction hotmail.com> wrote in message 
news:ynstshvzpaiusjyyoipo 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.
May 11 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2012 12:40 PM, H. S. Teoh wrote:
 Yeah, one of the biggest problems with C++ template syntax is that it
 looks like an alien language. I remember going, "wait, you have to type
 *that* to achieve what can written as a simple loop in normal C++
 code?!"

 I couldn't tell you how delighted I was when I saw D's much cleaner and
 clearer template syntax. I mean, it looks just like normal, non-template
 code! Gee, what a concept!

Back when Andrei was writing TDPL, I suggested that he avoid using the word 'template' completely - to simply include type parameters as if they were completely natural. I think this was a very successful approach. I got the idea after listening to a friend of mine who taught remedial algebra to college students. She said that peoples' brains freeze up when they see "x" in an equation. If she wrote: x + 3 = 5 on the board and asked people to "solve for x", they would fail completely. But, if she wrote: ( ) + 3 = 5 and asked them to "fill in the circle with the number that makes it work", they all went "of course, it's 2!" C++ has produced a "gee, templates are hard" mentality, and consequently many people just shut down when they see the word "template".
May 11 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/12/12 3:24 AM, Walter Bright wrote:
     x + 3 = 5

 on the board and asked people to "solve for x", they would fail
 completely. But, if she wrote:

     ( ) + 3 = 5

 and asked them to "fill in the circle with the number that makes it
 work", they all went "of course, it's 2!"

When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x? In Spanish we say "hallar el valor de x" which means "find the value of x"... I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P
May 11 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2012 8:51 PM, Ary Manzana wrote:
 On 5/12/12 3:24 AM, Walter Bright wrote:
 x + 3 = 5

 on the board and asked people to "solve for x", they would fail
 completely. But, if she wrote:

 ( ) + 3 = 5

 and asked them to "fill in the circle with the number that makes it
 work", they all went "of course, it's 2!"

When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x? In Spanish we say "hallar el valor de x" which means "find the value of x"... I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P

It's normal English mathematical jargon.
May 11 2012
prev sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jokmnh$17fl$4 digitalmars.com...
 When I read "solve *for* x" I don't understand it. What do you mean "for 
 x"? Like doing a favor to x?

 In Spanish we say "hallar el valor de x" which means "find the value of 
 x"...

 I'm not a native English speaker so I don't know if "solve for x" sounds 
 natural if you haven't done ecuations before... but for me it doesn't. :-P

You're right, it doesn't. "Find the value of x" would be *much* better. But that's just for beginners. Once they learn how to "Find the value of x", then it should be trivial to learn that "Solve for x" is "Another way to say...the same thing you're already doing." Along similar lines, my 4th grade teacher used to assign homework and then say "But that's for tomorrow". So that evening I would do some *other* homework (if any) because that obviously *wasn't today's fucking homework*, right? Said *said* it was *tomorrow's*. Then the next day, she would bitch and moan that I didn't do the homework she had *said* was "for tomorrow". Her excuse: "Yea, it was 'Due for tomorrow'." "DUE FOR TOMORROW"?!? That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period! It's either "due {time and/or place}" or it's nothing! "Due" doesn't take any damn preposition, it takes an *object*! "Due for" is grammatical fucking gibberish! There's no such damn thing! So why would anyone ever say "for tomorrow" when they could just as easily say what they fucking mean: "due tomorrow". It *would* have been somewhat excusable except...She was a native English speaker! Stupid fucking bitch.
May 11 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
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 :-)
May 12 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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
May 12 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2012 12:02 PM, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
 On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
 template hasMember(T, string name)
 { enum hasMember = __traits(hasMember, T, name); }


It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc...

I tend to agree. I think this is better (I've never gotten around to implementing it): enum hasMember(T, string name) = __traits(hasMember, T, name); I.e. analogously to struct templates.
May 11 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Mehrdad" <wfunction hotmail.com> wrote in message 
news:hnottedhszpplpbqtvyx forum.dlang.org...
 On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:
 I tend to agree. I think this is better (I've never gotten around to 
 implementing it):

   enum hasMember(T, string name) = __traits(hasMember, T, name);

 I.e. analogously to struct templates.

Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)

While do I agree 100% that 'enum' is a horrid name (*much* worse than calling immutables "invariant" - that at least had *some* logic to it), that is a completely separate issue.
May 11 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2012 3:25 PM, SomeDude wrote:
 I believe it takes no less than a year of full time programming
 to become a proficient C++ programmer (by proficient, I mean a
 programmer who doesn't fall in all the traps that the language
 offers, and therefore spends more time coding than debugging).

Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!
May 11 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/17/12 5:44 PM, Philippe Sigaud wrote:
 On Thu, May 17, 2012 at 7:00 PM, Marco Leise<Marco.Leise gmx.de>  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
May 17 2012
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
    and the solution indeed was NOT something I would've found 
 by myself without spending hours on it.

Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...
May 11 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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??
May 17 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 May 2012 13:47:05 -0400, Alex R=C3=B8nne Petersen  =

<xtzgzorex gmail.com> wrote:

 On 11-05-2012 19:39, Paulo Pinto wrote:
 The author of a D based PSP emulator just rewrote
 the emulator in C#, after being disappointed with D.

 https://github.com/soywiz/cspspemu

 The reasons are listed here,

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

 --
 Paulo

Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D'= s = lightning fast compilation time goes out the window. It has improved = greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to = compile all the unit tests. It used to be well over a minute, till walt= er = changed a linear lookup to a hash lookup on the symbol table. There's a= n = outstanding issue which is similar still in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=3D4900 -Steve
May 11 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.wd5o86s3eav7ka steves-laptop...
On Fri, 11 May 2012 13:47:05 -0400, Alex Rnne Petersen
<xtzgzorex gmail.com> wrote:
 Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:

Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.
May 11 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"SomeDude" <lovelydear mailmetrash.com> wrote in message 
news:bgrwgspedjiajgoesxgq forum.dlang.org...
 I remember g++ taking dozens of minutes on a SINGLE compilation unit on 
 FreeFEM++, a very heavily templated project. Large C++ projects with lots 
 of templates can take several hours to compile. So one has to be very 
 careful with libraries like Boost on large projects, compilation times can 
 explode.

Yea, it's like compiling GCC. You may as well go buy your groceries, run a few other errands, and go out for dinner. And I'm not even eggagerating. It's rediculous. (Maybe it's gotten better since I last tried though, but even so, it'd still tale a LOOOONG fucking time) And even that's not even the worst. Mainstream videogames have been known to frequently take at least a full day. I'm not certain, but I seem to remember hearing about ones that took "days" - plural. And then that leads to "incredibuild", build farms, blah, blah, blah, it's all a big fucking mess. The longest I've ever had to wait for a D program to comple (DDMD) was about 1.5 to 2 minutes - and that was on a 32-bit single-core.
May 11 2012
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Well, in most the big C++ projects I was involved in the
past, a full clean build would take at least an hour.

Am 12.05.2012 00:34, schrieb SomeDude:
 On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wd5o86s3eav7ka steves-laptop...
 On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
 <xtzgzorex gmail.com> wrote:
 Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:

Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.

I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.

May 11 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
awkward is which, backwards read things makes posting top but, ass an be to 
Not.

"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:joku8g$1kd9$1 digitalmars.com...
 Well, in most the big C++ projects I was involved in the
 past, a full clean build would take at least an hour.

 Am 12.05.2012 00:34, schrieb SomeDude:
 On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wd5o86s3eav7ka steves-laptop...
 On Fri, 11 May 2012 13:47:05 -0400, Alex Rnne Petersen
 <xtzgzorex gmail.com> wrote:
 Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:

Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.

I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.


May 11 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 08:05:57PM +0200, Mehrdad wrote:
 On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rnne Petersen wrote:
Complicated language structure? Long compilation times?

wat.

I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases...

Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something. Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.
 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very
 confusing if you don't happen to suddenly "get" them.

Again, the problem is lack of proper introductory documentation for them. Actually, I find that to be a consistent problem with much of the current D docs. They appear to be written for people who already know what the thing is, and as such is very unhelpful to a newbie.
 3. Ranges aren't confusing, but USING them certainly is.
 
    Don't believe me?
 
    Consider: In C#, you say Array.BinarySearch(arr) to search an
 array.
    It's VERY straightforward.
    In D, it's VERY CONFUSING -- there *is* no way to do this
 directly!
    Which led me to ask this question:
    http://stackoverflow.com/questions/4622377
    and the solution indeed was NOT something I would've found by
 myself
    without spending hours on it (which I already had partially
 done).

Again, this is due to poor (or lack of) introductory docs. Really, things like Ali's excellent D book need to be put in a prominent place on dlang.org, rather than relegated to a secondary source. Most of the stuff on dlang.org is written as reference material rather than tutorial material. It does serve its purpose -- it's there for reference when you need to look something up. But it's very unhelpful for someone trying to get started with the language.
 4. is(typeof(foo) U) is very confusing; it's completely unintuitive
 
 5. For that matter, is() is completely unintuitive

is() syntax is a horrible mess. Walter has said that he'd like to redesign it eventually... but it's not going to happen in the near future because it's a breaking change.
 6. The 'in' operator returns a pointer (instead of a boolean). Which
 is fine, except that it's not what you'd expect in any languages
 other than C/C++. i.e. Non-intuitive

Actually, that is a WAT even for somebody coming from C/C++.
 7. __traits() are confusing

But they are advanced stuff that you generally don't need until you're familiar with the language. I don't see this as a problem. T -- Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
May 11 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.597.1336760569.24740.digitalmars-d puremagic.com...
 Templates are stencils for generating code. There's nothing confusing
 about that, unless you try to shoehorn them into a preconceived mental
 model of functions that take parameters and return something.

 Granted, proper tutorials need to be written and put in a prominent
 place so that newbies start on the right footing.

https://semitwist.com/articles/article/view/template-primer-in-d Written. It'd just need to be linked from somewhere, or copied somewhere.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen 
wrote:
 On 11-05-2012 20:05, Mehrdad wrote:
 1. "templates": they seem to take in just about anything, and 
 return just about anything. They can be pretty confusing, 
 especially when youhave to worry about overloading vs. 
 specialization vs. constraints, or types vs. aliases...

Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.

Not sure I agree. Templates are almost *impossible* to ignore when working with ranges.
 2. Tuples (I'm referring to both tuple() and TypeTuple()) are 
 very confusing if you don't happen to suddenly "get" them.


Me too, as a matter of fact. But they definitely aren't intuitive (just judge by the number of questions about them that pop up on StackOverflow or elsewhere...)
 3. Ranges aren't confusing, but USING them certainly is.>

documentation on what ranges are.

Yeah probably.
 Consider: In C#, you say Array.BinarySearch(arr) to search an 
 array.
 It's VERY straightforward.
 In D, it's VERY CONFUSING


Yeah, you got me there... But in practice it doesn't make a difference what the cause is, so much as what the effect is...
 6. The 'in' operator returns a pointer (instead of a boolean). 
 Which is fine, except that it's not what you'd expect in any 
 languages other than C/C++. i.e. Non-intuitive

from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).

Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large number of people coming from C#/Java/Python/etc.
 But again, most code really won't be doing all that much 
 low-level metaprogramming.

That's the hope, but I keep on finding myself putting __traits(compiles, ...) on template conditions and such...
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 18:18:21 UTC, Andrei Alexandrescu wrote:
 At the same time it clarifies, documents, and statistically 
 verifies that you pass a sorted range. Also, D's binary search 
 works with non-array ranges, but C#'s works only with arrays 
 (which it assumes sorted only by convention).

 I think we copiously made the right call there.

 Andrei

Right, right, I understand all of that... But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
 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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; where what's in the ... depends on the parameters you passed to the template. So for example, if T is say MyClass, and name is myfield, then the stencil stamps out: enum hasMember = __traits(hasMember, MyClass, myfield); Now, bad __traits syntax aside (and I do agree with you that __traits() could've had more intuitive syntax), this is just a piece of code that depends on some compile-time knowledge. So if MyClass has a field called myfield, then the final code produced is just: enum hasMember = true; Otherwise, the code produced is: enum hasMember = false; You could've typed out the final code yourself, and the effect is exactly the same. The only difference is that capturing the process of producing this code inside a template allows you to do generic programming, that is, instead of checking each class for a particular member in every instance, you define a template that, in effect, replicates this process for you. And once you have this automation, you can build upon it -- whence comes templates that call other templates, function signatures constraints, etc.. 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. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
May 11 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 Just a note: I believe I *had* seen SortedRange in the docs, 
 but I'd never realized there's something called assumeSorted() 
 that I was supposed to call... so I was searching up and down 
 for how to search an *arbitrary* container, not how to search 
 something which was already pre-sorted for me.
 (In retrospect, I probably should've just coded binary search 
 myself...)
 It's very counterintuitive to have to make a new object (or 
 struct) just to do binary search on an array...

Maybe the documentation changed since, but currently the documentation for SortedRange says: "To construct a SortedRange from a range r that is known to be already sorted, use assumeSorted described below." And there is assumeSorted in the example.
May 11 2012
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
 1. "templates": they seem to take in just about anything, and 
 return just about anything. They can be pretty confusing, 
 especially when you have to worry about overloading vs. 
 specialization vs. constraints, or types vs. aliases...

I really have to disagree on this. I programmed in C++ for awhile and templates were always a huge stumbling block for me. The syntax didn't sync up for me and they were extremely difficult to implement well, which made any generic programming I attempted feel half-hearted (IMO). When I started looking at D's templates, I was _afraid_ that it would be as much of a pain in the ass. After putting it off and shying away from it, I decided to dive in and discovered that they were significantly easier to work with ... and more importantly, it was nearly straightforward to implement them _well_. It's absolutely no problem specifying that data type with certain properties should use this function and everything else should use this other function. In C++, you have to learn complicated, arbitrary idioms such as SFINAE to get any serious work done at all ... and it looks like all of it was written in another language when you're done, making maintenance a nightmare. It's not surprising that entire C++ books are dedicated to teaching the absurd complexities of C++ templates. If anything, my experience with C++ templates hindered me.
 3. Ranges aren't confusing, but USING them certainly is.
    ...
    Consider: In C#, you say Array.BinarySearch(arr) to search 
 an array.

There's definitely not enough info on how to get stuff done with ranges. I knew about assumeSorted and the fact that std.algorithm.sort returns a sorted range, but only because I carefully combed through the libraries looking for stuff like that. That said, the D way is actually very well designed once you discover it. Like Andrei said, the code clarifies its intentions. Hilariously, this style also makes the code look more magical. You want to say something is unique and, thus, can be legitimately made immutable? assumeUnique. Oh, you want to have a memoized version of funct? memoize!funct. I leave my friends wondering how D knew how to do all this stuff just by being "told" to. Magic API, that's how.
May 11 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh quickfur.ath.cx> 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
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
 On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
 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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>

That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.
May 11 2012
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 11 May 2012 at 18:33:06 UTC, Mehrdad wrote:
 But just because the *reasons* are correct that doesn't mean 
 it's more intuitive.

 ("Intuitive", by definition, means that you have a good chance 
 of getting it right without needing to look it up. Binary 
 searching in D failed this miserably for me.)

You want a language that you can program in without ever looking at docs? How exactly would that work? o_O
May 11 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2012 1:20 PM, 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.

That is amusing. I've been writing a bunch of range/algorithm code myself lately, and I find it's a struggle because it is simply not how I think about code. I think in terms of C style loops, and solutions just pop out of my fingers on the keyboard. With ranges, I have to forcibly think in a different way, it's a lot like transitioning from walking to using a snowboard.
May 11 2012
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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
May 11 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
May 14 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 19:01:25 UTC, jerro wrote:
 Just a note: I believe I *had* seen SortedRange in the docs, 
 but I'd never realized there's something called assumeSorted() 
 that I was supposed to call... so I was searching up and down 
 for how to search an *arbitrary* container, not how to search 
 something which was already pre-sorted for me.
 (In retrospect, I probably should've just coded binary search 
 myself...)
 It's very counterintuitive to have to make a new object (or 
 struct) just to do binary search on an array...

Maybe the documentation changed since, but currently the documentation for SortedRange says: "To construct a SortedRange from a range r that is known to be already sorted, use assumeSorted described below." And there is assumeSorted in the example.

Yeah, either I missed, or I just didn't look at it, and skipped it entirely just by the header (I don't remember). The point was that it simply wasn't what/where I expected to be.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 19:03:56 UTC, Chris Cain wrote:
 On Friday, 11 May 2012 at 18:33:06 UTC, Mehrdad wrote:
 But just because the *reasons* are correct that doesn't mean 
 it's more intuitive.

 ("Intuitive", by definition, means that you have a good chance 
 of getting it right without needing to look it up. Binary 
 searching in D failed this miserably for me.)

You want a language that you can program in without ever looking at docs? How exactly would that work? o_O

lol I think you're exaggerating my point. :P I said a "reasonable chance". For example, in std.algorithm, "joiner" is NOT what I expected the method to be called -- I expected "join". (Again, I *do* understand why it's called that.) Or in std.range, no one in a million years expects to see a method called "moveFront()". You're not "moving" a range... What we call "moveFront()" should, IMO, have been called "popFront()". Or maybe just "next()". But of course that was taken, so there wasn't a choice. Still, not intuitive. Heck, even C# has a more intuitive name for setDifference(): it's called "Except". (Like, items.except(otherItems).) 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. D's std.algorithm.completeSort() definitely does NOT have an intuitive name. etc. (But, actually, what you said WOULD work if you had a good enough IDE, like Visual Studio, that gave you the descriptions right there, instantly. That wasn't my point though.)
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 19:01:26 UTC, Chris Cain wrote:
 I really have to disagree on this. I programmed in C++ for 
 awhile and templates were always a huge stumbling block for me.
 [...]

Yes, D's templates are a great improvement over C++'s. I completely agree. Just pointing out why there are still a few things confusing about them, though.
 Hilariously, this style also makes the code look more magical.

Yup, that's what attracted me to D when I learned about it. :)
May 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 09:02:52PM +0200, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>

That's not how you see it when you're learning though.

Well, it *should* be seen that way. The fact that it isn't means that the user didn't get a proper introduction to the concept.
 It's more like, I can imagine someone asking these:
 
 1. Why the heck do I see "hasMember" twice?

It should be more like, "there's a template keyword, I wonder what it means -- <look up docs, which has a proper intro to the concept> -- ohhh so that's what it means. The fact that this first step failed means the documentation has failed.
 2. What does this have to do with enums?
 3. Where is anything getting "returned"???

Return? Why should templates return anything?
 4. So you mean templates are THINGS?? I thought you needed a
 template SOMETHING, like a template struct, template function,
 etc...

A stencil is a thing. What you stamp out depends on what's in it.
 5. What the heck is TypeTuple!()? Where's the blueprint?

Now, TypeTuples are a completely different kettle o' fish. They need their own proper introduction. :-) Trying to understand TypeTuple before you understand templates is like trying to run before you can stand. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
May 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 09:01:25PM +0200, Chris Cain wrote:
[...]
 I really have to disagree on this. I programmed in C++ for awhile
 and templates were always a huge stumbling block for me. The syntax
 didn't sync up for me and they were extremely difficult to implement
 well, which made any generic programming I attempted feel
 half-hearted (IMO).

Yeah, I remember when I first read about template metaprogramming and expression templates and stuff, and I was all riled up about finally being able to write matrix expressions in an intuitive way and still have peak performance... until I actually sat down to code the thing. Let's just say I didn't get very far before I got completely lost in deep jungle that is C++ template syntax.
 When I started looking at D's templates, I was _afraid_ that it
 would be as much of a pain in the ass. After putting it off and
 shying away from it, I decided to dive in and discovered that they
 were significantly easier to work with ... and more importantly, it
 was nearly straightforward to implement them _well_. It's absolutely
 no problem specifying that data type with certain properties should
 use this function and everything else should use this other
 function. In C++, you have to learn complicated, arbitrary idioms
 such as SFINAE to get any serious work done at all ... and it looks
 like all of it was written in another language when you're done,
 making maintenance a nightmare.

Yeah, one of the biggest problems with C++ template syntax is that it looks like an alien language. I remember going, "wait, you have to type *that* to achieve what can written as a simple loop in normal C++ code?!" I couldn't tell you how delighted I was when I saw D's much cleaner and clearer template syntax. I mean, it looks just like normal, non-template code! Gee, what a concept!
 It's not surprising that entire C++ books are dedicated to teaching
 the absurd complexities of C++ templates. If anything, my experience
 with C++ templates hindered me.

Or the absurdity of C++ itself. What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions. [...]
 There's definitely not enough info on how to get stuff done with
 ranges. I knew about assumeSorted and the fact that std.algorithm.sort
 returns a sorted range, but only because I carefully combed through
 the libraries looking for stuff like that.

Again, helpful tutorials like Ali's book really need to be on the forefront of D. Newbies *need* to read that stuff before they get dunked into the deep end of the pool that is the current dlang.org docs.
 That said, the D way is actually very well designed once you
 discover it. Like Andrei said, the code clarifies its intentions.
 
 Hilariously, this style also makes the code look more magical. You
 want to say something is unique and, thus, can be legitimately made
 immutable? assumeUnique. Oh, you want to have a memoized version of
 funct? memoize!funct. I leave my friends wondering how D knew how to
 do all this stuff just by being "told" to. Magic API, that's how.

+1. Sufficiently advanced programming language syntax is indistinguishible from magic. ;-) T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
May 11 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 11 May 2012 at 19:39:55 UTC, H. S. Teoh wrote:
 On Fri, May 11, 2012 at 09:01:25PM +0200, Chris Cain wrote:
 There's definitely not enough info on how to get stuff done  
 with ranges. I knew about assumeSorted and the fact that  
 std.algorithm.sort returns a sorted range, but only because I 
 carefully combed  through the libraries looking for stuff like 
 that.

Again, helpful tutorials like Ali's book really need to be on the forefront of D. Newbies *need* to read that stuff before they get dunked into the deep end of the pool that is the current dlang.org docs.

I remember reading from that book a bit on the ranges, and it all made wonderful sense when I did. That was something like a year ago, now I can't remember anything on it except it was good. Not having a good link to it does hinder your work quite a bit.
 That said, the D way is actually very well designed once you 
 discover it. Like Andrei said, the code clarifies its  
 intentions.
 
 Hilariously, this style also makes the code look more magical. 
  You want to say something is unique and, thus, can be 
 legitimately  made immutable? assumeUnique. Oh, you want to 
 have a memoized  version of funct? memoize!funct. I leave my 
 friends wondering how D knew  how to do all this stuff just by 
 being "told" to. Magic API, that's  how.

+1. Sufficiently advanced programming language syntax is indistinguishible from magic. ;-)

http://freefall.purrsia.com/ff300/fv00255.htm Safe to say documentation needs to be updated and added to. Here's a catch-22 we have here. We need those that know the system and language and compiler to work on it and give us a working set of tools, but we need those people to update and make the documentation for everyone that wants to use it or it will be a dead language. Hmmm... Unfortunately I don't have sufficient knowledge of all of D to make documentation for updated and newer changes to the language. :(
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 20:24:40 UTC, Walter Bright wrote:
 C++ has produced a "gee, templates are hard" mentality, and 
 consequently many people just shut down when they see the word 
 "template".

Same thing happens to me when I see a transistor symbol. :P
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
 On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
 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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>

That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.

I think TypeTuples originate from Andrei's famous book "Modern C++ Design"(chapter 3: Typelists), so it's essentially known by C++ programmers. Indeed, it does need some introduction if you haven't been exposed to these before.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 21:40:44 UTC, Andrei Alexandrescu wrote:
 Totally agreed. Intuition is supported by having seen the same 
 or a similar pattern before. In this case D takes an unusual 
 approach, which I think is better than the established approach.

 I have added a reference 
 (https://github.com/andralex/phobos/commit/650609be9b4146db3526b
0ccfca6776fed73b51) 
 such that searching the page std.algorithm for "binary search" 
 will lead to the correct reference.


 Andrei

Awesome!
May 11 2012
prev sibling next sibling parent "akaz" <nemo utopia.com> writes:
 What started out as C with classes started acquiring this 
 feature and
 that feature until the whole thing is just a haphazard heap of
 misfitting self-contradictory pieces, which requires an 
 enormous amount
 of essentially-arbitrary rules just to clarify something as 
 simple as,
 for example, automatic type conversions.

Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated. Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup. Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once? My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today. C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added later, *after* the naguage got assimilated. C# too ("hey! C++ made *simpler*!"). Then it was C#2, 3, 4 etc. True, C++ grew up a complicated beast, but *gradually*. At the beginning, it was not. D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
 On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
 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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>

That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.

BTW, don't forget to have a look at the articles on the left: http://dlang.org/tuple.html
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 11 May 2012 at 21:55:37 UTC, akaz wrote:
 What started out as C with classes started acquiring this 
 feature and
 that feature until the whole thing is just a haphazard heap of
 misfitting self-contradictory pieces, which requires an 
 enormous amount
 of essentially-arbitrary rules just to clarify something as 
 simple as,
 for example, automatic type conversions.

Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated. Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup. Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once? My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today. C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added later, *after* the naguage got assimilated. C# too ("hey! C++ made *simpler*!"). Then it was C#2, 3, 4 etc. True, C++ grew up a complicated beast, but *gradually*. At the beginning, it was not. D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.

There is no arguing that D is a big and complex language. If it wasn't, there wouldn't be huge discussions here about interactions between features. It's complex because there is so many new concepts to assimilate for newcomers from other languages. The former Java programmers will have to face advanced concepts coming from C++, the former C++ programmers will learn to master concepts coming from Python and functional languages, and former Python programmers will have to face lots of hurdles associated to static languages. So basically, everyone has a different learning curve. I believe it takes no less than a year of full time programming to become a proficient C++ programmer (by proficient, I mean a programmer who doesn't fall in all the traps that the language offers, and therefore spends more time coding than debugging). I can't tell for D, I believe D is a net gain for C++ programmers, but still a big investment.
May 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 05:27:11PM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.597.1336760569.24740.digitalmars-d puremagic.com...
 Templates are stencils for generating code. There's nothing
 confusing about that, unless you try to shoehorn them into a
 preconceived mental model of functions that take parameters and
 return something.

 Granted, proper tutorials need to be written and put in a prominent
 place so that newbies start on the right footing.

https://semitwist.com/articles/article/view/template-primer-in-d Written. It'd just need to be linked from somewhere, or copied somewhere.

Ah, I remember that. Yes, we do need to link to this from somewhere prominent, so that newbies have a higher chance of reading it *before* they decide to dive off the 3-storey diving board into std.algorithm. T -- It's amazing how careful choice of punctuation can leave you hanging:
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wd5o86s3eav7ka steves-laptop...
 On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
 <xtzgzorex gmail.com> wrote:
 Complicated language structure? Long compilation times?

I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:

Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.

I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.
May 11 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/11/12, Walter Bright <newshound2 digitalmars.com> wrote:
 If she wrote:
     x + 3 = 5
 on the board and asked people to "solve for x", they would fail completely.

Well that's funny, here in europe we've learned to use 'x' since junior school so that's more intuitive for us. :)
May 11 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 12/05/12 01:01, Andrej Mitrovic wrote:
 Well that's funny, here in europe we've learned to use 'x' since
 junior school so that's more intuitive for us. :)

Dangerous to speak for a whole group, I've met plenty of Europeans terrified of mathematical notation. Some people -- maybe even most people -- automatically freeze up when confronted with a notation that they associate with difficult stuff, or stuff that was too hard (or humiliating) for them at some point in the past. Maths-phobia is very common in a lot of people who are able to solve the exact same problems if they're not presented in "maths-y" clothing. By contrast look at how some mathematically gifted people freeze up in social situations! I saw a violin-playing friend in school freeze up once when she was asked to sightread a short piece with chords in it. She was adamant that she wasn't skilled enough to play chords properly. Yet a few seconds' calm examination of the notes on the page would have revealed that all she had to do was draw the bow across a pair of open strings, which is something that just about every violinist, even a beginner, does every day without even thinking about it. She couldn't see it, because "Oh my God!! Chords!!" got in the way of even trying to consider the problem.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:
 I tend to agree. I think this is better (I've never gotten 
 around to implementing it):

   enum hasMember(T, string name) = __traits(hasMember, T, name);

 I.e. analogously to struct templates.

Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 12 May 2012 at 04:19:57 UTC, Walter Bright wrote:
 On 5/11/2012 3:25 PM, SomeDude wrote:
 I believe it takes no less than a year of full time programming
 to become a proficient C++ programmer (by proficient, I mean a
 programmer who doesn't fall in all the traps that the language
 offers, and therefore spends more time coding than debugging).

Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!

Yeah, I didn't want to start a discussion on how much time it takes to make a good C++ programmer because I guess everyone has a different idea on this (definition of a "good" programmer, etc), but I agree. :)
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 12 May 2012 at 05:16:33 UTC, Nick Sabalausky wrote:
 Stupid fucking bitch.

Wow, you seem to love her. :D Cool down, man, it's over. :)
May 12 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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.
May 12 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074d7fe1e8c9e04bfd26f7d
Content-Type: text/plain; charset=UTF-8

On 11 May 2012 21:28, Mehrdad <wfunction 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. --20cf3074d7fe1e8c9e04bfd26f7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 11 May 2012 21:28, Mehrdad <span dir=3D"ltr">= &lt;<a href=3D"mailto:wfunction hotmail.com" target=3D"_blank">wfunction ho= tmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Yes, I agree, but consider that D users should NOT have t= o work with pointers to do something so basic</div></blockquote><div><br></= div><div>I&#39;d like to think this were true, but the fact that &#39;ref&#= 39; barely works makes this almost immediately false when trying to write a= ny non-trivial program.</div> </div> --20cf3074d7fe1e8c9e04bfd26f7d--
May 12 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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 aaaamon.dll from windows.
May 12 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300fb0c7f8048404bfd398b7
Content-Type: text/plain; charset=UTF-8

On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch> wrote:

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

 On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com
 <mailto:wfunction 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, 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. --20cf300fb0c7f8048404bfd398b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 12 May 2012 12:26, Timon Gehr <span dir=3D"lt= r">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.gehr gm= x.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 05/12/2012 10:13 AM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 11 May 2012 21:28, Mehrdad &lt;<a href=3D"mailto:wfunction hotmail.com" = target=3D"_blank">wfunction hotmail.com</a><br></div><div><div class=3D"h5"=

tion hotmail.com</a>&gt;<u></u>&gt; wrote:<br> <br> =C2=A0 =C2=A0Yes, I agree, but consider that D users should NOT have to wo= rk with<br> =C2=A0 =C2=A0pointers to do something so basic<br> <br> <br> I&#39;d like to think this were true, but the fact that &#39;ref&#39; barel= y works<br> makes this almost immediately false when trying to write any non-trivial<br=

</div></div></blockquote> <br> It depends on the coding style.<br> </blockquote></div><br><div>If the distinction is whether one likes to have= data structures in their code or not, I reckon there&#39;s a reasonably la= rge user base in the former? :)</div><div>Once you use &#39;struct&#39; you= can&#39;t avoid pointers, given that ref just doesn&#39;t work in many (pe= rhaps most) situations.</div> --20cf300fb0c7f8048404bfd398b7--
May 12 2012
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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 
 <hsteoh quickfur.ath.cx> 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!
May 12 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 12 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 13 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 11 May 2012 22:17:07 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 "Mehrdad" <wfunction hotmail.com> wrote in message
 news:ynstshvzpaiusjyyoipo 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: ??!??!
May 13 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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?
May 14 2012
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander  
<peter.alexander.au gmail.com> 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.
May 14 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 18 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 18 2012
prev sibling parent Brad Anderson <eco gnuk.net> writes:
--bcaec552424245379704c057e99c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 18, 2012 at 5:06 PM, H. S. Teoh <hsteoh quickfur.ath.cx> 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. --bcaec552424245379704c057e99c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 18, 2012 at 5:06 PM, H. S. Teoh <span dir=3D"ltr">&lt;<a href= =3D"mailto:hsteoh quickfur.ath.cx" target=3D"_blank">hsteoh quickfur.ath.cx= </a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote:<br> [...]<br> <div class=3D"im">&gt; Also, I think std.algorithm could use a mini-FAQ. = =A0std.range is long<br> &gt; overdue for an entire article explaining ranges but that&#39;s a well<= br> &gt; known omission that pretty much everyone agrees on.<br> <br> </div>What about the latest prerelease docs for std.range? I did clean up a= <br> lot of stuff there and tried to explain the basic idea of what a range<br> is, and included a link to Andrei&#39;s article that describes the idea of<= br> ranges in-depth.<br> <br> Or is that still not good enough? How can we improve the docs further?<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> T<br> <br> --<br> Computers aren&#39;t intelligent; they only think they are.<br> </font></span></blockquote></div><br><div>I like it. =A0Looks like it&#39;s= already up on the website and was included with 2.059 unless there are fur= ther changes beyond what&#39;s on=A0<a href=3D"http://dlang.org/phobos/std_= range.html">http://dlang.org/phobos/std_range.html</a></div> <div><br></div><div>It&#39;s very clean now and the link to Andrei&#39;s ar= ticle definitely helps. Also, good thinking linking to the print version in= stead of the difficult to read and confusing non-print version. People I li= nk to Andrei&#39;s articles on InformIT sometimes don&#39;t realize there i= s more than one page.</div> <div><br></div><div>It&#39;s a great improvement to the documentation. I do= agree with Jonathan, though, that a official article on <a href=3D"http://= dlang.org">dlang.org</a> like Steven&#39;s arrays article would be a nice a= ddition but what you&#39;ve done helps enormously.</div> --bcaec552424245379704c057e99c--
May 18 2012
prev sibling next sibling parent "Kirill" <bribeme gmail.com> writes:
On Monday, 14 May 2012 at 10:31:47 UTC, Simen Kjaeraas wrote:
 On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander 
 <peter.alexander.au gmail.com> 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.
May 15 2012
prev sibling next sibling parent "Anders =?UTF-8?B?U2rDtmdyZW4i?= <anders sjogren.info> writes:
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.
May 16 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 16 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.)
May 16 2012
prev sibling next sibling parent "Tobias Pankrath" <panke tzi.de> writes:
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?
May 16 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath <panke tzi.de> 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
May 16 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 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.
May 16 2012
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
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
May 16 2012
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
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
May 17 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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*.
May 17 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 17 May 2012 09:50:44 +0100, Lars T. Kyllingstad  
<public kyllingen.net> 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?


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/
May 17 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 17 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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).
May 17 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, May 17, 2012 at 7:00 PM, Marco Leise <Marco.Leise gmx.de> 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.
May 17 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Fri, May 18, 2012 at 3:01 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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.
May 18 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
May 18 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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?
May 18 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d042f9cd828828f04c057050a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 18, 2012 at 3:36 PM, Mehrdad <wfunction hotmail.com> 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. --f46d042f9cd828828f04c057050a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 18, 2012 at 3:36 PM, Mehrdad <span dir=3D"ltr">&lt;<a href=3D"m= ailto:wfunction hotmail.com" target=3D"_blank">wfunction hotmail.com</a>&gt= ;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "> <div class=3D"im">On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandres= cu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I guess it is now :o).<br> <br> Andrei<br> </blockquote> <br></div> lol<br> <br> <br> One more thing that&#39;s also annoying about this is that it&#39;s not in = std.algorithms, but std.range...<br> <br> Asn&#39;t binary search an algorithm?<br> </blockquote></div><br><div>I fairly often get confused about whether to lo= ok in std.range or std.algorithm for something. =A0filter is in algorithm b= ut recurrence is in range, for instance. I can see why but I still sometime= s go to the wrong module&#39;s documentation to look something up. There sh= ould probably be a lot more cross referencing between the two in the docume= ntation. =A0Also, I think std.algorithm could use a mini-FAQ. =A0std.range = is long overdue for an entire article explaining ranges but that&#39;s a we= ll known omission that pretty much everyone agrees on.</div> --f46d042f9cd828828f04c057050a--
May 18 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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).
May 18 2012
prev sibling parent Jerry <jlquinn optonline.net> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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
May 28 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 11:22:13 H. S. Teoh wrote:
 6. The 'in' operator returns a pointer (instead of a boolean). Which
 is fine, except that it's not what you'd expect in any languages
 other than C/C++. i.e. Non-intuitive

Actually, that is a WAT even for somebody coming from C/C++.

Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 21:15:53 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.

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
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 20:34:07 Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Sure, what your used to has a huge effect on what you expect. But I've done very little with python whereas I've done a lot with C++, so my expectations are strongly influenced by C++ but aren't influenced by python at all. I didn't even know that python _had_ an in operator. But when you're dealing with people from a variety of backgrounds, you're invariably going to end up making choices that fit what one set of people expects but confounds another. - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
 On 11-05-2012 20:34, Mehrdad wrote:
 On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
 Actually, that is a WAT even for somebody coming from C/C++.

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

Again, try to see it from the perspective of a Python user, not a C++ user.

Speaking of which, 'in' on arrays......... *hint hint*

Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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?
May 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen 
wrote:
 Except that it would break the generally expected algoritmic 
 complexity of in,
 so it'll never happen ( O(n) for arrays, whereas the worst 
 case that would be
 acceptable would be O(lg n) - e.g. what a binary tree could 
 achieve).

 - Jonathan M Davis

'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.

I think this has been discussed several times already, and you still haven't convinced any of us.
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 22:40:08 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?

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. - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 20:38:41 Mehrdad wrote:
 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 template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Templates are a code-generation tool. They're "templates" for code. I really think that the majority of programmers don't quite get that, even when they've programmed in C++ quite a bit. Templates are frequently used for stuff like making it so that you can construct a container with a different element type than another container of the same type or letting functions take a variety of argument types. Actually actively trying to _generate_ code with them is getting into template metaprogramming land, which is very ugly in C++ and therefore very foreign to many (most?) programmers. D makes it _much_ easier and _much_ more sane, so we end up doing it all the time, and it's definitely something that many programmers coming to D are going to have to learn as opposed to it being completely intuitive. Much of it really isn't all that complicated or difficult IMHO, but it's definitely new and different for many programmers. - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 22:01:33 Era Scarecrow wrote:
 I remember reading from that book a bit on the ranges, and it
 all made wonderful sense when I did. That was something like a
 year ago, now I can't remember anything on it except it was good.
 Not having a good link to it does hinder your work quite a bit.

http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
May 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, May 12, 2012 at 12:43:00AM +0200, Timon Gehr wrote:
 On 05/11/2012 10:29 PM, Jonathan M Davis wrote:

Except that it would break the generally expected algoritmic
complexity of in, so it'll never happen ( O(n) for arrays, whereas
the worst case that would be acceptable would be O(lg n) - e.g. what
a binary tree could achieve).

- Jonathan M Davis

The main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... }

I always use this idiom: if ("abcd".canFind(foo)) { ... } T -- It only takes one twig to burn down a forest.
May 11 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/12/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 I always use this idiom:

 	if ("abcd".canFind(foo)) { ... }

As do I. Generally when I end up repeating myself all the time I write a helper function.. or if it's something more complicated than that - a template. Anyway hasn't this thread gone completely off tracks? Maybe Carlos (pspemu author) should try and elaborate exactly which issues he's faced, if he's reading this thread. You can't improve language/tools unless you know what's wrong with them. More real-world feedback about D would be great methinks.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.)
May 11 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
May 11 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 May 2012 at 00:00:20 UTC, Timon Gehr wrote:
 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.

My work project takes about 8 seconds to compile and link in my normal build if there's RAM available, and can be much longer if there isn't. Since the compile takes upwards of 512 MB peak, having enough memory for the fast build doesn't happen many times. The build also takes well over a full minute if I use -O. The emulator might be using -O and getting brutally slow, or being run on a box without a billion terabytes of RAM. ...or perhaps I just think ~10 second build times are slow because I've been spoiled by all the other D I do. lol
May 11 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.

May 11 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Timon Gehr" <timon.gehr gmx.ch> 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!". In fact, I'd put "responsive" at the top of the "essential" list.
May 11 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/12/2012 08:04 AM, Nick Sabalausky wrote:
 "Timon Gehr"<timon.gehr gmx.ch>  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'.
May 12 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, May 12, 2012 02:00:19 Timon Gehr wrote:
 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.

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
May 11 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
May 12 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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 

May 12 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"SomeDude" <lovelydear mailmetrash.com> wrote in message 
news:icvpcsajlyvsubowpqxo 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.
May 12 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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.
May 11 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 12 May 2012 at 06:53:34 UTC, SomeDude wrote:

 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.

Perhaps what could make that better is not only compiling as you type, but if you have unittests already written it will run and test against those giving you feedback instantly on what parts fail.
May 12 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 12 May 2012 08:05:26 +0200, Paulo Pinto <pjmlp progtools.org>  =

wrote:

=CB=99=CA=87sod-do=CA=87 =CA=87ou op =C7=9Ds=C9=90=C7=9Dl=D4=80
=CB=99u=CA=8Dop-=C7=9Dp=C4=B1sdn s=C4=B1 =CA=87sod =C9=B9no=CA=8E =C7=9D=
=CA=9E=C4=B1l s=C9=AF=C7=9D=C7=9Ds =CA=87=C4=B1 =CA=87nq 'no=CA=8E =C9=AF=
=C9=B9=C9=90l=C9=90 o=CA=87 =CA=87oN

 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 (extrem=


 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 ...
 =3D> permanent, extremely annoying configuration change
 =3D> no way to tell what happened
 =3D> 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=


 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 simp=


 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 =


 comment on this.


May 13 2012
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
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
May 18 2012
next sibling parent =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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

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 Rnne Petersen alex lycus.org http://lycus.org
May 18 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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

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?
May 20 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
May 20 2012
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
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
May 30 2012
parent =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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 Rnne Petersen alex lycus.org http://lycus.org
May 30 2012
prev sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
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
May 30 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.
May 18 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
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.
May 18 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
May 19 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023543a2b3aa49b7104c069b35a
Content-Type: text/plain; charset=UTF-8

On 18 May 2012 19:59, Bruno Medeiros <brunodomedeiros+dng gmail.com> 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. --0023543a2b3aa49b7104c069b35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 18 May 2012 19:59, Bruno Medeiros <span dir= =3D"ltr">&lt;<a href=3D"mailto:brunodomedeiros+dng gmail.com" target=3D"_bl= ank">brunodomedeiros+dng gmail.com</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> <div class=3D"im">On 12/05/2012 01:00, Timon Gehr wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> some essential properties:<br> - starts up instantaneously<br> </blockquote></div> ....<div class=3D"im"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> some &#39;nice to have&#39; properties:<br> - code analysis based code completion<br> </blockquote></div> &gt; - integrated debugger<br> <br> So just starting up the IDE is more important than actually writing code or= fixing bugs?...<br> <br> Seriously, I&#39;m never going to understand you &quot;editor&quot; people.= .</blockquote><div></div></div><br><div>No, writing code and fixing bugs is= more important than sitting around and operating your computer.</div> <div>I can hit F7 or F5 way faster than I can type a full line of some comm= and on the shell. I can tap tab and instantly complete typing the crap I wa= ste 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 funct= ion appear INSTANTLY much faster than I can swap out and refer to some refe= rence 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 opera= te GDB.</div> <div>I will seriously never understand anyone who will try and honestly say= typing shit on a command line, feeding commands to GDB manually, and looki= ng up references in some external manual can possibly be faster... under AN= Y circumstances... ever.</div> --0023543a2b3aa49b7104c069b35a--
May 19 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 19 May 2012 at 20:42:13 UTC, Manu wrote:
 On 18 May 2012 19:59, Bruno Medeiros 
 <brunodomedeiros+dng gmail.com> 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.
May 19 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c76904e25a74a04c07c375c
Content-Type: text/plain; charset=UTF-8

On 20 May 2012 17:19, Timon Gehr <timon.gehr gmx.ch> 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

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

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

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. --00248c76904e25a74a04c07c375c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 20 May 2012 17:19, Timon Gehr <span dir=3D"lt= r">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.gehr gm= x.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 05/18/2012 06:59 PM, Bruno Medeiros wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 12/05/2012 01:00, Timon Gehr wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> some essential properties:<br> - starts up instantaneously<br> </blockquote> ....<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> some &#39;nice to have&#39; properties:<br> - code analysis based code completion<br> </blockquote> =C2=A0&gt; - integrated debugger<br> <br> So just starting up the IDE is more important than actually writing code<br=

<br> </blockquote> <br></div> No, you misunderstand.<br> <br> - Time spent starting up the IDE is lost time that could be spent doing som= ething productive instead. Hardware is fast. There is simply no excuse for = poor start up times/poor responsiveness.<br> <br> - The current IDEs have poor support for editing and navigating text. Furth= ermore, &#39;pattern recognition based code completion&#39; was on my list = as well.<br> <br> - I am more efficient at bug-chasing by sending relevant data to stdout ins= tead 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 trivi= al regressions and/or caught immediately by reasonably good assertions. YMM= V.<br> <br> - I concur that when faced with a new code base, or just poorly written cod= e 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?<div class=3D"im"> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Seriously, I&#39;m never going to understand you &quot;editor&quot; people.= .<br> <br> </blockquote> <br></div> I do not see how this is relevant. Is your misunderstanding of the post del= iberate?<br> </blockquote></div><br><div>It&#39;s also worth noting that this guy droppe= d D for C#. That&#39;s a pretty clear indication the environment was import= ant to him.</div> --00248c76904e25a74a04c07c375c--
May 20 2012
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Sun, 20 May 2012 20:43:15 +0100, Timon Gehr <timon.gehr gmx.ch> 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/
May 21 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 Yes, "in" for statically-sized arrays does make sense because 
 the complexity if bound at compilation time.

 Andrei

But complexity is not the only problem with the proposed operator in for arrays. That operator does not represent the same operation as operator in for associative arrays. Looking up an element based on its key is different from looking it up based on its value. The following would be true for the proposed operator in for arrays: !(a in b) || *(a in b) == a And the following is true for operator in for associative arrays: !(a in b) || *(a in b) == b[a] The same operator should not be used for fundamentally different operations. I don't think using operator in to look up array elements based on their value is any better than using left shift operator to write to streams or using plus to concatenate strings. If operator in worked on arrays, it should actually take an index as the left operand and return a pointer to the element at that index if the index was less than array length and null otherwise. But that wouldn't be very useful.
May 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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 <wfunction hotmail.com
 
 <mailto:wfunction 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. - Jonathan M Davis
May 12 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dc10c6d37e04bfd3f6e6
Content-Type: text/plain; charset=UTF-8

On 12 May 2012 12:37, Jonathan M Davis <jmdavisProg gmx.com> 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 <wfunction hotmail.com

 <mailto:wfunction hotmail.com>> wrote:
     Yes, I agree, but consider that D users should NOT have to work


     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


 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/cnwpmhihmckpjhlaszzy 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... --20cf3005dc10c6d37e04bfd3f6e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 12 May 2012 12:37, Jonathan M Davis <span dir= =3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdav= isProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Saturday, May 12, 2012 11:26:37 = Timon Gehr wrote:<br> &gt; On 05/12/2012 10:13 AM, Manu wrote:<br> &gt; &gt; On 11 May 2012 21:28, Mehrdad &lt;<a href=3D"mailto:wfunction hot= mail.com">wfunction hotmail.com</a><br> &gt; &gt;<br> &gt; &gt; &lt;mailto:<a href=3D"mailto:wfunction hotmail.com">wfunction hot= mail.com</a>&gt;&gt; wrote:<br> &gt; &gt; =C2=A0 =C2=A0 Yes, I agree, but consider that D users should NOT = have to work with<br> &gt; &gt; =C2=A0 =C2=A0 pointers to do something so basic<br> &gt; &gt;<br> &gt; &gt; I&#39;d like to think this were true, but the fact that &#39;ref&= #39; barely works<br> &gt; &gt; makes this almost immediately false when trying to write any non-= trivial<br> &gt; &gt; program.<br> &gt;<br> &gt; It depends on the coding style.<br> <br> </div></div>I rarely end up passing by either ref or pointer, and the only = issues that<br> I&#39;ve ever had with ref relate to the fact that you can&#39;t pass it rv= alues.<br> Obviously both pointers and ref have their uses, but I&#39;d definitely hav= e to<br> concur that it depends on your coding style and what you&#39;re doing. Also= , I<br> really don&#39;t know what&#39;s wrong with ref such that anyone could say = that it<br> &quot;barely works&quot; other than the issues with rvalues and functions w= hich take ref<br> or const ref.<br></blockquote><div><br></div><div><div>struct X</div><div>{= </div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span=
int i;</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"wh=

uot;+&quot;) { return X(i + b.i); }</div> <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>ref X= opOpAssign(string op)(const ref X b) if(op =3D=3D &quot;+&quot;) { i +=3D = b.i; return this; }</div><div><div><span class=3D"Apple-tab-span" style=3D"= white-space:pre"> </span>...etc</div> </div><div>}</div><div><br></div><div>ref X func(ref X x)</div><div>{</div>= <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>retur= n x;</div><div>}</div><div><br></div><div>bool maybe()</div><div>{</div><di= v> <span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return (ti= me() &amp; 1) !=3D 0;</div><div>}</div><div><br></div><div>void test()</div=
<div>{</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=

<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>X v[]= ;</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"white-sp= ace:pre"> </span>func(a); // this is basically the only expression that wor= ks</div> <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>X t = =3D a + (b + c); // fail</div><div><span class=3D"Apple-tab-span" style=3D"= white-space:pre"> </span>a +=3D b + c; // fail</div><div><span class=3D"App= le-tab-span" style=3D"white-space:pre"> </span>ref X t =3D func(a); // fail= </div> <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>func(= a + b); // fail</div><div><span class=3D"Apple-tab-span" style=3D"white-spa= ce:pre"> </span>func(maybe() ? a : b); // this generates bad code: <a href= =3D"http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy forum.dlang.org">htt= p://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy forum.dlang.org</a></div> <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>ref X= t =3D v[some + complex * (expression + that_i_dont_want_to_repeat())]; // = fail</div><div><br></div><div><div><span class=3D"Apple-tab-span" style=3D"= white-space:pre"> </span>foreach(i; 0..10)</div> <div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{</di= v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>re= f X t =3D v[some + expression * involving - i]; // fail</div><div><span cla= ss=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div> </div><div>}</div></div><div><br></div><div>Just a couple of extremely comm= on usage patterns that come to mind. I&#39;m sure there are many more...</d= iv></div> --20cf3005dc10c6d37e04bfd3f6e6--
May 12 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, May 12, 2012 13:03:26 Manu wrote:
 On 12 May 2012 12:37, Jonathan M Davis <jmdavisProg gmx.com> 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 <wfunction hotmail.com
 
 <mailto:wfunction 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/cnwpmhihmckpjhlaszzy 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
May 12 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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<jmdavisProg gmx.com>  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<wfunction hotmail.com

 <mailto:wfunction 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/cnwpmhihmckpjhlaszzy 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.
May 12 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf3074b2503d255d04bfd47908
Content-Type: text/plain; charset=UTF-8

On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg 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. 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. --20cf3074b2503d255d04bfd47908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 12 May 2012 13:13, Jonathan M Davis <span dir= =3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdav= isProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">So, basically it&#39;s just the iss= ue with neither ref nor const ref taking</div></div> lvalues.</blockquote><div><br></div><div>And the local references, and the = bug.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If you duplicate t= he functions (or use auto ref if they&#39;re templated<br> functions), then it&#39;s not an issue.</blockquote><div><br></div><div>Yes= it is. Passing by value is NOT passing by reference, it&#39;s a totally di= fferent operation. And what about non-const ref?</div><div>&#39;in ref&#39;= would be very nice if it worked. It would basically replace &#39;const ref= &#39;.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> It sucks to have to duplicat= e stuff, but<br> ref works just fine as long as you don&#39;t assume that it&#39;s going to = allow you to<br> pass rvalues to it.</blockquote><div><br></div>Well there&#39;s the bugs we= &#39;ve seen in optimised codegen.<br class=3D"Apple-interchange-newline"><= div>Duplicating with non-ref is not a solution. It&#39;s not even a workaro= und. The only workaround is to receive a pointer, which ruins all those cas= es in terms of syntax anyway.</div> <div><div><br></div></div><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Personally, I alm= ost always just have functions take<br> structs by value, so it&#39;s a non-issue except for stuff like opEquals, w= hich<br> requires const ref (for at least one overload anyway).<br></blockquote><div=
<br></div><div>Well I think it&#39;s safe to say most people pass data str=

it a bug/typo and fix it.</div> <div>You might say to use a class in D, but classes aren&#39;t a pure data = structure like they are in C; I see them as being for fundamentally differe= nt purposes, and I wouldn&#39;t use a class to express a struct.</div><div> Classes also ruin strict data layout and alignment of members. I don&#39;t = think that&#39;s a valid workaround either, it&#39;s effectively abusing th= e very _concept_ of classes in D.<br><br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> However, given the ridiculousness of having to duplicate functions to make = ref<br> usuable for any case where you&#39;re specifically trying to avoid a copy r= ather<br> than use it to pass a value out, Andrei and Walter are looking at making re= f<br> work with rvalues.</blockquote><div><br></div><div>Awesome, although it doe= sn&#39;t end there. Local references are also very important.</div><div><br=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=

They just have to sort out how to avoid the issues that C++<br> has due to allow const&amp; to take rvalues (which is why const ref in D do= esn&#39;t<br> currently take rvalues). So, there&#39;s a good chance that the situation w= ill<br> improve considerably sometime soon.<br></blockquote><div><br></div><div>Wha= t are these issues I keep hearing about? I&#39;m not aware of any fundament= al problem with ref in C++...</div><div>Can you show an example of the prob= lem the design is trying to avoid?</div> </div><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin= -top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-w= idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding= -left:1ex"> <div class=3D"im">&gt; That&#39;s not a solution, it&#39;s not even a work = around, it&#39;s a totally<br>&gt; different operation. I may not want to, = or can&#39;t, pass my data by value.<br><br></div>Whether passing by value = makes sense depends on the struct. If it has lots of<br> members, then no, passing by value doesn&#39;t work very well (though still= not as<br>badly as C++98 thanks to the fact that D can move structs far mo= re often due<br>to its different copy semantics). But almost all of the str= ucts that I deal<br> with only have a handful of member variables at most, so the cost of passin= g<br>by value isn&#39;t high. In most cases, if I have a lot, I probably wa= nted a<br>reference type anyway, in which case, I&#39;m almost certainly go= ing to use a<br> class.<br></blockquote><div><br></div><div>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 tolera= nce for wasting memory accesses on such a trivial operation.</div> <div>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 tole= rate passing by value.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;ma= rgin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> But there&#39;s no question that the situation with const ref needs to be i= mproved<br>(it was discussed quite a bit on the beta list during the last b= eta).<br>Fortunately, that&#39;s likely to happen sometime soon.</blockquot= e> <div><br></div><div>That&#39;s a shame, it&#39;s been coming up every day f= or me the last couple of weeks. I have workarounds in almost every source f= ile, and some cases where a workaround is impossible, which pollutes the co= de at the point of use.</div> </div> --20cf3074b2503d255d04bfd47908--
May 12 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12.05.2012 14:39, Manu wrote:
 On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg gmx.com
 <mailto:jmdavisProg 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
May 12 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.647.1336819289.24740.digitalmars-d puremagic.com...
 On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg gmx.com> 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.)
May 12 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, May 12, 2012 15:17:22 Manu wrote:
 On 12 May 2012 14:03, Jonathan M Davis <jmdavisProg gmx.com> 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
May 12 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.657.1336847061.24740.digitalmars-d 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.
May 12 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Paulo Pinto" <pjmlp progtools.org> 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. ;)
May 12 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 13-05-2012 00:20, Nick Sabalausky wrote:
 "Paulo Pinto"<pjmlp progtools.org>  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
May 12 2012
prev sibling parent "Jakob Bornecrantz" <wallbraker gmail.com> writes:
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.
May 14 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 11 May 2012 21:02:40 +0200
schrieb Philippe Sigaud <philippe.sigaud gmail.com>:

 On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh quickfur.ath.cx> 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
May 17 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 14 May 2012 10:19:40 +0200
schrieb "Jakob Bornecrantz" <wallbraker gmail.com>:

 On Saturday, 12 May 2012 at 23:27:15 UTC, Alex R=C3=B8nne Petersen
 wrote:
 You know, my project consisting of 130-ish source files and=20
 24.000-ish lines of code compiles from scratch in ~20 seconds=20
 on my machine, building one file at a time... I honestly have=20
 not managed to come up with a build system for D that is=20
 actually slow, if compared to C/C++.

Try using GDC the compiler that can actually produce good code, or using -inline -release flags. =20 Debug build (GDC, multi invocation, 3 threads) real 0m42.452s =20 Release build (GDC, multi invocation, 3 threads) real 1m0.140s =20 Debug build (GDC, single invocation) real 0m22.151s =20 Release build (GDC, single invocation) real 0m54.960s =20 $ find src/ -name "*.d" | xargs wc -l | tail --lines 1 46057 total =20 Cheers, Jakob.

This is true. Once you decide to use GDC for whatever reason (chances of in= clusion into GCC, better optimization, ...) you are also about 1 revision b= ehind 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 re= member 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 fas= ter 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 lang= uages come with the compiler integrated into the standard library, allowing= for easy integration into IDEs and further optimizations of the compile ti= me. I remember Delphi (not as a VM language) had the compiler and linker in= tegrated into the IDE which made single file rebuilds practically instantan= eous. --=20 Marco
May 17 2012
prev sibling next sibling parent "soywiz" <soywiz gmail.com> writes:
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."
Aug 02 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 02 2013
prev sibling next sibling parent "Jacob Carlborg" <doob me.com> writes:
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
Aug 02 2013
prev sibling next sibling parent "Andre Artus" <andre.artus gmail.com> writes:
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<TSource>( this IEnumerable<TSource> source, Func<TSource, bool> predicate ) The Exists method is an older construct with a more limited application (List vs IEnumerable)
Aug 03 2013
prev sibling parent "Andre Artus" <andre.artus gmail.com> writes:
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.
Aug 03 2013