On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
> I find this a very fluid style of programming that I'd hate to lose.

And that would have been a very important argument if D was targeted as scripting language. But (I hope so!) it is not, thus, additional well-defined reasoning about the code is more important then the "fluid style". IMHO, of course.

On Monday, 28 January 2013 at 02:10:48 UTC, deadalnix wrote:
> OK, let me restate that, as it was probably too strong.
>
> We got to be pedantic on the vocabulary used. We are trying to define very precise stuffs. We cannot define anything with imprecise vocabulary.
>
> Sorry for the intellectual dishonesty part, that was too much.

Well, why not leave formal vocabulary to DIPs and use wiki to brainstorm a bit? In any case, I really wonder how callable structs/classes fit the big picture. Intuitively I would like to behave them as functions in the similar way properties behave like data. But is that really feasible?

On 2013-01-28 03:25, Zach the Mystic wrote:

> I first saw UFCS and optional parentheses in Ruby and it seemed both
> alluring and deceptively simple.

First, Ruby doesn't have UFCS. You can add a new method to any existing class but it's still not UFCS in the same way as D.

Second, optional parentheses in Ruby is simple due to not being in conflict with other syntaxes. In Ruby there are no public instance variables, they're always private. If you access something with the dot operator in Ruby, you're always calling a method.

There is not conflict with callable objects. In Ruby invoking a callable object uses a different syntax from invoking a method. A callable object is invoked using "obj.call()", or in Ruby 1.9 "obj.()".

-- 
/Jacob Carlborg

On Monday, 28 January 2013 at 07:55:23 UTC, Dicebot wrote:
> On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
>> I find this a very fluid style of programming that I'd hate to lose.
>
> And that would have been a very important argument if D was targeted as scripting language. But (I hope so!) it is not, thus, additional well-defined reasoning about the code is more important then the "fluid style". IMHO, of course.

I agree. The clarity of logic in the language should be a priority here.

UFCS is a fine balance, on one hand you can significantly gain readability, on the other hand you can't tell by eye if something is a member function unless you look it up.

Optional parenthesis takes it another step further, meaning that suddenly you can't tell the difference between a member function, a field or an normal function. To me this seems a step too far.

Properties themselves do introduce this ambiguity (when reading code), but they do so in a controlled and contained manner, as opposed to the free-for-all that optional parenthesis enable.

On 1/28/13 1:10 AM, Zach the Mystic wrote:
> On Monday, 28 January 2013 at 04:42:34 UTC, Andrei Alexandrescu wrote:
>>> Do you think the Ferrari (i.e. optional parens) has got
>>> what it needs under the hood?
>>
>> I'm not sure I understand the question.
>
> Just that the elegant appearance of UFCS and optional parens isn't
> offset underneath by built-in ambiguities which lead to problems either
> with compiling wrongly or with making the code difficult to read. I
> don't really need an answer.

It's a pertinent question. (I didn't know Ferrari is a crappy car :o))

One interesting fact is that we have evidence at hand. Optional parens _exist_ today in D, and have for a while. The language has worked. They haven't been a disaster. Aside from discussions about @property itself, optional parens have just worked. We also have evidence that UFCS is convenient and useful. People use it and like it. And arguably UFCS and optional parens combine in a lovely way.

We've also converted the Phobos codebase to work with the half-strong -property switch. We've adorned a lot of functions with @property. I don't see evidence of found bugs or improved code quality. (Subjectively, I'd argue we actually degraded esthetics. There's no love lost between me and that "@property" plastered everywhere.)

These are not "what if" hypotheses; they describe experience accumulated from past events. Even people who dislike optional parens or UFCS must agree that their sentiment is far from widespread - unlike, for example, was the case for string lambdas.


Andrei

On 1/28/13 2:55 AM, Dicebot wrote:
> On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
>> I find this a very fluid style of programming that I'd hate to lose.
>
> And that would have been a very important argument if D was targeted as
> scripting language. But (I hope so!) it is not, thus, additional
> well-defined reasoning about the code is more important then the "fluid
> style". IMHO, of course.

As far as I understand this presupposes (a) a fluid style of programming is associated exclusively with scripting languages, (b) scripting languages have mutually exclusive benefits with systems languages. I disagree on both counts, and large parts of D's design disagree as well.

Andrei

On Monday, 28 January 2013 at 13:23:40 UTC, Andrei Alexandrescu wrote:

> As far as I understand this presupposes (a) a fluid style of programming is associated exclusively with scripting languages, (b) scripting languages have mutually exclusive benefits with systems languages. I disagree on both counts, and large parts of D's design disagree as well.
>
> Andrei

Tiny bit wrong - they are not exactly mutually exclusive. But when support for fluid style comes in conflict with reasoning about the code, scripting languages and system ones should make different choices. Those conflicts does not happen that often though and D is very proof of it, no doubt.

On 1/28/13 6:33 AM, John Colvin wrote:
> Properties themselves do introduce this ambiguity (when reading code),
> but they do so in a controlled and contained manner, as opposed to the
> free-for-all that optional parenthesis enable.

I agree optional parens take getting used to.

Andrei

On 1/28/13 8:27 AM, Dicebot wrote:
> On Monday, 28 January 2013 at 13:23:40 UTC, Andrei Alexandrescu wrote:
>
>> As far as I understand this presupposes (a) a fluid style of
>> programming is associated exclusively with scripting languages, (b)
>> scripting languages have mutually exclusive benefits with systems
>> languages. I disagree on both counts, and large parts of D's design
>> disagree as well.
>>
>> Andrei
>
> Tiny bit wrong - they are not exactly mutually exclusive. But when
> support for fluid style comes in conflict with reasoning about the code,
> scripting languages and system ones should make different choices. Those
> conflicts does not happen that often though and D is very proof of it,
> no doubt.

If we talk about _reasoning_, then properties have already broken that because a.b may be a function invocation. Probably it's about something weaker.

Andrei

On Monday, 28 January 2013 at 13:20:22 UTC, Andrei Alexandrescu wrote:
> It's a pertinent question. (I didn't know Ferrari is a crappy car :o))
>
> One interesting fact is that we have evidence at hand. Optional parens _exist_ today in D, and have for a while. The language has worked. They haven't been a disaster. Aside from discussions about @property itself, optional parens have just worked. We also have evidence that UFCS is convenient and useful. People use it and like it. And arguably UFCS and optional parens combine in a lovely way.
>

You have to think at it both way.

In a lot of code of mine, I omit parenthesis. I don't think that is a good idea in general, but I have to suffer the inconsistencies introduced anyway, so it make sense to benefit from them.

> We've also converted the Phobos codebase to work with the half-strong -property switch. We've adorned a lot of functions with @property. I don't see evidence of found bugs or improved code quality. (Subjectively, I'd argue we actually degraded esthetics. There's no love lost between me and that "@property" plastered everywhere.)
>

It seems to me that phobos has way too much @property in the first place (save for range for instance).

I'm pretty sure phobos has that much @property because they were implicit in the first place. Phobos state is to more the consequence of the laxness that existed in the first place rather than a problem with the later fix.

> These are not "what if" hypotheses; they describe experience accumulated from past events. Even people who dislike optional parens or UFCS must agree that their sentiment is far from widespread - unlike, for example, was the case for string lambdas.
>

I have to say I've seen many people « liking » the parentheses-less calls, but not many coming with actual arguments. You are an exception here. I usually don't trust games of numbers on such topics.