On 09/03/2011 12:22, Gareth Charnock wrote:
<snip>
> Which meant I had to look up what the default values of pos,size and style where even
> though I was happy with those default values. The more arguments the more of a pain this
> setup is without named arguments. Contrast to a hypothetical C++ syntax:
>
> new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")
<snip>

This isn't hypothetical C++ syntax, it's perfectly legal C++ syntax.  It is equivalent to

    name = "My Custom Name str", new wxFrame(a_parent, wxANY, "Hello world", name)

Struct and array initialisers use a colon, not an equals sign, and if we add named arguments they would need to do the same to avoid changing the meaning of existing code. You may be just illustrating the concept and not proposing this as the actual syntax to add to C++ or D, but being careful now will help you to get used to the feature when/if it arrives.

Stewart.

On 09/03/2011 17:20, Steven Schveighoffer wrote:
> On Wed, 09 Mar 2011 09:02:14 -0500, Bruno Medeiros
> <brunodomedeiros+spam@com.gmail> wrote:
>
>> Although in the particular cased of named arguments, I still don't
>> feel it is worthwhile. Not unless it could be done in a very
>> orthogonal way (both in semantics and syntax), and even so it should
>> likely be very low priority (as in, not any time soon...).
>
> It's one of those things where, in some cases, not having named
> arguments makes code unreadable. But having named arguments does not
> make *all* code more readable. In many many cases, code is readable just
> fine without using the named arguments.
>
> But those cases where it does help, it's essential. Like Don's
> CreateFont example (actually almost any GUI function).
>
> We might do something like require explicit comments for confusing
> functions like:
>
> foo(
> null, // paramA
> null, // paramB
> null, // paramC
> );
>
> during the review process. It would at least document properly what is
> happening.
>
> I see not too much value in the "skip default parameter" prospect, most
> code can do fine without that via overloading. But the documentation and
> compiler verification of parameter names is what I see as the killer
> feature here.
>
>>>> B) If the pull request is large, it should be near effortless to put
>>>> those changes in the IDE and review them there.
>>>
>>> Again, don't have one.
>>>
>>> -Steve
>>
>> Just because you don't have or don't use an IDE, that is not an
>> argument against doing B).
>
> It absolutely is. I use NetBeans for doing php development. It took me
> hours and hours to set it up properly, install the right add-ons, etc.
> I'm not about to do that for something like descent or DDT so I can
> properly read code, I'm way more likely to just go look up the function
> signature myself for the few times I need it.
>
> Just having the named arguments idea makes so much more sense than
> having to load a specialized (and I might add, way overkill for just
> reviewing code in both size and complexity) tool.
>

