On 06/02/2016 09:25 AM, Steven Schveighoffer wrote:
> And yes, I'm about to kill this thread from my newsreader, since it's
> wasting too much of my time...

A good idea for all of us. Could you also please look on my post on our meetup page? Thx! -- Andrei

On 02.06.2016 15:09, Andrei Alexandrescu wrote:
>>
>>
>> You can change string literals to be something other than arrays, and
>> then we have a path forward. But as long as char[] is not an array, we
>> have lost the battle of sanity.
>
> Yeah, it's a miracle the language stays glued eh.
> ...

It's not a language problem. Just avoid Phobos.

> Your post is a prime example that this thread has lost the battle of
> sanity.

He is just saying that the fundamental reason why autodecoding is bad is that it denies that T[] is an array for any T.

On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer wrote:
> On 6/1/16 6:31 AM, Marc Schütz wrote:
>> I believe everything that does only concatenation will work correctly.
>> That's why joiner() is one of those algorithms that should accept
>> strings directly without going through any decoding (but it may need to
>> recode the joining element itself, of course).
>
> This means that a string is a range. What is it a range of? If you want to make it a range of code units, I think you will lose that battle.
>

No, I don't want to make string a range of anything, I want to provide an additional overload for joiner() that accepts a const(char)[], and returns a range of chars.

The remark about the joining element is that

    ["abc", "xyz"].joiner(","d)

should convert ","d to "," first, to match the element type of the elements. But this is purely a convenience; it can also be pushed to the user.

> If you want to special-case joiner for strings, that's always possible.

Yes, that's what I want. Sorry if it wasn't clear.

> Or string could be changed to be a range of dchar struct explicitly. Then at least joiner makes sense, and I can reasonably explain why it behaves the way it does.
>
> -Steve

On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
> Your claim was obliterated, and now you continue arguing it by adjusting term definitions on the fly, while at the same time awesomely claiming to choose the high road by not wasting time to argue it. I should remember the trick :o). Stand with the points that stand, own those that don't.

> Definitely. It's a fine line to walk; this particular decision is not that much on the edge at all. We must stay with autodecoding.

