On 10 December 2013 12:32, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

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

It can be done. I use tools like this.
One of my favourites goes:

* highlight text
* click 'refactor' (or hotkey)
* type name for function

New function is produced containing the selected code. If the selected code
was an expression, then the function is generated with a return statement
and the appropriate return type.
If the selected code relied on any local variables, they are automatically
added as function parameters. The call-site is updated with the new
function call, and the local variables previously referenced passed to the
function as arguments appropriately.

There's room for an extension to this tool which might scan for the same code throughout the project, and offer to replace the same pattern with calls to the new function, again, automatically filling out the function parameters.

This is only one of many useful tools that become available once tooling
has a thorough semantic analysis library available.
It would be amazing if there was some real effort put into a convenient
tooling API in the DMD front-end lib.

Manu:

> There's room for an extension to this tool which might scan for

If you keep adding similar features to an IDE, you perceive the code less and less as an amount of text lines and more and more like something fluid, where its semantics become less tied to its look. And this is good. This does not require to save source code in a format different from the usual text.


> It would be amazing if there was some real effort put into a convenient tooling API in the DMD front-end lib.

I agree. Making D/D-front-end a bit more IDE-friendly is good.

Bye,
bearophile

On 12/9/2013 7:04 PM, Manu wrote:
> It would be amazing if there was some real effort put into a convenient tooling
> API in the DMD front-end lib.

Generally, the best tools come from people who make them to please themselves, not from people who make them to someone else's spec. I suspect you'd make a very good refactoring tool.

How about it?

On 10 December 2013 13:40, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/9/2013 7:04 PM, Manu wrote:
>
>> It would be amazing if there was some real effort put into a convenient
>> tooling
>> API in the DMD front-end lib.
>>
>
> Generally, the best tools come from people who make them to please themselves, not from people who make them to someone else's spec. I suspect you'd make a very good refactoring tool.
>
> How about it?
>

Not without a powerful semantic analysis library I wouldn't.
Other's have spent years now on semantic analysis libraries trying to
duplicate the understanding of the code that DMD must already have while
compiling.

On 09/12/13 20:45, Araq wrote:
> That language X is faster than C in "practice" because X is much more developer
> friendly and thus you can tweak your code much easier etc. is an argument of
> every language out there.

Yes, but most languages (certainly most "friendly" ones) do not allow you to drill down into the details in the way that D does.

The claim that's made for most languages in my experience is that, sure, the language is ultimately slower, but the developer time saved is worth more than the performance hit, and if you ever _really_ need to gain that extra performance, you can always drop down into C.  Of course, that assumption doesn't hold for some domains (e.g. intensive scientific simulation, games...) which is why C/C++ still has a significant presence there.

By contrast with D you get all that friendliness of refactoring and redesigning and extra time to experiment with alternatives, but in a language which is speed-wise on a par with C anyway; and if its higher-level constructs cause any problems, you can drill down to micro-management of your program _while still writing in D_.  That's why D is very useful for heavy-duty scientific simulation and why unlike most other friendly languages it's a genuine contender for games programming.

On Tue, Dec 10, 2013 at 02:01:09PM +1000, Manu wrote:
> On 10 December 2013 13:40, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> > On 12/9/2013 7:04 PM, Manu wrote:
> >
> >> It would be amazing if there was some real effort put into a convenient tooling API in the DMD front-end lib.
> >>
> >
> > Generally, the best tools come from people who make them to please themselves, not from people who make them to someone else's spec. I suspect you'd make a very good refactoring tool.
> >
> > How about it?
> >
> 
> Not without a powerful semantic analysis library I wouldn't.  Other's have spent years now on semantic analysis libraries trying to duplicate the understanding of the code that DMD must already have while compiling.

We need to work on the "compiler as a library" project. A *lot* of code analysis tools are unnecessarily duplicating effort because the compiler is opaque; if compiler internals could be leveraged, this would open the door for powerful code analysis/manipulation tools, and they'd be *accurate*, and won't need endless maintenance to keep up with compiler changes. Well, they still require maintenance, but the effort would be far easier if much of the codebase is shared.


T

-- 
It only takes one twig to burn down a forest.

On Tue, Dec 10, 2013 at 12:54:02PM +1000, Manu wrote:
[...]
> 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?).
[...]

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


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth

On Tue, Dec 10, 2013 at 08:28:14AM +0100, Joseph Rushton Wakeling wrote:
> On 09/12/13 20:45, Araq wrote:
> >That language X is faster than C in "practice" because X is much more developer friendly and thus you can tweak your code much easier etc. is an argument of every language out there.
> 
> Yes, but most languages (certainly most "friendly" ones) do not allow you to drill down into the details in the way that D does.
> 
> The claim that's made for most languages in my experience is that, sure, the language is ultimately slower, but the developer time saved is worth more than the performance hit, and if you ever _really_ need to gain that extra performance, you can always drop down into C.  Of course, that assumption doesn't hold for some domains (e.g. intensive scientific simulation, games...) which is why C/C++ still has a significant presence there.
> 
> By contrast with D you get all that friendliness of refactoring and redesigning and extra time to experiment with alternatives, but in a language which is speed-wise on a par with C anyway; and if its higher-level constructs cause any problems, you can drill down to micro-management of your program _while still writing in D_.  That's why D is very useful for heavy-duty scientific simulation and why unlike most other friendly languages it's a genuine contender for games programming.

Recently I rewrote one of my personal pet projects in D. It turned out a lot better than the original C version -- D's high-level features made it easier to implement complex functionality with relatively simple (and readable!) code.

Then I came to a CPU-intensive bit, and initially things didn't look very good: a particular medium-sized problem that I was using as a real-life test case ran in seconds in the C version, but took a very long time with the D version (about 40 *minutes*, if I remember). I was a bit disappointed, but remembered that the D version was still not yet refined. 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. (Basically, it's a brute-force combinatorial algorithm, so the complexity is exponential, and every little problem reduction can make a big difference. In this case, it was a matter of recognizing the equivalence of certain problem combinations that allowed the reduction of the search space by a factor of about n factorial.) 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.

Result? The D version now runs faster than the C version -- perhaps up to an order of magnitude. I was suitably impressed.  It's not all roses and flowers yet, of course -- the D version has some memory usage issues that I need to work on, but the fact that an almost optimal-performing version of the code could be done so smoothly in such a short time speaks good things about D.

Plus, D's ease of expression made it so easy to implement new algorithms without incurring runtime costs -- I easily implemented an A* search algorithm instead of the original plain BFS, and now, for certain problems, the D version flat out beats the C version in terms of performance. Could I have implemented an A* search in the C version? Sure, after weeks or months of careful reworking of the C code to make sure I didn't break anything or introduce any segfaults. Arguably, the result would perform better than D. But the fact of the matter is, with D, I achieved extremely good performance for just a few days' work. And I think that's the crux of the issue here: sure in C you can code in a way that will beat every other language out there. But it requires a lot of careful effort to get you there (not to mention dealing with all the associated pitfalls). D may not get you all the way to absolute every-last-drop-from-the-CPU performance, but it gets you 90% of the way there, with far, far less effort. Most of the time, this is a far better ROI than in C.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

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.

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? :-)