Le 10/12/2013 03:54, Manu a écrit :
> On 10 December 2013 11:42, deadalnix <deadalnix@gmail.com
> <mailto:deadalnix@gmail.com>> wrote:
>
>     On Sunday, 8 December 2013 at 05:37:09 UTC, H. S. Teoh wrote:
>
>         Or maybe this is just another one of those cultural old age
>         indicators?
>         Has the term "refactoring" shifted to mean "variable renaming"
>         among the
>         younger coders these days? Genuine question. I'm baffled that
>         these two
>         things could even remotely be considered similar things.
>
>
>     Refactoring is changing your code, without changing what it does. It
>     is done in order to make your code easier to understand, more
>     maintainable, more testable, or whatever.
>
>     Both extracting some code into a function and renaming a variable
>     are refactoring operations.
>
>
> With effective semantic analysis, there are many useful refactoring
> tools that become possible.
> Renaming things is the simplest and probably most common, so it's
> usually a good starting point.
>
> Other possibilities for instance:
>   * Not just renaming functions, but changing it's signature in general.
> If types are changed, then some handling likely needs to be performed
> (or at least alerted) at call sites
>   * Renaming modules (required when moving source files within the
> source tree); update imports, etc.
>   * Reordering function parameters automatically reorders terms supplied
> to calls of the function (how many times have you wanted to reverse 2
> function parameters, and they've both been int? impossible to update all
> references without error)
>   * Assignments to delegates may automatically produce an appropriate
> function stub, along with typical function name
> 'On[event-name-being-assigned-to]() { }' or whatever is conventional,
> and proper parameters
>   * Hilight some text, 'refactor into own function' can move a block of
> selected code into a separate function, and correctly update the call
> site with the appropriate call, automatically adding function parameters
> for previously referenced local variables (seriously, how many times
> have you done this, and then carefully had to chase up the locals that
> are referenced to build the parameter list?)
>   * In addition to the prior point, scan for additional instances of the
> code you just refactored, and offer to also replace with calls to the
> new function (again, properly hooking up arguments)
>   * Auto-magic @property/accessor generation from member variables
>   * Auto-magically produce stubs for methods declared in interfaces
>   * And many more possibilities...
>   * Produce tools to statically encorce project coding standards; ie,
> produce red underlines beneath terms in the editor that don't conform to
> project standards
  * Add/Remove import automatically
  * Underline in red errors without compiling

>   * Underline in red errors without compiling

I get this one for free in Emacs with flycheck. It's not _really_ without compiling since it calls the compiler behind my back, but it's essentially the same thing.

Am Tue, 10 Dec 2013 00:21:16 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> D may not get you all the way to absolute every-last-drop-from-the-CPU performance

I firmly disagree.

-- 
Marco

On 12/10/2013 1:01 PM, Marco Leise wrote:
> Am Tue, 10 Dec 2013 00:21:16 -0800
> schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:
>
>> D may not get you all the way to absolute every-last-drop-from-the-CPU
>> performance
>
> I firmly disagree.

Especially since if you write C code in D, you will get exactly C results.

On Tuesday, 10 December 2013 at 20:36:22 UTC, Walter Bright wrote:
> On 12/10/2013 1:01 PM, Marco Leise wrote:
>> Am Tue, 10 Dec 2013 00:21:16 -0800
>> schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:
>>
>>> D may not get you all the way to absolute every-last-drop-from-the-CPU
>>> performance
>>
>> I firmly disagree.
>
> Especially since if you write C code in D, you will get exactly C results.

I think it is better to rephrase it as "writing C code in D is possible but even less convenient than in C".

On 12/10/2013 12:39 PM, Dicebot wrote:
> I think it is better to rephrase it as "writing C code in D is possible but even
> less convenient than in C".

Why would it be less convenient?

At the least, it'll compile a lot faster!

On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote:
> At the least, it'll compile a lot faster!

Small C programs compile a *lot* faster than small D programs that use Phobos.

import std.stdio; == add half a second to your compile time.

$ time dmd hellod.d

real    0m0.780s # YIKES!
user    0m0.649s
sys     0m0.102s

$ time gcc helloc.c

real    0m0.148s # not bad
user    0m0.095s
sys     0m0.039s


yikes, even doing printf in D is slow nowadays

$ time dmd hellod.d

real    0m0.290s # good but not great
user    0m0.212s
sys     0m0.058s



Larger D programs do better, of course, at least if you compile all the files at once (and don't use so much CTFE that it starts thrashing the swap file).

Am 10.12.2013 22:16, schrieb Adam D. Ruppe:
> On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote:
>> At the least, it'll compile a lot faster!
>
> Small C programs compile a *lot* faster than small D programs that use
> Phobos.
>
> import std.stdio; == add half a second to your compile time.
>
> $ time dmd hellod.d
>
> real    0m0.780s # YIKES!
> user    0m0.649s
> sys     0m0.102s
>
> $ time gcc helloc.c
>
> real    0m0.148s # not bad
> user    0m0.095s
> sys     0m0.039s
>
>
> yikes, even doing printf in D is slow nowadays
>
> $ time dmd hellod.d
>
> real    0m0.290s # good but not great
> user    0m0.212s
> sys     0m0.058s
>
>
>
> Larger D programs do better, of course, at least if you compile all the
> files at once (and don't use so much CTFE that it starts thrashing the
> swap file).

Those are implementation issues, right?

--
Paulo

On Tue, Dec 10, 2013 at 10:16:25PM +0100, Adam D. Ruppe wrote:
> On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote:
> >At the least, it'll compile a lot faster!
> 
> Small C programs compile a *lot* faster than small D programs that use Phobos.
> 
> import std.stdio; == add half a second to your compile time.

That's not too bad. One of my template-heavy projects take almost 10 seconds to compile just a single source file. And a single string import can add up to 3-4 seconds (well, probably due to CTFE since I call split() on the string).


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote:
> On 12/10/2013 12:39 PM, Dicebot wrote:
>> I think it is better to rephrase it as "writing C code in D is possible but even
>> less convenient than in C".
>
> Why would it be less convenient?
>
> At the least, it'll compile a lot faster!

We have been already fighting on that topic several times here and on reddit ;) Probably the most frustrating difference for me are array literals that allocate in D, literally banning its usage from typical C-like code.