On 28/02/2011 22:13, Steven Schveighoffer wrote:


> Dunno, vim doesn't do that for me currently.

I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.

> Also, if reviewing code on github, there is no ide.
>
> -Steve

A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so.
B) If the pull request is large, it should be near effortless to put those changes in the IDE and review them there.

-- 
Bruno Medeiros - Software Engineer

Bruno Medeiros:

> A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so.

Named arguments allow to improve the reading of code everywhere, in editors too.
Reading code in texts, emails, or online, is a common thing for me. I see every day pieces of code in this newsgroup. I suggest you to try to use for few months a language that allows named arguments.


>The question that should be asked is if D should be optimized for IDE usage or not...<

I think modern languages need to be designed to be aware of the existence of IDEs. So far the D design seems to ignore IDEs. On the other hand C# (and other languages) have or have added named arguments even if they are often used in IDEs.

Bye,
bearophile

On Tue, 08 Mar 2011 15:29:28 -0500, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> On 28/02/2011 22:13, Steven Schveighoffer wrote:
>
>
>> Dunno, vim doesn't do that for me currently.
>
> I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.
>
>  > Also, if reviewing code on github, there is no ide.
>  >
>  > -Steve
>
> A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so.

I contest that web based code reviewing is going to be infrequent, since all major phobos changes now must be reviewed by 2 peers before inclusion.

Please look at a recent pull request review I participated in, without ever opening an editor/ide.  GitHub provides very good collaborative review.  If I have to install an IDE that I only use for reviewing, um... no.

https://github.com/jmdavis/phobos/commit/aca1a2d7cfe7d5e934668e06028b78ffb6796245

> 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

On 3/8/2011 12:29 PM, Bruno Medeiros wrote:
> On 28/02/2011 22:13, Steven Schveighoffer wrote:
> 
> 
>> Dunno, vim doesn't do that for me currently.
> 
> I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.
> 
>> Also, if reviewing code on github, there is no ide.
>>
>> -Steve
> 
> A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like
> web-based code reviewing in github or whatever, or reading code in books? I doubt so.
> B) If the pull request is large, it should be near effortless to put those changes in the IDE and review them there.
> 

Personally, I spend _way_ more time reading code (mine or other peoples) than I spend writing code.  Ignoring time, I also read far more lines/files/whatever code than I write.  I suspect these things are going to vary highly from person to person and from job role to job role.  Those that primarily produce new applications, tools, websites, etc and do little maintenance programming will be the polar opposite.

Regarding B, if a pull/review request is large, I'll likely send it back with instructions to break it into small pull requests.  Or at a minimum a series of small commits.  Gigantic lumps of code (particularly many separable changes all done at once) are just a bad idea no matter how you arrange it.

My 2 cents,
Brad

Named arguments are useful when you have a function that takes a large number of parameters, the vast majority of which have default values. For example, have a look at this constructor in wxWidgets:

http://docs.wxwidgets.org/trunk/classwx_frame.html#01b53ac2d4a5e6b0773ecbcf7b5f6af8

wxFrame::wxFrame	(	wxWindow * 	parent,
wxWindowID 	id,
const wxString & 	title,
const wxPoint & 	pos = wxDefaultPosition,
const wxSize & 	size = wxDefaultSize,
long 	style = wxDEFAULT_FRAME_STYLE,
const wxString & 	name = wxFrameNameStr	
)

If you want to change the name argument you need to call

new wxFrame(a_parent,wxANY,"Hello world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom name str")

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

I haven't bothered with the arguments I don't care about and my function call has ended up less sensitive to changes in the wxFrame constructor.

