Walter Bright wrote:
> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.

I think optimizing your language for vi and the printer is a dead-end. The vast majority of the time a developer is going to be working on his code on a computer using some tool.  If a tool lets you make use of a big productivity feature, then it makes sense to use it and officially endorse it as a basic requirement of the language.  Even vi users use tools like grep and ctags.

-Jeff

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>
>>> 4) Having overloads spread across the inheritance hierarchy makes the source code resistant to visual audits. For any method call, you'll have to look at EVERY base class to see if it has an overload that is a better match.
>>>
>>
>> I'm not sure if you've seen my other reply to this argument, but let be more explicit, with pictures. Let's say you have such a big inheritance hierarchy, with overloads spread across it.
> 
> I appreciate that you can write tools to analyze it. I think they help a lot in writing the code, but I don't think they are as helpful for auditing (code review).
> 

Auditing, as in someone review someone else's code? Well, yes, in that case that tool functionality wouldn't be that useful (although other functionalities might be), however, auditing is a very specific situation, as well has it has lots of other difficulties which aren't easy to handle.

> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.

"rarely used"?? Wait, what do you mean "add-on tools"? That functionality is part of JDT (the best (non-commercial) and most popular Java IDE), and similar functionality exists in other IDEs for other languages, so it's quite the opposite of rarely used.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright escribió:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>
>>> 4) Having overloads spread across the inheritance hierarchy makes the source code resistant to visual audits. For any method call, you'll have to look at EVERY base class to see if it has an overload that is a better match.
>>>
>>
>> I'm not sure if you've seen my other reply to this argument, but let be more explicit, with pictures. Let's say you have such a big inheritance hierarchy, with overloads spread across it.
> 
> I appreciate that you can write tools to analyze it. I think they help a lot in writing the code, but I don't think they are as helpful for auditing (code review).
> 
> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.

I think it's the opposite. In every workplace I've been, people can't live with a decent IDE.

Ary Manzana wrote:
> Walter Bright escribió:
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>>
>>>> 4) Having overloads spread across the inheritance hierarchy makes the source code resistant to visual audits. For any method call, you'll have to look at EVERY base class to see if it has an overload that is a better match.
>>>>
>>>
>>> I'm not sure if you've seen my other reply to this argument, but let be more explicit, with pictures. Let's say you have such a big inheritance hierarchy, with overloads spread across it.
>>
>> I appreciate that you can write tools to analyze it. I think they help a lot in writing the code, but I don't think they are as helpful for auditing (code review).
>>
>> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.
> 
> I think it's the opposite. In every workplace I've been, people can't live with a decent IDE.