Now that is an argument. Although I still don't agree: it really shouldn't take that long to setup an IDE (if Netbeans and/or its PHP plugin are crappy, don't use that to blame all IDEs :P ). But in any case this is kinda besides the point, because setting up an IDE is a one-time affair (reviewing code is many-times).

For small changes, yeah, it might be overkill to fire up an IDE. However I think the ideal solution in this issue is to bring a bit more IDE functionality to the web. There are already some projects loosely related to this underway, for example Orion (http://adtmag.com/articles/2011/03/21/eclipse-orion-hub.aspx ) from the Eclipse Foundation, of which Github is one of the involved parties.

But for bigger changes (in fact even for smaller ones as well) it might be worthwhile to use an IDE tool, because it can offer a lot of help in navigation and other stuff related to reviewing the code. I mean, the named arguments only address a very limited problem in reviewing code: it only tells you which parameter corresponds each argument. But what if you need to read the function's documentation to know or remind yourself what the function does, if the arguments have correct values, respect the contract, etc.? You'll likely need to open the function declaration in any case, in one way or another.


-- 
Bruno Medeiros - Software Engineer

On 23/03/2011 16:12, Bruno Medeiros wrote:
>
> But for bigger changes (in fact even for smaller ones as well) it might
> be worthwhile to use an IDE tool, because it can offer a lot of help in
> navigation and other stuff related to reviewing the code. I mean, the
> named arguments only address a very limited problem in reviewing code:
> it only tells you which parameter corresponds each argument. But what if
> you need to read the function's documentation to know or remind yourself
> what the function does, if the arguments have correct values, respect
> the contract, etc.? You'll likely need to open the function declaration
> in any case, in one way or another.
>
>

Actually... what if you want to make sure it compiles? Or to run unit tests? Or just run and test it manually? You can't do any of those on the web.
If you are just commenting on changes it might be fine, but if you are the one approving the code changes, I can hardly see how you can escape those tasks above (other than for very simple one-line changes), and thus the use of local tools.

-- 
Bruno Medeiros - Software Engineer

On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
>
> Now that is an argument. Although I still don't agree: it really
> shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
> plugin are crappy, don't use that to blame all IDEs :P ). But in any
> case this is kinda besides the point, because setting up an IDE is a
> one-time affair (reviewing code is many-times).

There is far more cost involved in using an IDE than the setup time.  A typical IDE will:

- Consume a relatively large chunk of space.  Visual Studio on my system takes up 1.9 GB, with one of the platform SDKs taking up an additional 565 MB.  XCode on my other system eats up a whopping 9.7 GB (!) with the iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the .dmg file).  Eclipse puts them both to shame at 268 MB for Eclipse Classic, with the JDK adding 179 MB on top of that.  (I only use Eclipse for Android development, so I haven't installed anything beyond the base classic package.)  For D development, I use Notepad++, which is just an editor -- 11.8 MB (plus 105 MB for dmd and associated tools).

- Hijack file extensions.  I have several versions of Visual Studio installed that all cooperate very nicely with each other, but if I were to install Eclipse for C/C++ development, I'd have to remember to tell it not to take over handling for .c/.cpp files.  This isn't such a big deal if the IDE only handles one or two languages, but if it's a multi-language IDE, then there may be a list of twenty or more file types to scroll through, assuming that the installer is even nice enough to let you choose.

- Have its own shortcuts, features, and quirks.  In Visual Studio, I can hit tab to confirm intellisense suggestions.  If I do the same thing in Eclipse, then I end up shifting focus over to the documentation popup window, which is just maddeningly stupid.  XCode doesn't give me a list; it just inserts its suggestion inline, and then I have to either hit escape or keep typing if I want something else entirely.  (XCode's suggestions also seem to be highly non-deterministic in nature; I think their algorithm would make for a great prng.)  Build in Visual Studio is F7.  In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This can be mitigated in most cases by changing key bindings, but now you're looking at either a short list of commands that can be changed (which might not include the command you're looking for), or a very, *very* long list with hundreds of commands that you have to wade through.  What's more, you have to figure out what name the IDE gives to the feature you're looking for, and it may not always be clear.  Eclipse provides a search bar to make it easier; good thing, too, because typing "content assist" into that bar gives me back *21 different entries*!

- Have its own unique, non-portable project format.  Some IDEs can work with makefiles, but even most of those don't actually use a makefile as its preferred project format.  This means that if you're looking at different projects from n different people/groups, you may need O(log(n)) different IDEs just to be able to open up their project.  On the flip side, if you're the author of a project and you want people to be able to use their favorite IDE, then you have to provide several different sets of project configuration files.  At least with makefiles, other people can build your project from the command-line without installing your favorite IDE.  (Same goes for Visual Studio project files, actually; you can build those from the command line with MSBuild without having to install Visual Studio.)

Lastly, at this point, D just doesn't have much in the line of support from major IDEs.  There are neat projects like Descent and VisualD, but that's hardly the breadth or scope of support that you'd get with an established, highly-visible language.  IDEs are simply not part of the language specification, and the language shouldn't be designed under the assumption that everyone's going to use an IDE, especially if you're thinking about a particular feature which many IDEs might not even have.

Don't get me wrong -- I love IDEs.  They can be very helpful, especially when it comes to dependency tracking and assisted editing.  Right now, I use Notepad++ for D because I don't feel that the existing alternatives really offer that much useful functionality beyond what that editor provides.  I'm working on some MSBuild tasks to make the process easier (yes, I develop primarily in Windows), and the IDE story will get better, but these things take a lot of time to fully materialize.

