On Thursday, 29 January 2015 at 02:23:56 UTC, Andrei Alexandrescu wrote:
> Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- Andrei

That discussion probably deserves its own thread.

On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:
>> It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.
>
> I don't think this is confusing:
>
> void foo() safe {
>     bool safe = false;
> }
>
> Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.  Let's consider this resolved and move on to better more interesting things:)  I appreciate you taking the time to voice your opinion and helping me understand the arguments against this idea.

I invested the time because you took a very polite and civil tone. ;)  I'm glad I was able to find a way of wording it that helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on!

On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote:
> I take it you also don't care if your IDE lags for 5 seconds every time you type a character?

Actually, modern parsers can parse ambiguous grammars in O(N) using memoing.

Just because you are reluctant to implement a modern parser does not mean that it cannot be done and wrapped up as a library.

> I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.

D does not even have a published grammar that rejects programs that are not well formed.

The problem is not that having a programmer friendly will cause tool writer problems. The problem is in D specification and semantics which are C++ish.

What people have requested is not C++ish it is well within a CFG.

> You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines.

What is easy for a standards committee is to check that their data structure definitions are implementable in C, C++, Java, C# and SQL. Not being able to repesent those in D will make D less attractive. Besides there is no ambiguity in allowing arbitrary field names since they are preceded by a ".".

(nobody cares about local variables)

On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic wrote:
> helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on!

Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done.

Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability!

While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet.

Here is the crux: nobody forces people who don't want to use "body" as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier!

D is a practically impractical language until it provides:

1. feature freeze

2. semantic specification

3. clean slate syntax upgrade

D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory.

16 years in the making, still no stable release.

On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad wrote:
>
> Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done.
>
> Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability!
>
> While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet.
>
> Here is the crux: nobody forces people who don't want to use "body" as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier!
>
> D is a practically impractical language until it provides:
>
> 1. feature freeze
>
> 2. semantic specification
>
> 3. clean slate syntax upgrade
>
> D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory.
>
> 16 years in the making, still no stable release.

In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei).
This role was rediscovered as "product owner" in Agile settings.
Strong leadership and saying "no" more often that people would like is a constant among good projects.

I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze.

Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.

On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote:
> In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei).

You mean like Batman?

I don't feel like discussing system development principles with you if you think the "dynamic duo" is anywhere near following sound software engineering principles. It is not a fun topic to teach (yes, I have done that).

> This role was rediscovered as "product owner" in Agile settings.
> Strong leadership and saying "no" more often that people would like is a constant among good projects.

The only thing that truly matters is that you have a plan and a reasonable process to back it up. Leadership is about facilitating the process.

A role is not a person, it is backing a task that to be fulfilled to facilitate the process in a predictable and orderly fashion.

> I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze.

I personally don't think it is reasonable for Walter and Andrei to present D as a tool that is suitable for production. If it is, then they have to fess up to massive critique. Take a look at dlang.org, where does it say "experimental language"? It used to say "beta", which actually should have been "alpha"...

I personally only want D to follow sound engineering principles. I personally don't want syntax changes or feature freeze, since it won't help without a solid process to back it up.

> Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.

I think it is abusive and dishonest to present a language as ready for use when it nowhere near a stable release. I've previously requested that they actually do language design by writing up a spec for where D is heading, so that people can make up their mind and decide to provide "implementation power" if they like the presented outcome. Without a clear horizon, it makes no sense to participate unless you have it as a hobby.

That slows down progress. That is what makes Rust and Go winners and D a stagnation.

What I suggest is the best for D is:

1. Feature freeze.
2. Fix semantics/refactor compiler internals.
3. Fix syntax to be mainstream friendly.

In that order.

I have no hope that it will happen without a major restructuring of the process. I'm totally with ketmar on that front.

On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
>>> I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.
>>
>> Thats not possible:
>>
>> @safe {
>>    void some func() // now valid
>> }
>>
>> safe:
>>    void some func() // now valid
>>
>>
>>
>> safe {
>>    void some func() // could not be valid
>> }
>>
>> safe:
>>    void some func() // could not be valid
>>
>>
>> So you need more places where keyword needs to be contextual keyword
>>
>> And this is a path I am not sure we want to go.
>
> None of those cases would valid.  Non-Keyword attributes without a '@' must be on the right hand side of the function parameters.
>

Then I'm afraid the proposal is pointless :-( The goal AIUI is to make the language more consistent. If we can't use the new syntax everywhere (and later get rid of the old one), we can't achieve that.

On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote:
>> For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially.
>
> That explains why new languages make ";" optional, or wait...
>
> Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go?

Counter example: Rust. Of course, Rust isn't the epitome of readability.

>
> Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.

On 2015-01-28 23:27, Walter Bright wrote:

> For example, people often realize that the ; statement terminator is
> redundant, so they propose removing it. In trying it, however, it soon
> becomes clear that error message clarity, recovery, and the correct
> identification of the location of the error degrades substantially.
>
> So consider:
>
>      void func()
>      safe T = 7;
>
> With your proposal, an error isn't discovered until the '=' is found.

A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.

-- 
/Jacob Carlborg

On 2015-01-29 01:19, Walter Bright wrote:

> One of the other mistakes they make is the great idea of implicit
> declaration of variables, and then ruefully have to deprecate/remove it
> a year or two later. (How could those experienced designers have missed
> this obviously great feature?!?)

Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.

-- 
/Jacob Carlborg