If you are to stay with autodecoding (and I hope you won't) then
please, *please*, at least make it decode to graphemes so that it
decodes to something that actually have some kind of meaning of its
own.

> I think we have underperformed and we need to do radically better. I'm on lookout for radical new approaches to things all the time. This is for another discussion though.
>
> There are many components to the decision, not only compatibility with old code.
>
> It's funny that evidence for the "overwhelming" support is the vote of 35 voters, which was cast in terms of percentages. Math is great.
>
> ZombineDev, I've been at the top level in the C++ community for many many years, even after I wanted to exit :o). I'm familiar with how the committee that steers C++ works, perspective that is unique in our community - even Walter lacks it. I see trends and patterns. It is interesting how easily a small but very influential priesthood can alienate itself from the needs of the larger community and get into a frenzy over matters that are simply missing the point.
>
> This is what's happening here. We worked ourselves to a foam because the creator of the language started a thread entitled "The Case Against Autodecode", whilst fully understanding there is no way to actually eliminate autodecode. The very definition of a useless debate, the kind he and I had agreed to not initiate anymore. It was a mistake. I'm still metaphorically angry at him for it. I admit I started it by asking the question, but Walter shouldn't have answered. Following that, there was blood in the water; any of us loves to improve something by 2% by completely rewiring the thing. A proneness to doing that is why we self-select to be in this community and forum.
>
> Meanwhile, I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:
>
> * The garbage collector eliminates probably 60% of potential users right off.
>
> * Tooling is immature and of poorer quality compared to the competition.
>
> * Safety has holes and bugs.
>
> * Hiring people who know D is a problem.
>
> * Documentation and tutorials are weak.
>
> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.
>
> * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist.
>
> * Let's wait for the "herd effect" (corporate support) to start.
>
> * Not enough advantages over the competition to make up for the weaknesses above.
>
> There is a second echelon of arguments related to language proper issues, but those collectively count as much less than the above. And "inefficient/poor/error-prone string handling" has NEVER come up. Literally NEVER, even among people who had some familiarity with D and would otherwise make very informed comments about it.
>
> Look at reddit and hackernews, too - admittedly other self-selected communities. Language debates often spring about. How often is the point being made that D is wanting because of its string support? Nada.

I think the real reason about why this isn't mentioned in the
critics you mention is that people don't know about it. Most people
don't even imagine it can be as broken as it is. Heck, it even
took Walter by surprise after years! This thread is the first real
discussion we've had about it with proper deconstruction and
very reasonnable arguments against it. The only unreasonnable thing
here has been your own arguments. I'd like not to point a finger at
you but the fact is that you are the only single one defending
autodecoding and not with good arguments.

Currently autodecoding relies on chance only. (Yes, I call “hoping
the text we're manipulating can be represented by dchars” chance.)
This cannot be anymore.

> Currently dfix is weak because it doesn't do lookup. So we need to make the front end into a library. Daniel said he wants to be on it, but he has two jobs to worry about so he's short on time. There's only so many hours in the day, and I think the right focus is on attacking the matters above.

...

> Andrei

On Thursday, 2 June 2016 at 13:55:28 UTC, cym13 wrote:
> If you are to stay with autodecoding (and I hope you won't) then
> please, *please*, at least make it decode to graphemes so that
> it decodes to something that actually have some kind of meaning
> of its own.

That would cause just as much - if not more - code breakage as ditching auto-decoding entirely. It would also be considerably slower and more memory-hungry.

On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
>
> Look at reddit and hackernews, too - admittedly other self-selected communities. Language debates often spring about. How often is the point being made that D is wanting because of its string support? Nada.

I've been lurking on this thread for a while and was convinced by the arguments that autodecoding should go.

Nevertheless, I think this is really the strongest argument you've made against using the community's resources to fix it now. If your position from the beginning were this clear, then I think the thread might not have gone on so long. As someone trained in economics, I get convinced by arguments about scarce resources. It makes more sense to focus on higher value issues.

However, the case against autodecoding is clearly popular. At a minimum, it has resulted in a significant amount of time dedicated to forum discussion and has made you metaphorically angry at Walter. Resources spent grumbling about it could be better spent elsewhere.

One way to deal with the problem of scarce resources is by reducing the cost of whatever action you want to take. For instance, Adam Ruppe just put up a good post in the Dealing with Autodecode thread
https://forum.dlang.org/post/ksasfwpuvpwxjfniupiv@forum.dlang.org
noting that a compiler switch could easily be added to phobos. Combined with a long deprecation timeline, the cost that it would impose on D users who are not active forum members and might want to complain about the issue would be relatively small.

Another problem related to scarce resources is that there is a division of labor in the community. People like yourself and Walter have fewer substitutes for your labor. It makes sense that the top contributors should be focusing on higher value issues where fewer people have the ability to contribute. I don't dispute that. However, there seem to be a number of people who can contribute on this issue and want to contribute. Scarcity of resources seems to be less of an issue here.

Finally, when you discussed things people complain about D, you mentioned tooling. In the time I've been following this forum, I haven't seen a single thread focusing on this issue. I don't mean a few comments like "oh D should improve its tooling." I mean a thread dedicated to D's tooling strengths and weaknesses with a goal of creating a plan on what to do to improve things.

>
> Currently dfix is weak because it doesn't do lookup. So we need to make the front end into a library. Daniel said he wants to be on it, but he has two jobs to worry about so he's short on time. There's only so many hours in the day, and I think the right focus is on attacking the matters above.
>

On a somewhat tangential basis, I was reading about Microsoft's Roslyn a week or so ago. They do something similar where they have a compiler API. I don't have a very good sense of how it works from their overview, but it seems to be an interesting approach.

On 06/02/2016 09:55 AM, cym13 wrote:
> On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
>> Your claim was obliterated, and now you continue arguing it by
>> adjusting term definitions on the fly, while at the same time
>> awesomely claiming to choose the high road by not wasting time to
>> argue it. I should remember the trick :o). Stand with the points that
>> stand, own those that don't.
>
>> Definitely. It's a fine line to walk; this particular decision is not
>> that much on the edge at all. We must stay with autodecoding.
>
> If you are to stay with autodecoding (and I hope you won't) then
> please, *please*, at least make it decode to graphemes so that it
> decodes to something that actually have some kind of meaning of its
> own.

That's not going to work. A false impression created in this thread has been that code points are useless and graphemes are da bomb. That's not the case even if we ignore the overwhelming issue of changing semantics of existing code.

> I think the real reason about why this isn't mentioned in the
> critics you mention is that people don't know about it. Most people
> don't even imagine it can be as broken as it is.

This should be taken at face value - rampant speculation. From my experience that's not how these things work.

> Heck, it even
> took Walter by surprise after years! This thread is the first real
> discussion we've had about it with proper deconstruction and
> very reasonnable arguments against it. The only unreasonnable thing
> here has been your own arguments. I'd like not to point a finger at
> you but the fact is that you are the only single one defending
> autodecoding and not with good arguments.

Fair enough. I accept continuous scrutiny of my competency - it comes with the territory.

> Currently autodecoding relies on chance only. (Yes, I call “hoping
> the text we're manipulating can be represented by dchars” chance.)
> This cannot be anymore.

The real ticket out of this is RCStr. It solves a major problem in the language (compulsive GC) and also a minor occasional annoyance (autodecoding).


Andrei

On Thu, Jun 02, 2016 at 09:06:44AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> ZombineDev, I've been at the top level in the C++ community for many many years, even after I wanted to exit :o). I'm familiar with how the committee that steers C++ works, perspective that is unique in our community - even Walter lacks it. I see trends and patterns. It is interesting how easily a small but very influential priesthood can alienate itself from the needs of the larger community and get into a frenzy over matters that are simply missing the point.

Appeal to authority.


> This is what's happening here. We worked ourselves to a foam because the creator of the language started a thread entitled "The Case Against Autodecode", whilst fully understanding there is no way to actually eliminate autodecode.

I think that's a misrepresentation of the situation.  I was getting increasingly unhappy with autodecoding myself, completely independently of Walter, and in fact have filed bugs and posted complaints about it long before Walter started his thread.  I used to be a supporter of autodecoding, but over time it has become increasingly clear to me that it was a mistake.  The fact that you continue to deny this and write it off in the face of similar complaints raised by many active D users is very off-putting, to say the least, and does not inspire confidence. Not to mention the fact that you started this thread yourself with a question about what it is we dislike about autodecoding, yet after having received a multitude of complaints, corrobated by many forum members, you simply write off the whole thing like it was nothing.  If you want D to succeed, you need to raise the morale of the community, and this is not the way to raise morale.


> The very definition of a useless debate, the kind he and I had agreed to not initiate anymore. It was a mistake. I'm still metaphorically angry at him for it.

On the contrary, I found that Walter's willingness to admit past mistakes very refreshing, even if practically speaking we can't actually get rid of autodecoding today.  What he proposed in the other thread is actually a workable step towards reversing the wrong decision behind autodecoding, that doesn't leave existing users out in the cold, and that we might actually be able to pull off if done carefully.  I know you probably won't see it the same way, since you still seem convinced that autodecoding was a good idea, but you need to understand that your opinion is not representative in this case.


[...]
> Meanwhile, I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:
> 
> * The garbage collector eliminates probably 60% of potential users right off.

At least we have begun to do something about this. That's good news.


> * Tooling is immature and of poorer quality compared to the competition.

And what have we done about it? How long has it been since dfix existed, yet we still haven't really integrated it into the dmd toolchain?


> * Safety has holes and bugs.

And what have we done about it?


> * Hiring people who know D is a problem.

There are many willing candidates right here. :-P


> * Documentation and tutorials are weak.

And what have we done about this?


> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.

What about linking to it in a prominent place on dlang.org?  This isn't a big problem, AFAICT.  I don't think it takes months and years to put up a big prominent banner promoting vibe.d on, say, the download page of dlang.org.


> * (On Windows) if it doesn't have a compelling Visual Studio plugin,
> it doesn't exist.

And what have we done about this?

One of the things that I have found a little disappointing with D is that while it has many very promising features, it lacks polish in many small details. Such as the way features interact with each other in corner cases. E.g., the whole can't-use-gc from dtor debacle, the semantics of closures over aggregate members, holes in @safe, holes in const/immutable in unions, the whole import mess that took oh-how-many-years to clean up that thankfully was finally improved recently, can't use @nogc with Phobos, can't use const/pure/etc. in Object.toString, Object.opEqual, et al (which we've been trying to get of since how many years ago now?), and a whole long list of small irritations that in themselves are nothing, but together add up like a dustball to an overall perception of lack of polish.

I'm more sympathetic to Walter's stance of improving the language for *current* users, instead of bending over backwards to please would-be adopters who may never actually adopt the language -- they'd just come back with new excuses of why they can't adopt D yet. If you make existing users happier, they will do all the work of evangelism for you, instead of you having to fight the uphill battle by yourself while bleeding away current users due to poor morale.


T

-- 
Why ask rhetorical questions? -- JC

On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
> This is what's happening here. We worked ourselves to a foam because the creator of the language started a thread entitled "The Case Against Autodecode", whilst fully understanding there is no way to actually eliminate autodecode.

Autodecode doesn't need to be removed from phobos completely, it only needs to be more bearable, like it is in the foreach statement. E.g. byDchar will stay, initial idea is to actually put it to more intensive usage in phobos and user code, no need to remove it.

On 06/02/2016 10:14 AM, jmh530 wrote:
> However, the case against autodecoding is clearly popular. At a minimum,
> it has resulted in a significant amount of time dedicated to forum
> discussion and has made you metaphorically angry at Walter. Resources
> spent grumbling about it could be better spent elsewhere.

Yah, this is a bummer and one of the larger issues of our community: there's too much talking about doing things and too little doing things. On one hand I want to empower people (as I said at DConf: please get me fired!), and on the other I need to prevent silly things from happening. The quality of some of the code that gets into Phobos when I look the other way is sadly sub-par. Cumulatively that has reduced its quality over time. That (improving the time * talent torque) is the real solution to Phobos' technical debt, of which autodecoding is negligible.

> One way to deal with the problem of scarce resources is by reducing the
> cost of whatever action you want to take. For instance, Adam Ruppe just
> put up a good post in the Dealing with Autodecode thread
> https://forum.dlang.org/post/ksasfwpuvpwxjfniupiv@forum.dlang.org
> noting that a compiler switch could easily be added to phobos. Combined
> with a long deprecation timeline, the cost that it would impose on D
> users who are not active forum members and might want to complain about
> the issue would be relatively small.

This is a very costly solution to a very small problem. I'm here to prevent silly things like this from happening and from bringing back perspective. We've had huge issues with language changes that were much more important and brought much less breakage. The fact that people talk about 132 breakages in Phobos with a straight face is a good sign that the heat of the debate has taken perspective away. I'm sure it will come back in a few weeks. Just need to keep the dam until then.

The real ticket out of this is RCStr. It solves a major problem in the language (compulsive GC) and also a minor occasional annoyance (autodecoding). This is what I need to work on, instead of writing long messages to put back sense into people.

Many don't realize that the only reason current strings ever work in safe code is because of the GC. char[] is too little encapsulation, so it needs GC as a crutch to be safe. That's the problem with D's strings, not autodecoding. That's why we need to change things. That's what keeps me awake at night.



Andrei