On 28/02/11 21:50, Jonathan M Davis wrote:
> On Monday, February 28, 2011 13:38:34 Don wrote:
>> spir wrote:
>>> On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
>>>> I'm not entirely against named arguments being in D, however I do
>>>> think that any
>>>> functions that actually need them should be refactored anyway.
>>
>> I agree.
>> CreateFont() in the Windows API, I'm looking at you. (For Linux people,
>> that function has about 12 parameters).
>>
>>> ???
>>>
>>>> In actuality, if I were to vote on whether named arguments should be
>>>> in the
>>>> language, I would definitely vote against it (I just plain don't want
>>>> the code
>>>> clutter,  [...]
>>>
>>> Just don't use them!
>>
>> You don't have that option. At least, if you're a library developer, you
>> don't. (I'm a bit sick of people saying "you don't have to use it if you
>> don't want to" in language design. If it is in the language, you don't
>> have a choice. You will encounter it).
>>
>> There are a couple of things that I really, really don't like about the
>> names argument idea:
>> 1. It makes parameter names part of the API.
>> Providing no way for the function writer to control whether it is part
>> of the API or not, and especially, doing it retrospectively, strikes me
>> as extremely rude.
>>
>> 2. It introduces a different syntax for calling a function.
>> foo(4, 5);
>> foo(x: 4, y: 5);
>> They look different, but they do exactly the same thing. I don't like
>> that redundancy.
>>
>>
>> Especially since, as far as I can tell, the named arguments are just
>> comments (which the compiler can check).
>> If so, a syntax like this would be possible, with no language change at
>> all:
>>
>> pragma(namedarguments); // applies to whole module
>>
>> foo(/*x*/ 4, /*y*/ 5);
>>
>> --->  if a function parameter has a comment which forms a valid
>> identifier, it's a named parameter.
>>
>> But I still don't see the need for this feature. Aren't people using
>> IDEs where the function signature (with parameter names) pops up when
>> you're entering the function, and when you move the mouse over the
>> function call?
>> And if you really want to see them all the time, why not build that
>> feature into the IDE?
>> ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
>
> I agree with pretty much everything said here. However, as I understand it,
> named parameters (at least as they work in Python) would allow for you to
> reorder parameters and give values for paramters which are normally default
> parameters without giving values for the default paramters before them, and
> those changes could not be dealt with by comments. However, I consider them to
> be a big _problem_, not a feature - _especially_ the ability to rearrange the
> function arguments. All of a sudden you could have
>
> foo(4, 5);
> foo(x : 4, y : 5);
> foo(y : 5, X : 4);
>
> all making _exactly_ the same function call. That seem _very_ bug-prone and
> confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, x :
> 4)? Not good. The amount of effort to understand the code becomes considerably
> higher. You could be very familiar with foo and know exactly what parameters it
> takes and totally mistake what it's really getting passed, because the arguments
> were flipped in comparison to the function parameters.
>
> I agree with Don. I think that named parameters would cause far more
> intellectual overhead and problems than they'd solve.
>
> - Jonathan M Davis
>
> - Jonathan M Davis

On 08/03/2011 21:37, Steven Schveighoffer wrote:
> On Tue, 08 Mar 2011 15:29:28 -0500, Bruno Medeiros
> <brunodomedeiros+spam@com.gmail> wrote:
>
>> On 28/02/2011 22:13, Steven Schveighoffer wrote:
>>
>>
>>> Dunno, vim doesn't do that for me currently.
>>
>> I feel tempted to say something very short and concise regarding vim
>> and emacs, but it would require a large amount of justification to
>> properly expose such point. I am planning to write a blog post about
>> that, but I haven't gotten to it yet.
>>
>> > Also, if reviewing code on github, there is no ide.
>> >
>> > -Steve
>>
>> A) Should we give any significant weight to very minute and relatively
>> infrequent code reading situations, like web-based code reviewing in
>> github or whatever, or reading code in books? I doubt so.
>
> I contest that web based code reviewing is going to be infrequent, since
> all major phobos changes now must be reviewed by 2 peers before inclusion.
>
> Please look at a recent pull request review I participated in, without
> ever opening an editor/ide. GitHub provides very good collaborative
> review. If I have to install an IDE that I only use for reviewing, um...
> no.
>
> https://github.com/jmdavis/phobos/commit/aca1a2d7cfe7d5e934668e06028b78ffb6796245
>
>

Hum, looking at that GitHub pull request (first time I have done so), GitHub does look quite nice in terms of code reviewing functionality.
So, hum, I do agree that web-based code reviewing might become significantly frequent (if it is not already). (Note that I am not talking about Phobos development only)

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


>> 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). What should be considered is whether it is worthwhile to review it in an IDE or do it the web application, for a given change request.
At the moment, probably not (although I would say it depends a lot on the D code and the underlying project). But in the future things might change. It could even be that a web-based application like GitHub would grow some IDE features, like the one about parameters context information.

-- 
Bruno Medeiros - Software Engineer

On 09/03/2011 06:10, Brad Roberts wrote:
> Personally, I spend_way_  more time reading code (mine or other peoples) than I spend writing code.  Ignoring time, I
> also read far more lines/files/whatever code than I write.  I suspect these things are going to vary highly from person
> to person and from job role to job role.  Those that primarily produce new applications, tools, websites, etc and do
> little maintenance programming will be the polar opposite.

Me too, I also spend a lot of time reading and trying to understand code, especially when working with Eclipse, which is a huge code base. But I do it inside the IDE.

I didn't mean reading in any kind of situation, but only minute ones when tools are not available. Like reading a book, reading a online guide/tutorial/snippet, etc..

-- 
Bruno Medeiros - Software Engineer

On 9 March 2011 13:22, Gareth Charnock <gareth.charnock@gmail.com> wrote:

