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

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

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

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

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

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

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

-- 
Marco

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.

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

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.

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.

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