On Monday, 9 December 2013 at 20:38:34 UTC, Walter Bright wrote:
> On 12/9/2013 11:45 AM, Araq wrote:
>> On Monday, 9 December 2013 at 19:19:46 UTC, Walter Bright wrote:
>>> On 12/9/2013 6:24 AM, Araq wrote:
>>>> ("When in doubt, assume it modifies this location.")
>> > And it's usually in doubt, often enough to make that optimization a pipe dream.
>> I disagree.
>
> I'm not without some experience with this - I have written a data flow analysis optimizer (it's in dmd) and I know how they work.

Well so do I.

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.

On 12/9/2013 1:51 PM, Araq wrote:
> On Monday, 9 December 2013 at 20:38:34 UTC, Walter Bright wrote:
>> On 12/9/2013 11:45 AM, Araq wrote:
>>> On Monday, 9 December 2013 at 19:19:46 UTC, Walter Bright wrote:
>>>> On 12/9/2013 6:24 AM, Araq wrote:
>>>>> ("When in doubt, assume it modifies this location.")
>>> > And it's usually in doubt, often enough to make that > optimization a pipe
>>> dream.
>>> I disagree.
>>
>> I'm not without some experience with this - I have written a data flow
>> analysis optimizer (it's in dmd) and I know how they work.
>
> Well so do I.

Have you instrumented one and then run it on real programs to see how often certain optimizations can be applied? Because I have, and these sorts of optimization opportunities rarely occur. "It's always something" that prevents it because the worst possible case always is the one that rules.

It can be as simple as retrieving a pointer from a data structure. Or one of the callers to a function is getting its pointer from an API that you didn't have source for (like the operating system). Or it came from malloc(). Etc.

On Monday, 9 December 2013 at 19:19:46 UTC, Walter Bright wrote:
> Inlining across source files?
>

Yes. LTO consist in dumping the IR in the object file. Then the linker can merge all the IR in one giant module and perform global optimizations.

This is expansive, but useful to get the last drop of perfs out of release builds.

On Monday, 9 December 2013 at 19:19:46 UTC, Walter Bright wrote:
> On 12/9/2013 6:24 AM, Araq wrote:
>> Both GCC and LLVM can perform link time optimizations.
>
> Inlining across source files?

Yes, and MSVC does so too.

David

On Monday, 9 December 2013 at 21:51:09 UTC, Araq wrote:
> On Monday, 9 December 2013 at 20:38:34 UTC, Walter Bright wrote:
>> On 12/9/2013 11:45 AM, Araq wrote:
>>> On Monday, 9 December 2013 at 19:19:46 UTC, Walter Bright wrote:
>>>> On 12/9/2013 6:24 AM, Araq wrote:
>>>>> ("When in doubt, assume it modifies this location.")
>>> > And it's usually in doubt, often enough to make that optimization a pipe dream.
>>> I disagree.
>>
>> I'm not without some experience with this - I have written a data flow analysis optimizer (it's in dmd) and I know how they work.
>
> Well so do I.

My experience also matches Walter's.

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.

Yes, renaming is not very representative of "refactoring", which generally is intended to mean more complex reorganizations. (That's why I asked Walter if he considered renaming something to be refactoring, before arguing my point). Still, it seems reasonable to me to include renaming as part of the refactoring tools, conceptually and practically.

I chose the trivial task of renaming for the example because it was something everybody does, is easily understandable and adequate to the argument: a human and a generic editor function/macro do not do it as quickly and safely as a specialized refactoring tool which understands the language (which will fix all static uses of the old name, and can point out other places for review).

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.

On Tue, Dec 10, 2013 at 02:42:05AM +0100, deadalnix 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.

OK, but isn't renaming among the more trivial refactoring operations? Albeit, granted, it is probably also the most easily automated. Splitting an overly-long function into smaller pieces is a more meaningful (IMO) refactoring operation, but probably much more difficult to automate (if it even can be).


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln

On 10 December 2013 11:42, deadalnix <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

If you develop habits around these sorts of tools, you can be far more
productive, and then when they are gone, it feels kinda like trying to use
a mouse without a wheel (ever tried that recently?).
They can also significantly increase the quality of code overall, since
trivial refactoring in many forms becomes an instantaneous operation rather
than wasting programmers working hours. And tools like project coding
standards enforcement will keep the slackers in check.