July 28, 2009
Andrei Alexandrescu:
> So, polls would be very useful to gauge what people want. That's very solid information.

I want to add two small things:

1) Votes must follow a period of discussions, and possibly even a summary that lists the most common ideas. Otherwise lot of people will base their vote on an insufficient level of knowledge of the topic :-)

2) Votes (or proposals) may be all equal, with always a "weight" of 1.
OR they may have a variable weight, that for example comes from the estimated experience (or importance) of a person on a topic. For example once I have seen Guido V. Rossum vote for something with with a weight of 1000 (it essentially meant that his decision was the final one). It means that for example I can accept that a vote by Bartoz regarding some concurrency topic is much more heavy (important) than mine, because I know very little about that topic compared to him. In practice to keep things practical most people have a weight of 1, with few known exceptions (for example if you define the API of regex you may have a weight of 4 or 5).

Bye,
bearophile
July 28, 2009
bearophile escribió:
> Andrei Alexandrescu:
>> So, polls would be very useful to gauge what people want. That's very solid information.
> 
> I want to add two small things:
> 
> 1) Votes must follow a period of discussions, and possibly even a summary that lists the most common ideas. Otherwise lot of people will base their vote on an insufficient level of knowledge of the topic :-)
> 
> 2) Votes (or proposals) may be all equal, with always a "weight" of 1.
> OR they may have a variable weight, that for example comes from the estimated experience (or importance) of a person on a topic. For example once I have seen Guido V. Rossum vote for something with with a weight of 1000 (it essentially meant that his decision was the final one). It means that for example I can accept that a vote by Bartoz regarding some concurrency topic is much more heavy (important) than mine, because I know very little about that topic compared to him. In practice to keep things practical most people have a weight of 1, with few known exceptions (for example if you define the API of regex you may have a weight of 4 or 5).

Do you know such a poll system that's free? I just created a poll, but forgot about these points...
July 28, 2009
bearophile:
>(for example if you define the API of regex you may have a weight of 4 or 5).<

Just to be sure of what I mean: it mans you can express a vote in the closed interval [-5 .. +5], you aren't forced to vote just -5 and +5 :-)

Bye,
bearophile
July 28, 2009
Tue, 28 Jul 2009 11:30:00 -0500, Andrei Alexandrescu wrote:

>>>> The presence or absence of parens is a hard-coded accepted meaning of field vs. function.
>>>
>>> I understand how some people want to derive meaning from obj.foo() versus obj.foo. I think they shouldn't in D. I mean D has had for years the behavior that you could drop the trailing empty parentheses.
>> 
>> And for years, there have been complaints about it.  This will continuously be a thorn in the side of D adoption until it is resolved.
> 
> Again, most complaints have been directed towards writeln = 5. I think that's the major problem to be resolved.

I think it is mentioned more often because you tend to agree with it. There are many more as valid arguments which you discard or ignore, mainly maintainability.
July 28, 2009
On Tue, Jul 28, 2009 at 2:35 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Tue, Jul 28, 2009 at 1:49 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>
>> I think the expectation is more that you would address or respond to his argument rather than making your own argument again.
>>
>> Or say something like this:
>> The fundamental difference in our viewpoints is that you believe that
>> expressing extra semantic information to people who read the code is
>> more valuable that saving some typing.  I believe the opposite.
>>
>> (feel free to rewrite as you wish)  Then it is clear that you have understood his argument and have some idea how and where the difference in opinion really comes from.   Simply repeating your argument makes it look as though you have not read his.
>
> Well we both repeated our arguments several times :o). And don't forget: I don't get to decide. So such a discussion between Steve and me could as well be a discussion between any two participants.

That's not quite true.  You do talk to Walter more than Steve does. And I think everyone can guess that if you don't get convinced there's no way Walter will be.  Convincing you isn't sufficient, but it is necessary.

> I do have accountability for Phobos, and there haven't been huge debates about it that I vetoed against, have there?

You have indeed made a good effort there.  It was iffy for a while with the head/toe thing, but you did come around. :-)


>> I don't think it's this one issue he's talking about.  I think the issue is an occasionally repeated history of questionable changes in D made in the face of strong community opposition.  Like foreach_reverse.  Such choices may be perfectly valid, but if you find yourself repeatedly not seeing eye-to-eye with the designers of a language, you have to wonder if you're in the right language community.
>
> I understand. On the other hand, a lot of good things have been done in relative silence, which are likely to positively impact code writing experience a great deal. They just need some more riping. For example, I consider the recently-introduced value range propagation an excellent feature and a well-balanced engineering tradeoff. Such a thing *would* be the kind of feature that would make me cast an interested eye over a language. Finally, a step forward in the always-muddy world of fixed-size integer arithmetic. Then probably I'd try value range propagation and see the compiler essentially fail for all cases (Walter, Walter... I wonder if you had *any* test case for the thing) and then give up in frustration.

There's probably a connection there with human nature's way of remembering affronts much more clearly and dearly than compliments.

--bb
July 28, 2009
Tue, 28 Jul 2009 13:20:30 -0400, Steven Schveighoffer wrote:

> Let me come at another angle.  You can't view properties as some sort of enforcement by the compiler.  The compiler is not guaranteeing that if you call something without parentheses, it doesn't execute arbitrary code, it has nothing to do with what the compiler guarantees.  But the *meaning* that the author of the function wishes to convey is available via the requirement of parentheses or lack thereof.  The author of the code is saying "I wrote this function as if it were a field."

I think the reason is purely syntactical.  Specifically to distinguish nouns from verbs.