For most things I do just fine without an IDE.  For all my work with D, PHP, ... well nearly everything, I use EditPlus which provides next to nothing beyond very basic keyword highlighting.  Its enough.  :) (Actually he added simplistic code folding in the last release... that I do like, but I digress.)  For Ruby I use SciTE which is little more than a glorified notepad/edit with respectably elaborate highlighting.  (I use that for Ruby because it can handle some special cases such as #{} expressions within strings.)

The only language I crave an IDE for... is Java.  Just for dot-code-completion, and then only because the standard library so such huge.  (Okay... so Ruby has a pretty extensive set as well, but its not so unapproachably big as Java's.)

That being said...  I do like to run tools to generate "meta-data" and other reports from code which I can use to review it.  Even to the extent of sometimes coding my own.  (Wrote a little thing to generate HTML files from a LambdaMOO database once.  Made working on a MOO a little saner.)

So I think the primary argument is still sound in favor of tools, although I'm slipping back toward neutrality on this matter of inheritance and overloading...  turns out Walter is right about one important thing at the very least: it can definitely be argued, and argued well, in either direction.  At least aliases are a quick and simple "fix".

What we really need is a fix for the problem of casting to a Base class "forgetting" overrides.  Maybe a change to how vtbls work?  Okay, an example:

class Base {
  int foo () { return 1; }
}

class Derived : Base {
  override int foo () { return 2; }
}

What I'm thinking, is that Derived's copy of Base's vtbl should have the pointer for .foo replaced with a pointer to its override.  That way, when cast to Base the entry still points to Derived's method.  Assuming the vtbl is prepared at compile-time, this shouldn't cause any runtime issues... should it?

-- Chris Nicholson-Sauls

Jeff Nowakowski wrote:
> I think optimizing your language for vi and the printer is a dead-end. The vast majority of the time a developer is going to be working on his code on a computer using some tool.  If a tool lets you make use of a big productivity feature, then it makes sense to use it and officially endorse it as a basic requirement of the language.  Even vi users use tools like grep and ctags.

Everyone uses different tools, and particular tools may not be available  on all platforms D is on.

FWIW, a lot of hard core programmers still use vi.

Bruno Medeiros wrote:
> Walter Bright wrote:
>> I appreciate that you can write tools to analyze it. I think they help a lot in writing the code, but I don't think they are as helpful for auditing (code review).
>>
> 
> Auditing, as in someone review someone else's code?

Yes. This is done a lot in professional programming environments, and in particular in cases where high reliability/security is needed. C++ is a very expensive language to audit because of, for example, the nearly nonexistent modularity.

> Well, yes, in that case that tool functionality wouldn't be that useful (although other functionalities might be), however, auditing is a very specific situation, as well has it has lots of other difficulties which aren't easy to handle.

I think that when a language is more auditable, it is more attractive for uses that demand high reliability or security. Auditability has definitely been a goal of D since the beginning. I've worked with programmers from the corporate Java world who have told me about auditability problems with Java that makes their life much more difficult.

>> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.
> 
> "rarely used"?? Wait, what do you mean "add-on tools"? That functionality is part of JDT (the best (non-commercial) and most popular Java IDE), and similar functionality exists in other IDEs for other languages, so it's quite the opposite of rarely used.

Let me put it another way. How many people use a profiler? coverage analyser? Those tools are built-in, are extremely useful, yet are still rarely used.

Walter Bright wrote:
> Jeff Nowakowski wrote:
>> I think optimizing your language for vi and the printer is a dead-end. The vast majority of the time a developer is going to be working on his code on a computer using some tool.  If a tool lets you make use of a big productivity feature, then it makes sense to use it and officially endorse it as a basic requirement of the language.  Even vi users use tools like grep and ctags.
> 
> Everyone uses different tools, and particular tools may not be available  on all platforms D is on.
> 
> FWIW, a lot of hard core programmers still use vi.

I use emacs at work.  Sun Studio (the obvious alternative) is too slow and I don't care about any of the features it offers over a plain text editor combined with command-line tools (grep, etc).


Sean

Reply to Chris Nicholson-Sauls,

> What we really need is a fix for the problem of casting to a Base
> class "forgetting" overrides.  Maybe a change to how vtbls work?
> Okay, an example:
> 
> class Base {
> int foo () { return 1; }
> }
> class Derived : Base {
> override int foo () { return 2; }
> }
> What I'm thinking, is that Derived's copy of Base's vtbl should have
> the pointer for .foo replaced with a pointer to its override.  That
> way, when cast to Base the entry still points to Derived's method.
> Assuming the vtbl is prepared at compile-time, this shouldn't cause
> any runtime issues... should it?
> 

Unless I'm totally misreading you, that IS how it works.

Reply to Walter,

> Bruno Medeiros wrote:
> 
>> Walter Bright wrote:
>> 
>>> 4) Having overloads spread across the inheritance hierarchy makes
>>> the source code resistant to visual audits. For any method call,
>>> you'll have to look at EVERY base class to see if it has an overload
>>> that is a better match.
>>> 
>> I'm not sure if you've seen my other reply to this argument, but let
>> be more explicit, with pictures. Let's say you have such a big
>> inheritance hierarchy, with overloads spread across it.
>> 
> I appreciate that you can write tools to analyze it. I think they help
> a lot in writing the code, but I don't think they are as helpful for
> auditing (code review).
> 
> Another problem with them is they are not part of the D compiler
> itself, and in my experience add on tools rarely get used, no matter
> how useful they are.
> 


In code review, you may have a point. In writing code? Now that is one thing Microsoft got RIGHT!! Visual Studio rocks in that regard.

Now it they just had a feature that (automatically without me asking for it) gives me a list of cases where a code change resulted in a different overload resolution... It would make a nice feature in a diff tool as well.

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>
>>> 4) Having overloads spread across the inheritance hierarchy makes the source code resistant to visual audits. For any method call, you'll have to look at EVERY base class to see if it has an overload that is a better match.
>>>
>>
>> I'm not sure if you've seen my other reply to this argument, but let be more explicit, with pictures. Let's say you have such a big inheritance hierarchy, with overloads spread across it.
> 
> I appreciate that you can write tools to analyze it. I think they help a lot in writing the code, but I don't think they are as helpful for auditing (code review).
> 
> Another problem with them is they are not part of the D compiler itself, and in my experience add on tools rarely get used, no matter how useful they are.

It might be neat to define an API for the compiler.  I mean an api that would let you write programs that link to d-compiler.lib to do various things like get an AST etc.  I know D syntax tries to be easy to parse, but why not just have the spec also specify an api for would-be D compilers.  Giving a compiler a well defined API is not really something specific to D but it would make a lot of things easier.

--bb