View mode: basic / threaded / horizontal-split · Log in · Help
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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?
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home