On Saturday, 25 August 2012 at 21:17:55 UTC, Walter Bright wrote:
> On 8/25/2012 1:06 PM, Peter Alexander wrote:
>> On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright wrote:
>>> On 8/25/2012 6:03 AM, Peter Alexander wrote:
>>>> Okay, so bitfields are rarely used, but many templates involve some use of CTFE,
>>>> and templates are very common in D code. It's good that D's parser is fairly
>>>> simple to implement (compared to C++ anyway), but to do automated refactoring
>>>> you need simple semantic analysis, and this is something that D does not have.
>>>
>>> How many IDEs can handle the C preprocessor, with token pasting and all, when
>>> refactoring?
>>
>> Straw man - I didn't suggest that the C preprocessor was any better. C++ is
>> similarly criticised for its poor IDE support (when compared with C# and Java)
>> due to the pre-processor and templates. If you haven't seen the level of support
>> that (for example) Visual Studio provides for C# then I recommend checking it
>> out. I imagine the situation with Java and Eclipse is similar, but I don't have
>> any experience there.
>
>
> I don't agree it's a straw man - it's the point. A perfect job is not necessary in order for people to find automated refactoring useful.

I'm not sure how your previous comment supports that point.

C (and C++) don't do a perfect job, but as I said, they are similarly criticised for their poor IDE support.

I do agree with you: the tools don't need to do a perfect job, but I worry if they'll even be able to do a reasonable job. Templates, CTFE, mixins, etc. are all rampant in D, so I worry about the amount of work required for tool-developers to support a respectable subset of D that will stand up to criticism from the C#/Java folks.

Because of reflection, refactoring can't do an accurate job in Java/C# either.

On 08/25/2012 09:48 PM, Jeff Nowakowski wrote:
> On 08/25/2012 12:23 PM, Timon Gehr wrote:
>> On 08/25/2012 03:36 AM, Pragma Tix wrote:
>>
>> I really don't get what this is about. Are you actually suggesting
>> things are as they are because some clueless developers are unaware of
>> the issues?
>
> Judging by your first reaction, that is a possibility, where you
> completely ignored important issues like garbage collection and the pain
> surrounding immutable.
>

Everyone here is aware of these issues.

> ...
> They also had funding and hired somebody to work on the Eclipse plugin full
> time.

Exactly.

On 2012-08-25 21:39, Walter Bright wrote:

> How many IDEs can handle the C preprocessor, with token pasting and all,
> when refactoring?

1. Any IDE based on libclang should be able to handle this. Xcode 4 uses libclang.

2. The C preprocessor is no excuse to why we shouldn't have good refactoring tools for D.

-- 
/Jacob Carlborg

On Saturday, 25 August 2012 at 22:11:12 UTC, Araq wrote:
> Because of reflection, refactoring can't do an accurate job in Java/C# either.


Uh, you're being VERY unfair here.

C# and Java refactoring tools are 100% accurate for compile-time code.

Calling them "inaccurate" because of reflection is completely missing the point.

C++ or D tools can't even do their compile-time job to begin with, even forgetting about RTTI.

On Sat, 25 Aug 2012 22:36:08 +0200
"SomeDude" <lovelydear@mailmetrash.com> wrote:

> On Saturday, 25 August 2012 at 00:20:57 UTC, Timon Gehr wrote:
> > On 08/25/2012 01:58 AM, Pragma Tix wrote:
> >> ----was Andrew McKinlay is trying D for Suneido.
> >>
> >> http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html
> >>
> >> You do not necessarily have to agree with Andrew, but this is a
> >> pragmatic developer's view.  Let me say that Andrew has
> >> created his own
> >> database system (Relational Algebra based) , his own language
> >> (Ruby
> >> like)  and his own application frame work. Finally he is using
> >> his Tools
> >> to create real world software.. i.e. Trucking/Transport /
> >> Accounting etc.
> >>
> >> IMO a voice, D core developers should listen to.
> >>
> >> Bjoern
> >
> > His post comes down to: "I like to have an IDE and I prefer Java
> > because I already know Java."
> > This is perfectly fine of course, but why would this be
> > relevant for D
> > development?
> 
> No, he points out that 1) templates inherently complexify code 2)
> make refactoring difficult, especially automated refactoring,
> something that is supported by major modern IDEs and not by text
> editors like vim/emacs, because the former have some knowledge of
> the AST, not the latter.
> I know the first point is debatable; maybe there is less need for
> refactoring as the language is more expressive, but when
> refactoring is needed, it's probably much more difficult than in
> Java/C#, especially without the help of tools.

