December 29, 2011
On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam@nospam.com> wrote:

> On 29.12.2011 04:48, David Nadlinger wrote:
>> On 12/29/11 3:46 AM, Timon Gehr wrote:
>>> My point is, without named arguments you can improve the names at any
>>> time. With named arguments, you are stuck and have to get it right
>>> upfront.
>>
>> My point is, without positional arguments you can improve the ordering
>> at any time. With positional arguments, you are stuck and have to get it
>> right upfront.
>>
>> David
>
> That's rubbish! Unless you plan to disallow positional arguments...

Maybe you missed the point?

I see the point in David's response as being that regardless of whether we have positional or named parameters, once exposed, they are pretty well set in concrete. I think that no one is suggesting that position parameters are to be replaced by named ones. The upshot of the idea would be that a API user would be free to choose between whatever *they* felt was appropriate.


-- 
Derek Parnell
Melbourne, Australia
December 29, 2011
On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
> On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
>> (while I have not written a significant amount of functional-style
>> code in Javascript)
>
> It looks fine if you use named functions or a little whitespace
> around the literals (same as D!).

I had been a stupidly staunch defender of braces/semicolons before I actually tried the languages with significant indentation. Since then, I find C-like syntaxes not so attractive, to say the least. It takes a while to fall out of the bad habit typing all that punctuation but the result is rewarding.

Comparing CoffeeScript and the equivalent JavaScript code at http://jashkenas.github.com/coffee-script/, it is obvious that JavaScript is unnecessarily noisy.
December 29, 2011
On 28.12.2011 17:41, Jacob Carlborg wrote:
> On 2011-12-27 23:27, Timon Gehr wrote:
>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>
>>>
>>>
>>>
>>> Andrei
>>
>> Great! =)
>>
>> What about making => syntax available to named functions as well?
>>
>> class C{
>> private int x;
>> int getX() => x;
>> }
>>
>>
>> void main(){
>> int[] arr;
>> bool isOdd(int x) => x&1;
>> writeln(arr.filter!isOdd());
>> }
>>
>
> I wouldn't say no to that.
>

I don't think it improves readability, since it doesn't occur in arbitrary contexts. It'll always be the only thing on the line.
I think that example is close to the best case, but

bool isOdd(int x) { return x & 1; }

is not terribly difficult to read.
So all you're doing is saving 6 characters + one space.
The longer the return expression becomes, the less it matters.

real isComplicated(int param1, Foo param2, real param3) => 43.4 * foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) + param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);

doesn't look any more readable than the equivalent code with a return statement. Especially not in the member function case.

December 29, 2011
On 29.12.2011 09:39, Derek wrote:
> On Thu, 29 Dec 2011 19:08:36 +1100, Don <nospam@nospam.com> wrote:
>
>> On 29.12.2011 04:48, David Nadlinger wrote:
>>> On 12/29/11 3:46 AM, Timon Gehr wrote:
>>>> My point is, without named arguments you can improve the names at any
>>>> time. With named arguments, you are stuck and have to get it right
>>>> upfront.
>>>
>>> My point is, without positional arguments you can improve the ordering
>>> at any time. With positional arguments, you are stuck and have to get it
>>> right upfront.
>>>
>>> David
>>
>> That's rubbish! Unless you plan to disallow positional arguments...
>
> Maybe you missed the point?
>
> I see the point in David's response as being that regardless of whether
> we have positional or named parameters, once exposed, they are pretty
> well set in concrete. I think that no one is suggesting that position
> parameters are to be replaced by named ones. The upshot of the idea
> would be that a API user would be free to choose between whatever *they*
> felt was appropriate.

I'm not aware of any languages where positional arguments are not supported. The restrictions imposed by named arguments are a pure superset of the restrictions imposed by positional arguments.

David's post implies that they are two independent approaches.

It's pretty obvious what happens when you have named arguments: if you make a poor choice in naming an argument, you generally shouldn't fix it. Documentation suffers.
Named arguments WILL reduce code quality in some cases.

There are definitely cases where named arguments are beneficial, though I suspect that most of them involve poorly designed functions. (The Windows CreateFont() function is my favourite example).

As an always-on feature, I can see as more downsides than upsides.
OTOH if it were an opt-in feature (for the library writer), I'd be completely in favour.
December 29, 2011
On 29.12.2011 09:34, Derek wrote:
> On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam@nospam.com> wrote:
>
>
>> sin(real x);
>> sin(real theta);
>>
>> The argument name is *completely* irrelevant. That shouldn't be part
>> of the interface.
>>
>> I have a really really bad taste in my mouth from named arguments in COM.
>
> Were you forced to use named parameters or was it optional?

Forced to support them. The great evil is that the named arguments can arrive in any order.

You're not forced to use them. It's just for the benefit of VB.

December 29, 2011
On 2011-12-29 10:07, Max Samukha wrote:
> On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
>> On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
>>> (while I have not written a significant amount of functional-style
>>> code in Javascript)
>>
>> It looks fine if you use named functions or a little whitespace
>> around the literals (same as D!).
>
> I had been a stupidly staunch defender of braces/semicolons before I
> actually tried the languages with significant indentation. Since then, I
> find C-like syntaxes not so attractive, to say the least. It takes a
> while to fall out of the bad habit typing all that punctuation but the
> result is rewarding.
>
> Comparing CoffeeScript and the equivalent JavaScript code at
> http://jashkenas.github.com/coffee-script/, it is obvious that
> JavaScript is unnecessarily noisy.

