On 10 December 2013 08:29, Walter Bright <newshound2@digitalmars.com> wrote:
> On 12/9/2013 11:55 PM, H. S. Teoh wrote:
>>
>> Agree with your points, but just had to point out that I don't even *use* the mouse (well, barely), so your example is moot. :-P
>
>
> A vi user? :-)
>

Worse, he's from the emacs crowd.  :o)

On 10/12/13 09:21, H. S. Teoh wrote:
> It turned out that I had overlooked a simple but very significant
> optimization present in the C version that hadn't been implemented
> in the D version yet. [...] In the original C code, it took quite
> a while to implement this optimization because ...  well, in C, you
> had to spell out every last thing, otherwise it just won't work. In
> D, I kicked a crude version of it out in under a day.

There are such amazing multiplicative gains from D's design decisions -- as you describe here, even when you _need_ to drill down and micro-optimize, very often that too can be achieved in a way that is simpler than its C equivalent.  And so, at every level of your code, you get that opportunity to focus more on exploration and improvement and less on firefighting.

On 12/09/2013 11:00 PM, Walter Bright wrote:
> On 12/9/2013 1:28 PM, Timon Gehr wrote:
>> Sorry, I'm lost. What point are you arguing? None of this disputes in
>> any way
>> anything I wrote.
>
> I thought you were arguing that whole program analysis was as good as
> using immutable and const qualifiers.

Indeed. Recovering all immutable and const qualifiers that are possible to assign to the program is simple to do if the whole program is available.

(I was neither arguing that static analysis will eliminate all array bounds checks, nor that integrating such information into an existing C back-end is trivial, nor that manually adding the information does not mean that it does not have to be inferred.)

On Tuesday, 10 December 2013 at 08:28:12 UTC, Walter Bright wrote:
> On 12/10/2013 12:21 AM, H. S. Teoh wrote:
>> Result? The D version now runs faster than the C version -- perhaps up
>> to an order of magnitude.
>
> This case history would make a great blog post.

+1. My opinion _might_ be just a tad biased given that I just wrote one myself. :)

On Tue, Dec 10, 2013 at 08:59:26AM +0000, Iain Buclaw wrote:
> On 10 December 2013 08:29, Walter Bright <newshound2@digitalmars.com> wrote:
> > On 12/9/2013 11:55 PM, H. S. Teoh wrote:
> >>
> >> Agree with your points, but just had to point out that I don't even *use* the mouse (well, barely), so your example is moot. :-P
> >
> >
> > A vi user? :-)
> >
> 
> Worse, he's from the emacs crowd.  :o)

A vim user, actually. And that's text-mode vim, not gvim or any of that fancy stuff. In monochrome.

(Also, a ratpoison user. I don't do GUIs.)


T

-- 
The best way to destroy a cause is to defend it poorly.

On Tuesday, 10 December 2013 at 15:09:37 UTC, H. S. Teoh wrote:
> On Tue, Dec 10, 2013 at 08:59:26AM +0000, Iain Buclaw wrote:
>> On 10 December 2013 08:29, Walter Bright <newshound2@digitalmars.com> wrote:
>> > On 12/9/2013 11:55 PM, H. S. Teoh wrote:
>> >>
>> >> Agree with your points, but just had to point out that I don't even
>> >> *use* the mouse (well, barely), so your example is moot. :-P
>> >
>> >
>> > A vi user? :-)
>> >
>> 
>> Worse, he's from the emacs crowd.  :o)
>
> A vim user, actually. And that's text-mode vim, not gvim or any of that
> fancy stuff. In monochrome.
>
> (Also, a ratpoison user. I don't do GUIs.)
>
>
> T

That makes my GUI soul bleed. :)

--
Paulo

On Tue, Dec 10, 2013 at 10:38:42AM +0100, Joseph Rushton Wakeling wrote:
> On 10/12/13 09:21, H. S. Teoh wrote:
> >It turned out that I had overlooked a simple but very significant optimization present in the C version that hadn't been implemented in the D version yet. [...] In the original C code, it took quite a while to implement this optimization because ...  well, in C, you had to spell out every last thing, otherwise it just won't work. In D, I kicked a crude version of it out in under a day.
> 
> There are such amazing multiplicative gains from D's design decisions -- as you describe here, even when you _need_ to drill down and micro-optimize, very often that too can be achieved in a way that is simpler than its C equivalent.  And so, at every level of your code, you get that opportunity to focus more on exploration and improvement and less on firefighting.

I like that term "firefighting". :) An apt description of a large proportion of C programming. And I would add, *especially* true in C++ (cf. http://bartoszmilewski.com/2013/09/19/edward-chands/). At a certain point, it just becomes so tiresome to be spending more time fighting the language than actually attacking the problem you're trying to solve.

That's not to say everything is perfect in D -- sometimes working around compiler bugs (or issues in the const system) starts to feel a bit like firefighting too.

But D gets so many more things right, that I find myself far more productive in D than in C or C++. Exploration is far easier, as you say. Especially in C, the lack of adequate abstraction mechanisms force you to commit to a particular design early, and once you commit to that design, it takes a major overhaul if later on you decide that a different design is better. A lot of time is spent fighting the language, rather than actually moving on with the task at hand. I would say this is another point where D wins over C: sure, if you already know exactly how your final program will look like, you can plan ahead and design it for maximum performance from the get-go in C.  But many times you *don't* know beforehand what's the best design, and there's quite a bit of exploration needed before you settle on one. In C, exploration is difficult because it could mean rewriting the whole thing from ground up. In D, far less effort is needed, which gives you more time to work on stability and tuning performance, rather than throwing in a bunch of last-minute hacks just to make things work because you've spent too much time firefighting, and now the deadline's almost up and the product needs to be shipped.


T

-- 
This is not a sentence.

On Tuesday, 10 December 2013 at 07:51:56 UTC, H. S. Teoh wrote:
> We need to work on the "compiler as a library" project.

I hope everyone agrees on this. My wild guess is that the project will be the next "big thing" to work on after the frontend is moved to D.

"Francesco Cattoglio" <francesco.cattoglio@gmail.com> wrote in message news:stpuvkzasctgyoryunbg@forum.dlang.org...
> On Tuesday, 10 December 2013 at 07:51:56 UTC, H. S. Teoh wrote:
>> We need to work on the "compiler as a library" project.
>
> I hope everyone agrees on this. My wild guess is that the project will be the next "big thing" to work on after the frontend is moved to D.

That's the plan.

On 12/10/2013 1:58 AM, Timon Gehr wrote:
> Recovering all immutable and const qualifiers that are possible to
> assign to the program is simple to do if the whole program is available.

I believe you are seriously mistaken about it being simple, or even possible.

For example, malloc() returns a pointer. How do you know if that returns a pointer to immutable data or not? Even if it could look at the source code to malloc()?