> Named arguments are useful when you have a function that takes a large number of parameters, the vast majority of which have default values. For example, have a look at this constructor in wxWidgets:
>
>
> http://docs.wxwidgets.org/trunk/classwx_frame.html#01b53ac2d4a5e6b0773ecbcf7b5f6af8
>
> wxFrame::wxFrame        (       wxWindow *      parent,
> wxWindowID      id,
> const wxString &        title,
> const wxPoint &         pos = wxDefaultPosition,
> const wxSize &  size = wxDefaultSize,
> long    style = wxDEFAULT_FRAME_STYLE,
> const wxString &        name = wxFrameNameStr
> )
>
> If you want to change the name argument you need to call
>
> new wxFrame(a_parent,wxANY,"Hello world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom name str")
>
> 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")
>
> I haven't bothered with the arguments I don't care about and my function call has ended up less sensitive to changes in the wxFrame constructor.
>
>
> On 28/02/11 21:50, Jonathan M Davis wrote:
>
>> On Monday, February 28, 2011 13:38:34 Don wrote:
>>
>>> spir wrote:
>>>
>>>> On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
>>>>
>>>>> I'm not entirely against named arguments being in D, however I do
>>>>> think that any
>>>>> functions that actually need them should be refactored anyway.
>>>>>
>>>>
>>> I agree.
>>> CreateFont() in the Windows API, I'm looking at you. (For Linux people,
>>> that function has about 12 parameters).
>>>
>>>  ???
>>>>
>>>>  In actuality, if I were to vote on whether named arguments should be
>>>>> in the
>>>>> language, I would definitely vote against it (I just plain don't want
>>>>> the code
>>>>> clutter,  [...]
>>>>>
>>>>
>>>> Just don't use them!
>>>>
>>>
>>> You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
>>>
>>> There are a couple of things that I really, really don't like about the
>>> names argument idea:
>>> 1. It makes parameter names part of the API.
>>> Providing no way for the function writer to control whether it is part
>>> of the API or not, and especially, doing it retrospectively, strikes me
>>> as extremely rude.
>>>
>>> 2. It introduces a different syntax for calling a function.
>>> foo(4, 5);
>>> foo(x: 4, y: 5);
>>> They look different, but they do exactly the same thing. I don't like
>>> that redundancy.
>>>
>>>
>>> Especially since, as far as I can tell, the named arguments are just
>>> comments (which the compiler can check).
>>> If so, a syntax like this would be possible, with no language change at
>>> all:
>>>
>>> pragma(namedarguments); // applies to whole module
>>>
>>> foo(/*x*/ 4, /*y*/ 5);
>>>
>>> --->  if a function parameter has a comment which forms a valid
>>> identifier, it's a named parameter.
>>>
>>> But I still don't see the need for this feature. Aren't people using
>>> IDEs where the function signature (with parameter names) pops up when
>>> you're entering the function, and when you move the mouse over the
>>> function call?
>>> And if you really want to see them all the time, why not build that
>>> feature into the IDE?
>>> ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
>>>
>>
>> I agree with pretty much everything said here. However, as I understand
>> it,
>> named parameters (at least as they work in Python) would allow for you to
>> reorder parameters and give values for paramters which are normally
>> default
>> parameters without giving values for the default paramters before them,
>> and
>> those changes could not be dealt with by comments. However, I consider
>> them to
>> be a big _problem_, not a feature - _especially_ the ability to rearrange
>> the
>> function arguments. All of a sudden you could have
>>
>>
>> foo(4, 5);
>> foo(x : 4, y : 5);
>> foo(y : 5, X : 4);
>>
>> all making _exactly_ the same function call. That seem _very_ bug-prone
>> and
>> confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5,
>> x :
>> 4)? Not good. The amount of effort to understand the code becomes
>> considerably
>> higher. You could be very familiar with foo and know exactly what
>> parameters it
>> takes and totally mistake what it's really getting passed, because the
>> arguments
>> were flipped in comparison to the function parameters.
>>
>> I agree with Don. I think that named parameters would cause far more intellectual overhead and problems than they'd solve.
>>
>> - Jonathan M Davis
>>
>> - Jonathan M Davis
>>
>
>
I actually like the idea of named variables, for these funktions that takes a lot of parameters, mostly because if the libary dev, chooses to change the default value of something, my old placeholder value, will end up being wrong without me knowing anything about it.

Say:
wxFrame::wxFrame        (       wxWindow *      parent,
wxWindowID      id,
const wxString &        title,
const wxPoint &         pos = wxDefaultPosition,
const wxSize &  size = wxDefaultSize,
long    style = wxDEFAULT_FRAME_STYLE,
const wxString &        name = wxFrameNameStr
)

And I call it with the default args, because I have to, to change the name; however then the libary dev decides it would be better to have a default value of size = 800x600, now I'm not getting the default as I wanted to.


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

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.

It's not one of those "absolutely have to have it" features, it's a nice-to-have.  I certainly can and have lived without it, and there are certainly ways to compensate for not having it.

It's kind of like arrays in D.  Every time I have to use another language, I miss D's array syntax features.  All the same functionality is there, it just takes more effort to do the same thing.  That little effort is not terrible, but I much prefer not having to do it.

-Steve

On 03/09/2011 06:20 PM, Steven Schveighoffer wrote:
> It's kind of like arrays in D.  Every time I have to use another language, I
> miss D's array syntax features.  All the same functionality is there, it just
> takes more effort to do the same thing.  That little effort is not terrible,
> but I much prefer not having to do it.

Agreed. This overall programmer-friendly design, is D's very big + for me.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com