I completely agree. CoffeeScript is a really nice language. Except for the nicer syntax it's also really nice to have proper class based object model (or at least as proper it can be since it's compiled to a prototype model).

-- 
/Jacob Carlborg
December 29, 2011
On 2011-12-29 10:19, Don wrote:
> On 28.12.2011 17:41, Jacob Carlborg wrote:
>> On 2011-12-27 23:27, Timon Gehr wrote:
>>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrei
>>>
>>> Great! =)
>>>
>>> What about making => syntax available to named functions as well?
>>>
>>> class C{
>>> private int x;
>>> int getX() => x;
>>> }
>>>
>>>
>>> void main(){
>>> int[] arr;
>>> bool isOdd(int x) => x&1;
>>> writeln(arr.filter!isOdd());
>>> }
>>>
>>
>> I wouldn't say no to that.
>>
>
> I don't think it improves readability, since it doesn't occur in
> arbitrary contexts. It'll always be the only thing on the line.
> I think that example is close to the best case, but
>
> bool isOdd(int x) { return x & 1; }
>
> is not terribly difficult to read.
> So all you're doing is saving 6 characters + one space.
> The longer the return expression becomes, the less it matters.
>
> real isComplicated(int param1, Foo param2, real param3) => 43.4 *
> foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
> param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);
>
> doesn't look any more readable than the equivalent code with a return
> statement. Especially not in the member function case.
>

When you're implementing a lot of properties that basically just forwards to the instance variables it can be really useful.

-- 
/Jacob Carlborg
December 29, 2011
On 29-12-2011 14:07, Jacob Carlborg wrote:
> On 2011-12-29 10:19, Don wrote:
>> On 28.12.2011 17:41, Jacob Carlborg wrote:
>>> On 2011-12-27 23:27, Timon Gehr wrote:
>>>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>> Great! =)
>>>>
>>>> What about making => syntax available to named functions as well?
>>>>
>>>> class C{
>>>> private int x;
>>>> int getX() => x;
>>>> }
>>>>
>>>>
>>>> void main(){
>>>> int[] arr;
>>>> bool isOdd(int x) => x&1;
>>>> writeln(arr.filter!isOdd());
>>>> }
>>>>
>>>
>>> I wouldn't say no to that.
>>>
>>
>> I don't think it improves readability, since it doesn't occur in
>> arbitrary contexts. It'll always be the only thing on the line.
>> I think that example is close to the best case, but
>>
>> bool isOdd(int x) { return x & 1; }
>>
>> is not terribly difficult to read.
>> So all you're doing is saving 6 characters + one space.
>> The longer the return expression becomes, the less it matters.
>>
>> real isComplicated(int param1, Foo param2, real param3) => 43.4 *
>> foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
>> param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);
>>
>> doesn't look any more readable than the equivalent code with a return
>> statement. Especially not in the member function case.
>>
>
> When you're implementing a lot of properties that basically just
> forwards to the instance variables it can be really useful.
>

+1.

- Alex
December 29, 2011
On 29-12-2011 14:10, Alex Rønne Petersen wrote:
> On 29-12-2011 14:07, Jacob Carlborg wrote:
>> On 2011-12-29 10:19, Don wrote:
>>> On 28.12.2011 17:41, Jacob Carlborg wrote:
>>>> On 2011-12-27 23:27, Timon Gehr wrote:
>>>>> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>>>>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andrei
>>>>>
>>>>> Great! =)
>>>>>
>>>>> What about making => syntax available to named functions as well?
>>>>>
>>>>> class C{
>>>>> private int x;
>>>>> int getX() => x;
>>>>> }
>>>>>
>>>>>
>>>>> void main(){
>>>>> int[] arr;
>>>>> bool isOdd(int x) => x&1;
>>>>> writeln(arr.filter!isOdd());
>>>>> }
>>>>>
>>>>
>>>> I wouldn't say no to that.
>>>>
>>>
>>> I don't think it improves readability, since it doesn't occur in
>>> arbitrary contexts. It'll always be the only thing on the line.
>>> I think that example is close to the best case, but
>>>
>>> bool isOdd(int x) { return x & 1; }
>>>
>>> is not terribly difficult to read.
>>> So all you're doing is saving 6 characters + one space.
>>> The longer the return expression becomes, the less it matters.
>>>
>>> real isComplicated(int param1, Foo param2, real param3) => 43.4 *
>>> foo(param2, bar(param2, param1 + param3 * param3,), 556.4 * param1) +
>>> param3 + param1 *param2 * param2.baz(param1 + 46, param1*2.46);
>>>
>>> doesn't look any more readable than the equivalent code with a return
>>> statement. Especially not in the member function case.
>>>
>>
>> When you're implementing a lot of properties that basically just
>> forwards to the instance variables it can be really useful.
>>
>
> +1.
>
> - Alex

It would be hard to specify in/out for such properties though, with the => syntax (this is something I do often).

- Alex
December 29, 2011
On 12/29/2011 3:07 AM, Don wrote:
> sin(real x);
> sin(real theta);
>
> The argument name is *completely* irrelevant. That shouldn't be part of the interface.
>
> I have a really really bad taste in my mouth from named arguments in COM.
Great example... I can totally think that 'x', 'theta', 't', 'angle', 'radians', 'value', 'val', 'v', etc. could all be valid parameter names (some better than others, obviously).