Many English words can be used as both.  "Empty" may mean "contains nothing" or "to throw everything away" and both meanings are equally valid.  You need context to derive the correct meaning of a word.  You always have such context in human language because of its nature. Programming languages are much more formalized which robs you of context.

Parentheses make a perfect syntactic convention for anybody familiar with C family languages: verbs have parens, nouns (adjectives, adverbs) don't.  Because functions do things but variables do not.  So when I define "empty" as a property in C# I don't promise pure behavior or O(1) complexity.  I simply state: "This *word* is not a verb. Read it accordingly."  And it's immediately clear to me that "empty" is "nothing inside" while "empty()" is "do cleanup".
July 28, 2009
Bill Baxter wrote:
> On Tue, Jul 28, 2009 at 2:35 PM, Andrei
> Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>> Bill Baxter wrote:
>>> On Tue, Jul 28, 2009 at 1:49 PM, Andrei
>>> Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>> I think the expectation is more that you would address or respond to
>>> his argument rather than making your own argument again.
>>>
>>> Or say something like this:
>>> The fundamental difference in our viewpoints is that you believe that
>>> expressing extra semantic information to people who read the code is
>>> more valuable that saving some typing.  I believe the opposite.
>>>
>>> (feel free to rewrite as you wish)  Then it is clear that you have
>>> understood his argument and have some idea how and where the
>>> difference in opinion really comes from.   Simply repeating your
>>> argument makes it look as though you have not read his.
>> Well we both repeated our arguments several times :o). And don't forget: I
>> don't get to decide. So such a discussion between Steve and me could as well
>> be a discussion between any two participants.
> 
> That's not quite true.  You do talk to Walter more than Steve does.
> And I think everyone can guess that if you don't get convinced there's
> no way Walter will be.  Convincing you isn't sufficient, but it is
> necessary.

Oh yeah? How about "lazy"?


Andrei
July 29, 2009
On Tue, Jul 28, 2009 at 4:45 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
> Bill Baxter wrote:
>>
>> On Tue, Jul 28, 2009 at 2:35 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>> Bill Baxter wrote:
>>>>
>>>> On Tue, Jul 28, 2009 at 1:49 PM, Andrei
>>>> Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>> I think the expectation is more that you would address or respond to
>>>> his argument rather than making your own argument again.
>>>>
>>>> Or say something like this:
>>>> The fundamental difference in our viewpoints is that you believe that
>>>> expressing extra semantic information to people who read the code is
>>>> more valuable that saving some typing.  I believe the opposite.
>>>>
>>>> (feel free to rewrite as you wish)  Then it is clear that you have understood his argument and have some idea how and where the difference in opinion really comes from.   Simply repeating your argument makes it look as though you have not read his.
>>>
>>> Well we both repeated our arguments several times :o). And don't forget: I don't get to decide. So such a discussion between Steve and me could as well be a discussion between any two participants.
>>
>> That's not quite true.  You do talk to Walter more than Steve does. And I think everyone can guess that if you don't get convinced there's no way Walter will be.  Convincing you isn't sufficient, but it is necessary.
>
> Oh yeah? How about "lazy"?


I mean in this case, since Walter seems happy to leave things as-is. His expressed desire is to change things as little as possible here. So if you say a new keyword isn't necessary the chance of a new keyword is basically zero.

--bb
July 29, 2009
Wed, 22 Jul 2009 16:20:36 -0700, Walter Bright thusly wrote:

> Jarrett Billingsley wrote:
>> Ha.  Had D differed *too* much from C++, then we'd run the risk of scaring off the C++ snobs simply because it wasn't familiar enough to them.
> 
> It's a good point. Radically different languages tend to fail simply because few are willing to expend the effort to learn it. This is why Haskell will never catch on.

Do you think it is the syntax or the semantics that is the cause? D is getting closer and closer to languages like Haskell. You can fit in many of the missing features without a sweat, but some fundamental parts of the languages already are contradictory. Some ideas: add tuples, algebraic data types, higher order types, existential and universal quantification, dynamic types, pattern matching, type classes, monad comprehensions, built-in currying, and guards.

Maybe you don't see it as a problem yet, but D seems to suffer from serious featuritis; the philosophy seems to be: if some feature is implementable but yet unimplemented, it will be implemented. More features creep in until the language sinks.

Isn't it too early to state whether Haskell will never catch on? Will D ever catch on? Both communities have grown since the births of the languages.
July 31, 2009
Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> On Tue, 28 Jul 2009 16:08:58 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> However, when I see:
>>>>  x.empty;
>>>>  I can't tell what is implied here.
>>>
>>> You can. In either C# or D language it could execute arbitrary code that you better know what it's supposed to do. D simply doesn't make it "bad style" as C# stupidly does.
>>
>> still not getting it, are you...
>>
>> Just forget it, I think this is a lost cause, I keep making the same points over and over again, and you keep not reading them.
> 
> I do read them and understand them. I mean, it's not rocket surgery. At the end of the day you say "x = a.b;" looks more like sheer access because that's what happens for fields already. Then you say "a.b()" in any context looks more like an action because it's clear that there's a function call involved. But your arguments are not convincing to me, and in turn I explained why. What would you do if you were me?
> 
> Andrei

I totally agree with Steven's arguments (and have enjoyed reading the discussion).

I think the reason he says you're "not getting it" is because your examples tend to be "a.b" whereas his examples tend to be "a.empty". In your examples, you've stripped away the distinct function/field names and presented the argument from the compiler's perspective: in terms of arbitrary symbols that might either perform a pointer dereference or a function invocation.

Steve's arguments, on the other hand, are all from the perspective of the programmer. The parentheses following the identifier act as *punctuation* that clarify intent.

Good?

Good.

--benji