Am 24.03.2011 07:36, schrieb Bekenn:
> On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
>>
>> Now that is an argument. Although I still don't agree: it really
>> shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
>> plugin are crappy, don't use that to blame all IDEs :P ). But in any
>> case this is kinda besides the point, because setting up an IDE is a
>> one-time affair (reviewing code is many-times).
>
> There is far more cost involved in using an IDE than the setup time. A
> typical IDE will:
>
> - Consume a relatively large chunk of space. Visual Studio on my system
> takes up 1.9 GB, with one of the platform SDKs taking up an additional
> 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the
> iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the
> .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse
> Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse
> for Android development, so I haven't installed anything beyond the base
> classic package.) For D development, I use Notepad++, which is just an
> editor -- 11.8 MB (plus 105 MB for dmd and associated tools).
>

9,7GB is pretty much.. but how much of that is iOS SDK stuff?
However: Eclipse is pretty bloated and still only uses <300MB in your configuration..
And in times of multiple Terabyte Harddisks a few hundred MBs (or even a 2-3GBs) for an IDE is not really a problem.

> - Hijack file extensions. I have several versions of Visual Studio
> installed that all cooperate very nicely with each other, but if I were
> to install Eclipse for C/C++ development, I'd have to remember to tell
> it not to take over handling for .c/.cpp files. This isn't such a big
> deal if the IDE only handles one or two languages, but if it's a
> multi-language IDE, then there may be a list of twenty or more file
> types to scroll through, assuming that the installer is even nice enough
> to let you choose.
>

This can happen with normal text editors as well and is more an issue of crappy IDEs that do this stuff without asking you than with IDEs in general.

