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


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


 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.


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?


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

sorted only by convention).

I think we copiously made the right call there.


Andrei
May 11 2012
next sibling parent reply "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 

 (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
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
parent reply "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.


it's called "Except".
(Like, items.except(otherItems).)


empty, whereas D's "any()" method takes in a predicate. I find 


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
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, May 11, 2012 21:15:53 Mehrdad wrote:


 empty, whereas D's "any()" method takes in a predicate. I find



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
next sibling parent reply "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 



Are you thinking of a language in particular that has D's 
behavior? Or is this just a guess?
May 11 2012
next sibling parent reply "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


 
 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
next sibling parent reply "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.

"are there any elements in this list?", NOT with the meaning D
uses.)
May 11 2012
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.

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


--
/Jacob Carlborg
Aug 02 2013
prev sibling parent reply 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"



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

 would do


 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
prev sibling 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 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 parent "Kagamin" <spam here.lot> writes:
On Friday, 11 May 2012 at 19:15:54 UTC, Mehrdad wrote:


 empty, whereas D's "any()" method takes in a predicate. I find 



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 parent reply 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

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

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



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 parent reply "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
parent reply "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
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 reply "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
next sibling parent reply "Anders =?UTF-8?B?U2rDtmdyZW4i?= <anders sjogren.info> writes:
Since this post is about inuition, I'll raise my voice even 

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
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 reply "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
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
parent reply "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
next sibling parent reply "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
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 reply 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
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 parent reply 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
parent reply 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
parent reply "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
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?


  May the schwartz be with you.


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


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


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

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
May 17 2012
prev sibling parent reply "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
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 reply "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
parent reply "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
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 next sibling 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 parent reply "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
next 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 "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 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 "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
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 reply "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
next sibling parent reply 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
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 Brad Anderson <eco gnuk.net> writes:
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.
May 18 2012
prev sibling 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 parent Brad Anderson <eco gnuk.net> writes:
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.
May 18 2012
prev 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 reply "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
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 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?


 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
parent reply "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.


 I don't know about that. They seemed simple enough to me.


Me too, as a matter of fact.

But they definitely aren't intuitive (just judge by the number of 
questions about them that pop up on StackOverflow or elsewhere...)


 3. Ranges aren't confusing, but USING them certainly is.>


 On the contrary, I actually think we're lacking proper 
 documentation on what ranges are.


Yeah probably.



 array.
 It's VERY straightforward.
 In D, it's VERY CONFUSING


 Library issue.


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



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


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


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

The mere fact that it uses a pointer makes it unintuitive to a 




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


 I don't know about that. They seemed simple enough to me.


 Me too, as a matter of fact.

 But they definitely aren't intuitive (just judge by the number of
 questions about them that pop up on StackOverflow or elsewhere...)


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


 3. Ranges aren't confusing, but USING them certainly is.>


 On the contrary, I actually think we're lacking proper documentation
 on what ranges are.


 Yeah probably.



 It's VERY straightforward.
 In D, it's VERY CONFUSING


 Library issue.


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


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


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


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


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


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


 The mere fact that it uses a pointer makes it unintuitive to a large




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



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



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



 
 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
next sibling parent reply "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
next sibling parent reply =?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
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 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 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 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 reply "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
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 parent reply Manu <turkeyman gmail.com> writes:
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.
May 12 2012
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 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 reply Manu <turkeyman gmail.com> writes:
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.
May 12 2012
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 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 Manu <turkeyman gmail.com> writes:
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...
May 12 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 Rønne Petersen wrote:

Complicated language structure? Long compilation times?

wat.


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


Templates are stencils for generating code. There's nothing confusing
about that, unless you try to shoehorn them into a preconceived mental
model of functions that take parameters and return something.

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



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


Again, the problem is lack of proper introductory documentation for
them. Actually, I find that to be a consistent problem with much of the
current D docs. They appear to be written for people who already know
what the thing is, and as such is very unhelpful to a newbie.



 3. Ranges aren't confusing, but USING them certainly is.
 
    Don't believe me?
 

 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
next sibling parent reply "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
next sibling parent reply "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
parent reply "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
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 "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 "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 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 reply "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
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 reply 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
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 parent reply 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
parent reply 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
parent reply 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
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 reply "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
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 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 parent reply "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
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 reply "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
parent reply "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
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
parent reply "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
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 reply "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
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
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 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 reply "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
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 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 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 parent reply "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.
    ...

 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
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 parent reply "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
next sibling parent reply "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
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 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
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 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 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
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 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 parent reply "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, 


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
parent reply "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 


 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
parent reply 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
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 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


 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 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++.
May 11 2012
parent reply "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
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 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 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


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


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


 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=




ely

 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=




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




le,

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

 
 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
parent reply "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 


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

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

 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 !

comparable
 to Python.


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


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


This is too simplistic and very wasteful. The same data will be 
processed all over again. I don't know how IDEs manage to make modern 

2GHZ quad-core systems appear slow, but it might well be that kind of 


coding.
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 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 "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 =?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


  > - integrated debugger

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


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


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


-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
May 18 2012
prev sibling next sibling parent reply "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
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 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 reply Manu <turkeyman gmail.com> writes:
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.
May 19 2012
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 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


  > - integrated debugger

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


No, you misunderstand.

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

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

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

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


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


I do not see how this is relevant. Is your misunderstanding of the post 
deliberate?
May 20 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
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


  > - integrated debugger

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


 No, you misunderstand.

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

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

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

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


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


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



clear indication the environment was important to him.



 May 20 2012



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


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


 clear indication the environment was important to him.



Linux any day.



 May 20 2012



  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:


 clear indication the environment was important to him.



 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  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 Rønne Petersen
alex lycus.org
http://lycus.org



 May 30 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:


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.



 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


 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



  parent reply =?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


 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



  parent reply "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



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


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

 and it probably has a compiler with comparable speed to DMD (e.g. much fas=

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  parent reply "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 

easily. In the case of D I would have to creaet a emitter per 
supported platform (mostly x86, x64 and ARM).


fact, I liked D a lot, that much that I started an emulator using 
it."



 Aug 02 2013



  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 

 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