FWIW: Personally, I would argue that (as nice as automated refactoring admittedly is) putting up with a simplistic less expressive language for the sake of niceties like (perfect) automated refactoring is putting the cart before the horse. It'd be like putting up with starvation because you can't find a salad marked "organic". Having automated refactoring be less-than-perfect is a price, yes, but it's a very small price to pay for the much bigger savings you get from having powerful metaprogramming.

Plus, certain non-automatic refactorings would be a much bigger pain in something like Java anyway because of, for example, the lack of type inference and the increased need for code to be non-generic in the first place.

My $0.02, anyway.

On Sun, 26 Aug 2012 00:33:01 +0200
"Mehrdad" <wfunction@hotmail.com> wrote:

> On Saturday, 25 August 2012 at 22:11:12 UTC, Araq wrote:
> > Because of reflection, refactoring can't do an accurate job in Java/C# either.
> 
> 
> Uh, you're being VERY unfair here.
> 
> C# and Java refactoring tools are 100% accurate for compile-time code.
> 
> Calling them "inaccurate" because of reflection is completely missing the point.
> 
> C++ or D tools can't even do their compile-time job to begin with, even forgetting about RTTI.

No, I think Araq raises a good point here: Reflection screws with automated refactoring, period, and Java and D both have reflection.

Whether that reflection is runtime or compile-time doesn't change anything here. Java code that uses reflection can't be perfectly auto-refactored. D code that uses reflection can't be perfectly auto-refactored. Same effect either way. Saying that it counts for compile-time but not for run-time is just arbitrarily moving the goal-posts.

Of course, D also has other things besides reflection that can mess with refactorings, like mixins+ctfe, but hey, anyone can still stick a code-generator in front of a call to "javac", and you've got the same problem (only clunkier to use and even *less* likely to be refactorable). Not saying that's as common in Java as mixins+ctfe are in D, but the point is: it's features/techniques that mess with auto-refactoring, not languages.

It *is* a tradeoff, admittedly. But I'm not sure how fair it is to blame a language for it rather than a technique. And I think that many people, even if not *all* (can't please all the people all the time), would find the tradeoff to be a net gain. I certainly do, at least.

On Saturday, 25 August 2012 at 22:32:10 UTC, Jacob Carlborg wrote:
> On 2012-08-25 21:39, Walter Bright wrote:
>
>> How many IDEs can handle the C preprocessor, with token pasting and all,
>> when refactoring?
>
> 1. Any IDE based on libclang should be able to handle this. Xcode 4 uses libclang.
>
> 2. The C preprocessor is no excuse to why we shouldn't have good refactoring tools for D.

For (1), I think Walter is referring to something like this:


#define GLOBAL(name) g_ ## name

int GLOBAL(foo);
g_foo = 123;


I don't think XCode would allow you to right-click the g_foo and rename it. It's not possible in the general case.

On Sat, 25 Aug 2012 14:16:27 -0700
Walter Bright <newshound2@digitalmars.com> wrote:
> On 8/25/2012 1:06 PM, Peter Alexander wrote:
> >
> > Straw man - I didn't suggest that the C preprocessor was any better. C++ is similarly criticised for its poor IDE support (when compared with C# and Java) due to the pre-processor and templates. If you haven't seen the level of support that (for example) Visual Studio provides for C# then I recommend checking it out. I imagine the situation with Java and Eclipse is similar, but I don't have any experience there.
> 
> 
> I don't agree it's a straw man - it's the point. A perfect job is not necessary in order for people to find automated refactoring useful.
> 

C++ is known for having a lot of problems - Heck, that's why D exists. So saying "C++ does XX" doesn't necessarily excuse anything. And I don't think it does excuse it in this case.

However, that said, I think C++ does work as an example of why it's not *necessarily* a terribile thing that D isn't perfectly auto-refactorable. And FWIW, I do think D's metaprogramming power *is* perfectly sufficient justification for it's refactoring difficulty.

And do I agree that "A perfect job is not necessary in order for people to find automated refactoring useful."

On 8/25/2012 3:32 PM, Jacob Carlborg wrote:
> On 2012-08-25 21:39, Walter Bright wrote:
>
>> How many IDEs can handle the C preprocessor, with token pasting and all,
>> when refactoring?
>
> 1. Any IDE based on libclang should be able to handle this. Xcode 4 uses libclang.
>
> 2. The C preprocessor is no excuse to why we shouldn't have good refactoring
> tools for D.

I'm not saying it's an excuse, I'm saying that people don't say C IDEs are a failure because of this.