> - Have its own shortcuts, features, and quirks. In Visual Studio, I can
> hit tab to confirm intellisense suggestions. If I do the same thing in
> Eclipse, then I end up shifting focus over to the documentation popup
> window, which is just maddeningly stupid. XCode doesn't give me a list;
> it just inserts its suggestion inline, and then I have to either hit
> escape or keep typing if I want something else entirely. (XCode's
> suggestions also seem to be highly non-deterministic in nature; I think
> their algorithm would make for a great prng.) Build in Visual Studio is
> F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This
> can be mitigated in most cases by changing key bindings, but now you're
> looking at either a short list of commands that can be changed (which
> might not include the command you're looking for), or a very, *very*
> long list with hundreds of commands that you have to wade through.
> What's more, you have to figure out what name the IDE gives to the
> feature you're looking for, and it may not always be clear. Eclipse
> provides a search bar to make it easier; good thing, too, because typing
> "content assist" into that bar gives me back *21 different entries*!
>

The same happens with normal editors, vi and emacs have totally different shortcuts.

Cheers,
- Daniel

On 24/03/2011 06:36, Bekenn wrote:
> On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
>>
>> Now that is an argument. Although I still don't agree: it really
>> shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
>> plugin are crappy, don't use that to blame all IDEs :P ). But in any
>> case this is kinda besides the point, because setting up an IDE is a
>> one-time affair (reviewing code is many-times).
>
> There is far more cost involved in using an IDE than the setup time. A
> typical IDE will:
>
> - Consume a relatively large chunk of space. Visual Studio on my system
> takes up 1.9 GB, with one of the platform SDKs taking up an additional
> 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the
> iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the
> .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse
> Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse
> for Android development, so I haven't installed anything beyond the base
> classic package.) For D development, I use Notepad++, which is just an
> editor -- 11.8 MB (plus 105 MB for dmd and associated tools).
>
> - Hijack file extensions. I have several versions of Visual Studio
> installed that all cooperate very nicely with each other, but if I were
> to install Eclipse for C/C++ development, I'd have to remember to tell
> it not to take over handling for .c/.cpp files. This isn't such a big
> deal if the IDE only handles one or two languages, but if it's a
> multi-language IDE, then there may be a list of twenty or more file
> types to scroll through, assuming that the installer is even nice enough
> to let you choose.
>
> - Have its own shortcuts, features, and quirks. In Visual Studio, I can
> hit tab to confirm intellisense suggestions. If I do the same thing in
> Eclipse, then I end up shifting focus over to the documentation popup
> window, which is just maddeningly stupid. XCode doesn't give me a list;
> it just inserts its suggestion inline, and then I have to either hit
> escape or keep typing if I want something else entirely. (XCode's
> suggestions also seem to be highly non-deterministic in nature; I think
> their algorithm would make for a great prng.) Build in Visual Studio is
> F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This
> can be mitigated in most cases by changing key bindings, but now you're
> looking at either a short list of commands that can be changed (which
> might not include the command you're looking for), or a very, *very*
> long list with hundreds of commands that you have to wade through.
> What's more, you have to figure out what name the IDE gives to the
> feature you're looking for, and it may not always be clear. Eclipse
> provides a search bar to make it easier; good thing, too, because typing
> "content assist" into that bar gives me back *21 different entries*!
>
> - Have its own unique, non-portable project format. Some IDEs can work
> with makefiles, but even most of those don't actually use a makefile as
> its preferred project format. This means that if you're looking at
> different projects from n different people/groups, you may need
> O(log(n)) different IDEs just to be able to open up their project. On
> the flip side, if you're the author of a project and you want people to
> be able to use their favorite IDE, then you have to provide several
> different sets of project configuration files. At least with makefiles,
> other people can build your project from the command-line without
> installing your favorite IDE. (Same goes for Visual Studio project
> files, actually; you can build those from the command line with MSBuild
> without having to install Visual Studio.)
>
> Lastly, at this point, D just doesn't have much in the line of support
> from major IDEs. There are neat projects like Descent and VisualD, but
> that's hardly the breadth or scope of support that you'd get with an
> established, highly-visible language. IDEs are simply not part of the
> language specification, and the language shouldn't be designed under the
> assumption that everyone's going to use an IDE, especially if you're
> thinking about a particular feature which many IDEs might not even have.
>
> Don't get me wrong -- I love IDEs. They can be very helpful, especially
> when it comes to dependency tracking and assisted editing. Right now, I
> use Notepad++ for D because I don't feel that the existing alternatives
> really offer that much useful functionality beyond what that editor
> provides. I'm working on some MSBuild tasks to make the process easier
> (yes, I develop primarily in Windows), and the IDE story will get
> better, but these things take a lot of time to fully materialize.

Well, now we go back to discussion of the discussion of whether one thinks it's worthwhile to use and IDE or not (for general development, not just code reviews).
I don't want to go into this discussion again, at least not now so soon. I think that what we all may take from the discussion I was having from Steven right now, and maybe everyone agree with, is that whether it's worthwhile to use an IDE for code reviews is reduced to the discussion of whether it's worthwhile to use an IDE generally or not. In other words, if you don't do the tasks I mentioned before (looking up documentation, compiling and running code, running tests. also, using the source control system) from inside the IDE when developing yourself, you will definitely won't want to use it when code reviewing, accepting patches, etc..


-- 
Bruno Medeiros - Software Engineer

On Thu, 24 Mar 2011 10:33:28 -0400, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> Well, now we go back to discussion of the discussion of whether one thinks it's worthwhile to use and IDE or not (for general development, not just code reviews).
> I don't want to go into this discussion again, at least not now so soon. I think that what we all may take from the discussion I was having from Steven right now, and maybe everyone agree with, is that whether it's worthwhile to use an IDE for code reviews is reduced to the discussion of whether it's worthwhile to use an IDE generally or not. In other words, if you don't do the tasks I mentioned before (looking up documentation, compiling and running code, running tests. also, using the source control system) from inside the IDE when developing yourself, you will definitely won't want to use it when code reviewing, accepting patches, etc..

Building on that, I'll actually put it another way:

Without netbeans, I would be twice as slow with php development.  Being a non-static language, with so many little quirks and annoyances that come with, I find netbeans' features essential (my most favorite is the recent ability to "type" object variables so you can look at the documented members).  In fact, I'd be way more likely to install a D for netbeans plugin than I would to install another IDE specifically for D.

But with D, I find the online documentation and included tools "good enough" for most development.  I'm also way more familiar with D's library than I am with php's.

I don't know if it's a good apples-to-apples comparison, but I simply feel no need to have an IDE to read D code.  I don't feel the same way about php :)  Having named arguments would add to that feeling of comfort, I believe.

-Steve

P.S. I've tried two D ides in the past for about 10 minutes (descent and code::blocks), could not get either of them to work right.  And it was *not* trivial to set them up.

On Thu, Mar 24, 2011 at 3:23 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Thu, 24 Mar 2011 10:33:28 -0400, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>
>> Well, now we go back to discussion of the discussion of whether one thinks
>> it's worthwhile to use and IDE or not (for general development, not just
>> code reviews).
>> I don't want to go into this discussion again, at least not now so soon. I
>> think that what we all may take from the discussion I was having from Steven
>> right now, and maybe everyone agree with, is that whether it's worthwhile to
>> use an IDE for code reviews is reduced to the discussion of whether it's
>> worthwhile to use an IDE generally or not. In other words, if you don't do
>> the tasks I mentioned before (looking up documentation, compiling and
>> running code, running tests. also, using the source control system) from
>> inside the IDE when developing yourself, you will definitely won't want to
>> use it when code reviewing, accepting patches, etc..
>
> Building on that, I'll actually put it another way:
>
> Without netbeans, I would be twice as slow with php development.  Being a non-static language, with so many little quirks and annoyances that come with, I find netbeans' features essential (my most favorite is the recent ability to "type" object variables so you can look at the documented members).  In fact, I'd be way more likely to install a D for netbeans plugin than I would to install another IDE specifically for D.
>
> But with D, I find the online documentation and included tools "good enough" for most development.  I'm also way more familiar with D's library than I am with php's.
>
> I don't know if it's a good apples-to-apples comparison, but I simply feel no need to have an IDE to read D code.  I don't feel the same way about php :)  Having named arguments would add to that feeling of comfort, I believe.
>
> -Steve
>
> P.S. I've tried two D ides in the past for about 10 minutes (descent and code::blocks), could not get either of them to work right.  And it was *not* trivial to set them up.
>

