Koroskin Denis:
> As a gentoo user when I compile something (and I do it alot :p ) I expect two messages: "build finished" *or* "build failed for the following reason: ...". All those warning are *not for me*, they are for developers and needed during development time only. Imagine you are updating a web-browser or some other application and get all those "comparison between signed and unsigned types" messages. Do you want to read them?

Then if you build things to just use them quickly, then you may want to omit putting -Wall there...

Bye,
bearophile

Koroskin Denis wrote:
> On Sun, 27 Jul 2008 17:56:01 +0400, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
> 
>> Walter Bright wrote:
>>> Nick Sabalausky wrote:
>>>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to.
>>>  The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
>>>  So, why not just turn off the warnings?
>>>  The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. If you're faced with compiling someone else's code (like you downloaded it off the internet and have to compile it because it only is distributed as source) and warnings go off, is that a bug in the code or not? What do you do?
>>>
>>
>> You have a distorted notion of warnings. Warnings are not errors (and by corollary are not "optional errors" also). They are simply messages which indicate some "strange" situations in code, which suggest some attention from the developer (now or in the future).
>> That's why other compilers have an *option* such as "treat-warnings-as-errors". If they were errors, they wouldn't need that option, cause they would already be treated as errors (cause they would *be* errors...), lol. :(
>>
>> You (Walter) and other people, may be inclined to disagree, especially if you are heavily biased torwards C++, where warnings, like you said, have been used for *things that should have been errors*, and have created this whole messed up and confused situations, and scenarios where people think C++ code should compile without errors, etc., etc.. But that is just a scenario arising from C++ fucked-up-ness.
>>
>> If you (and others) still don't agree, which you probably won't, then let's not argue semantics, and just call this notion of warnings that I defined before as "cautions".
>> _ With this in mind, what's wrong with the compiler generating messages (and just messages, not errors) for certain suspicious code situations, such as unused variables? Just that, what do you say? _
>>
>>
> 
> Now I agree with Walter on that matter. Compiler's job is to compile an executable. As a gentoo user when I compile something (and I do it alot :p ) I expect two messages: "build finished" *or* "build failed for the following reason: ...". All those warning are *not for me*, they are for developers and needed during development time only. Imagine you are updating a web-browser or some other application and get all those "comparison between signed and unsigned types" messages. Do you want to read them?
> 

I too was talking about development time only. If you're compiling as a user, then yes there should be an option that suppresses various output, warnings or not.

> OTOH, I want for my code to be constantly analyzed for suspicious situation but _only during development time_. That's why I use IDE. And my IDE should help me as I type: syntax highlighting, code autocomplete, refactoring *and* warnings. It's almost free for IDE to analyze my code for possible errors. But compiler's job is to compile *or* reject the code, and it should do it as fast as possible without spending time for looking into suspicious situations.
> 
> Compiler and IDE tasks do often overlap, of course, but it doesn't mean that they should be merged into single solution.
> 
> Just my $0.02...

Like you said, the compiler and IDE tasks overlap. In D's case, if DMD did a proper warning analysis, then an IDE could use the compiler to present warnings to the user in a proper manner (like squiggles in the source code editor). In Descent's case, it would be particularly easy to do that, since it has an embedded/ported DMD frontend, and already does the same for compiler errors.

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

Bruno Medeiros wrote:
> Koroskin Denis wrote:
>> On Sun, 27 Jul 2008 17:56:01 +0400, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>>
>>> Walter Bright wrote:
>>>> Nick Sabalausky wrote:
>>>>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to.
>>>>  The problem with unused variable warnings is they are annoying when
>>>> you're developing code in an iterative manner. They get in the way
>>>> when you're commenting out sections of code to try and isolate a
>>>> problem. They can be a problem when using "version" and "static if"
>>>> statements.
>>>>  So, why not just turn off the warnings?
>>>>  The problem with warnings is that if there are n warnings, there
>>>> are essentially n factorial different versions of the language. If
>>>> you're faced with compiling someone else's code (like you downloaded
>>>> it off the internet and have to compile it because it only is
>>>> distributed as source) and warnings go off, is that a bug in the
>>>> code or not? What do you do?
>>>>
>>>
>>> You have a distorted notion of warnings. Warnings are not errors (and by corollary are not "optional errors" also). They are simply messages which indicate some "strange" situations in code, which suggest some attention from the developer (now or in the future). That's why other compilers have an *option* such as "treat-warnings-as-errors". If they were errors, they wouldn't need that option, cause they would already be treated as errors (cause they would *be* errors...), lol. :(
>>>
>>> You (Walter) and other people, may be inclined to disagree, especially if you are heavily biased torwards C++, where warnings, like you said, have been used for *things that should have been errors*, and have created this whole messed up and confused situations, and scenarios where people think C++ code should compile without errors, etc., etc.. But that is just a scenario arising from C++ fucked-up-ness.
>>>
>>> If you (and others) still don't agree, which you probably won't, then
>>> let's not argue semantics, and just call this notion of warnings that
>>> I defined before as "cautions".
>>> _ With this in mind, what's wrong with the compiler generating
>>> messages (and just messages, not errors) for certain suspicious code
>>> situations, such as unused variables? Just that, what do you say? _
>>>
>>>
>>
>> Now I agree with Walter on that matter. Compiler's job is to compile an executable. As a gentoo user when I compile something (and I do it alot :p ) I expect two messages: "build finished" *or* "build failed for the following reason: ...". All those warning are *not for me*, they are for developers and needed during development time only. Imagine you are updating a web-browser or some other application and get all those "comparison between signed and unsigned types" messages. Do you want to read them?
>>
> 
> I too was talking about development time only. If you're compiling as a user, then yes there should be an option that suppresses various output, warnings or not.
> 
>> OTOH, I want for my code to be constantly analyzed for suspicious situation but _only during development time_. That's why I use IDE. And my IDE should help me as I type: syntax highlighting, code autocomplete, refactoring *and* warnings. It's almost free for IDE to analyze my code for possible errors. But compiler's job is to compile *or* reject the code, and it should do it as fast as possible without spending time for looking into suspicious situations.
>>
>> Compiler and IDE tasks do often overlap, of course, but it doesn't mean that they should be merged into single solution.
>>
>> Just my $0.02...
> 
> Like you said, the compiler and IDE tasks overlap. In D's case, if DMD did a proper warning analysis, then an IDE could use the compiler to present warnings to the user in a proper manner (like squiggles in the source code editor). In Descent's case, it would be particularly easy to do that, since it has an embedded/ported DMD frontend, and already does the same for compiler errors.
> 

Even better would be to have something like clang which offers a collection of libs (codegen, semantic analysis, parsing, etc..) and an API for each lib. that way the descent folks could have just used the semantic analysis and parser DLLs of the compiler and the respective APIs instead of having to port the DMD frontend from c++ to Java. I think Ary wrote here once that he had to replace all the gotos with exceptions or something like that. That doesn't sound good or maintainable to me..

Yigal Chripun wrote:
> 
> Even better would be to have something like clang which offers a
> collection of libs (codegen, semantic analysis, parsing, etc..) and an
> API for each lib. that way the descent folks could have just used the
> semantic analysis and parser DLLs of the compiler and the respective
> APIs instead of having to port the DMD frontend from c++ to Java. I
> think Ary wrote here once that he had to replace all the gotos with
> exceptions or something like that. That doesn't sound good or
> maintainable to me..

*How* an IDE uses the compiler to perform analysis is another story. Right now the point is simply that it would be nice if the compiler (DMD) had more analysis functionality.


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

Bruno Medeiros Wrote:

> Before some people here say they don't use an IDE, but instead use <editor foo with syntax highlighting and little more than that> and are fine with it,

I would say that the reason developers still prefer to code with text editors rather than IDE's is they find the text editor more productive. Eclipse based IDE are just far too slow for a good developer's fingers.

When you're used to a super quick, highly responsive editor, it can be terribly frustrating to have you step down to a slow IDE.

The slowness of the keyboard response turns what was an automatic action, that of typing, into a though process and this plays havoc with the 'thinking about the code while I type' through process.

> If you were in a multi-team, 6+ months project, working with such tools, do you think you would perform the same as the same team, with a proper toolchain?

Yes.

I would say team of 'editor based programmers' would be far more productive than a team o 'IDE based programmers'. The simple fact that the editor programmer can code outside the IDE immediately means they have a better understanding of there coding environment and their toolchain.

There is nothing more pathetic than to watch an IDE programmer turn
into a quivering mess, just because they can't find the answer to
simple questions like:

  Why does my program run fine in the IDE but not
  outside the IDE?

Jussi Jumppanen wrote:
> Bruno Medeiros Wrote:
> 
>> Before some people here say they don't use an IDE, but instead use <editor foo with syntax highlighting and little more than that> and are fine with it, 
> 
> I would say that the reason developers still prefer to code with text editors rather than IDE's is they find the text editor more productive. Eclipse based IDE are just far too slow for a good developer's fingers.
> 
> When you're used to a super quick, highly responsive editor, it can be terribly frustrating to have you step down to a slow IDE. 
> 
> The slowness of the keyboard response turns what was an automatic action, that of typing, into a though process and this plays havoc with the 'thinking about the code while I type' through process.

Bullshit. Do you have a 200 MhZ Pentium with 128MB RAM? Even then, IDEs are going to prioritize the editor itself over any autocomplete/background processing, so the editor shouldn't be any less responsive. It might take 5 seconds if you click "go to definition" and it has to open a new file, but that's vs 2 minutes of searching for an import, finding the file location, and using find to get to the definition in that file.

The issue is the placebo effect and the comfort zone... which are real issues (that's why so many people are like "oh, Vista is soooo bloated compared to XP"...). If you've been using ed to write code for the last 30 years, the mental concept of using your $2000 computer to its full potential to help you write software is mind-boggling. If you're more comfortable with your "power-editor" or just can't deal with a 1-minute startup time for a product you're going to be using for 8 hours, well all the more power to ya; no amount of productivity gains could make you willing to switch.

I'm not saying "more complex is always better," but why let all that processing power go to waste?

On Mon, Jul 28, 2008 at 11:15 AM, Robert Fraser <fraserofthenight@gmail.com>wrote:

> Jussi Jumppanen wrote:
>
>> Bruno Medeiros Wrote:
>>
>>  Before some people here say they don't use an IDE, but instead use
>>> <editor foo with syntax highlighting and little more than that> and are fine with it,
>>>
>>
>> I would say that the reason developers still prefer to code with text editors rather than IDE's is they find the text editor more productive. Eclipse based IDE are just far too slow for a good developer's fingers.
>>
>> When you're used to a super quick, highly responsive editor, it can be
>> terribly frustrating to have you step down to a slow IDE.
>> The slowness of the keyboard response turns what was an automatic action,
>> that of typing, into a though process and this plays havoc with the
>> 'thinking about the code while I type' through process.
>>
>
> Bullshit. Do you have a 200 MhZ Pentium with 128MB RAM? Even then, IDEs are going to prioritize the editor itself over any autocomplete/background processing, so the editor shouldn't be any less responsive. It might take 5 seconds if you click "go to definition" and it has to open a new file, but that's vs 2 minutes of searching for an import, finding the file location, and using find to get to the definition in that file.
>
> The issue is the placebo effect and the comfort zone... which are real issues (that's why so many people are like "oh, Vista is soooo bloated compared to XP"...). If you've been using ed to write code for the last 30 years, the mental concept of using your $2000 computer to its full potential to help you write software is mind-boggling. If you're more comfortable with your "power-editor" or just can't deal with a 1-minute startup time for a product you're going to be using for 8 hours, well all the more power to ya; no amount of productivity gains could make you willing to switch.
>
> I'm not saying "more complex is always better," but why let all that processing power go to waste?
>

I think part of the problem is that there are a whole lot of IDEs that really don't live up to the potential you guys are talking about.  Plus IDEs come with their own set of problems.  For instance I just wasted most of a day getting a MSVC7 project set up to also work with MSVC9.  That's just ridiculous.  Microsoft goes and makes these minor changes to their project file formats for every release of Visual Studio, and then only provide a tool to do 1-way, in-place upgrades of all your project files.  It's insane.  Just imagine if you were forced to fork your makefiles for every dang version of GCC that comes out.  The way project management works in IDEs is often just completely silly like that.

The so called "Intellisense" in Visual Studio also has historically been pretty lame, with refactoring support basically non-existant.  The Visual Assist add-on from Whole Tomato was pretty much a "must" to bring it up to snuff.  I get the impression that the Java IDEs offer a lot more on the refactoring frontier.  So that's just to say, it's easy to get the impression that IDEs are not useful because there are many IDEs that genuinely are not that useful.  I can see where Jussi is coming from.  I have a feeling when Brunos says "IDE" he's thinking of IDEs at their very best.  Not another one of these lame editors with syntax highlighting and a "compile" button that claims to be an IDE.

I still primarily like to use my good ole emacs for writing large amounts of new code.  There I don't find all the little buttons and completion popups and things in an IDE very useful.  But when it comes to debugging and fixing code, damn it's nice to have the IDE there with all it's quick cross-linking abilities.  The integrated debugger in MSVC is also damn fine.

--bb

Jussi Jumppanen a écrit :
> Bruno Medeiros Wrote:
> 
>> Before some people here say they don't use an IDE, but instead use <editor foo with syntax highlighting and little more than that> and are fine with it, 
> 
> I would say that the reason developers still prefer to code with text editors rather than IDE's is they find the text editor more productive. Eclipse based IDE are just far too slow for a good developer's fingers.

In Eclipse there's a time delay you can configure before autocompletion proposals appear (by default 200ms). That means that if you are faster than that delay (your claim), the IDE won't help you. Buf if you do wait a little, probably because you don't know what all the possible autocompletions are, then it will show the popup with suggestions.

I can't see how that is worse than not having autocompletion at all, plus not having go-to-definition or semantic highlighting.

Bill Baxter Wrote:

> On Mon, Jul 28, 2008 at 11:15 AM, Robert Fraser <fraserofthenight@gmail.com>wrote:
> 
> > Jussi Jumppanen wrote:
> >
> >> Bruno Medeiros Wrote:
> >>
> >>  Before some people here say they don't use an IDE, but instead use
> >>> <editor foo with syntax highlighting and little more than that> and are fine with it,
> >>>
> >>
> >> I would say that the reason developers still prefer to code with text editors rather than IDE's is they find the text editor more productive. Eclipse based IDE are just far too slow for a good developer's fingers.
> >>
> >> When you're used to a super quick, highly responsive editor, it can be
> >> terribly frustrating to have you step down to a slow IDE.
> >> The slowness of the keyboard response turns what was an automatic action,
> >> that of typing, into a though process and this plays havoc with the
> >> 'thinking about the code while I type' through process.
> >>
> >
> > Bullshit. Do you have a 200 MhZ Pentium with 128MB RAM? Even then, IDEs are going to prioritize the editor itself over any autocomplete/background processing, so the editor shouldn't be any less responsive. It might take 5 seconds if you click "go to definition" and it has to open a new file, but that's vs 2 minutes of searching for an import, finding the file location, and using find to get to the definition in that file.
> >
> > The issue is the placebo effect and the comfort zone... which are real issues (that's why so many people are like "oh, Vista is soooo bloated compared to XP"...). If you've been using ed to write code for the last 30 years, the mental concept of using your $2000 computer to its full potential to help you write software is mind-boggling. If you're more comfortable with your "power-editor" or just can't deal with a 1-minute startup time for a product you're going to be using for 8 hours, well all the more power to ya; no amount of productivity gains could make you willing to switch.
> >
> > I'm not saying "more complex is always better," but why let all that processing power go to waste?
> >
> 
> I think part of the problem is that there are a whole lot of IDEs that really don't live up to the potential you guys are talking about.  Plus IDEs come with their own set of problems.  For instance I just wasted most of a day getting a MSVC7 project set up to also work with MSVC9.  That's just ridiculous.  Microsoft goes and makes these minor changes to their project file formats for every release of Visual Studio, and then only provide a tool to do 1-way, in-place upgrades of all your project files.  It's insane.  Just imagine if you were forced to fork your makefiles for every dang version of GCC that comes out.  The way project management works in IDEs is often just completely silly like that.
> 
> The so called "Intellisense" in Visual Studio also has historically been pretty lame, with refactoring support basically non-existant.  The Visual Assist add-on from Whole Tomato was pretty much a "must" to bring it up to snuff.  I get the impression that the Java IDEs offer a lot more on the refactoring frontier.  So that's just to say, it's easy to get the impression that IDEs are not useful because there are many IDEs that genuinely are not that useful.  I can see where Jussi is coming from.  I have a feeling when Brunos says "IDE" he's thinking of IDEs at their very best.  Not another one of these lame editors with syntax highlighting and a "compile" button that claims to be an IDE.
> 
> I still primarily like to use my good ole emacs for writing large amounts of new code.  There I don't find all the little buttons and completion popups and things in an IDE very useful.  But when it comes to debugging and fixing code, damn it's nice to have the IDE there with all it's quick cross-linking abilities.  The integrated debugger in MSVC is also damn fine.
> 
> --bb

VS is crap (when the VS team is using Source Insight to develop it, you know something is wrong...). Even Visual C# pales in comparison to what I can do with Eclipse + JDT for Java; you have to use ReSharper to get the functionality a real IDE can provide.

On Tue, Jul 29, 2008 at 2:56 AM, Robert Fraser <fraserofthenight@gmail.com>wrote:

> VS is crap (when the VS team is using Source Insight to develop it, you know something is wrong...). Even Visual C# pales in comparison to what I can do with Eclipse + JDT for Java; you have to use ReSharper to get the functionality a real IDE can provide.
>

Hmm, Brunos is an Eclipse fan too.  So maybe when you guys say "an IDE" you really mean "Eclipse+JDT for Java".  Are there any other IDEs, for any language, out there that you would deem acceptable?  Just curious.

--bb