I would make the argument that once you started working with a D IDE with enough features, you'd probably find yourself addicted to it as you are with PHP and Netbeans. At least, that's been my experience across just about every language I've coded in.

On Thu, 24 Mar 2011 23:39:30 -0400, Andrew Wiley <debio264@gmail.com> wrote:

> I would make the argument that once you started working with a D IDE
> with enough features, you'd probably find yourself addicted to it as
> you are with PHP and Netbeans. At least, that's been my experience
> across just about every language I've coded in.

/me likes my vi :)  I know ides can mimic vi, or use vi directly to edit, but for most purposes, vi + online docs suits my style well.

I don't dislike IDEs per se, I've used Visual Studio quite a bit and I like it, though it's not supported on my current OS (Linux).  I also think NetBeans is pretty good, it certainly makes php coding more enjoyable.

But I will never, ever install an IDE for the sole purpose of reviewing code.  And I don't see the problem with making code more understandable without an IDE.  The point that named parameters a "useless" feature because IDEs already take care of that is what I disagree with, not that IDEs are useful.

-Steve

On 24/03/2011 20:23, Steven Schveighoffer wrote:
>
> P.S. I've tried two D ides in the past for about 10 minutes (descent and
> code::blocks), could not get either of them to work right. And it was
> *not* trivial to set them up.


I must invite you try out DDT :D , even you don't stick to using it aferward. It should be no more than 5 minutes to setup (download times excluding):
http://code.google.com/a/eclipselabs.org/p/ddt/wiki/UserGuide

*fingers crossed*

-- 
Bruno Medeiros - Software Engineer