The Case Against Autodecode

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 2 06:06:44 PDT 2016


On 06/02/2016 06:42 AM, ZombineDev wrote:
> On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu wrote:
>> On 06/01/2016 06:09 PM, ZombineDev wrote:
>>> Regardless of how different people may call it, it's not what this
>>> thread is about.
>>
>> Yes, definitely - but then again we can't after each invalidated claim
>> to go "yeah well but that other point stands".
>
> My claim was not invalidated. I just didn't want to waste time arguing
> about it, because it is off topic. My point was that foreach is a purely
> language construct that doesn't know about the std.range.primitives
> module, therefore doesn't use it and therefore foreach doesn't perform
> **auto**decoding. It does perform explicit decoding because you need to
> specify a different type of iteration variable to trigger the behavior.
> If the variable type is not specified, you won't get any decoding (it
> will instead iterate over the code units).

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.

>>> Deprecating front, popFront and empty for narrow
>>> strings is what we are talking about here.
>>
>> That will not happen. Walter and I consider the cost excessive and the
>> benefit too small.
>
> On the other hand many people think that the cost of using a language
> (like C++) that has accumulated excessive number of bad design decisions
> and pitfalls is too high.
> Keeping bad design decisions alienates existing users and repulses new
> ones.

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.

> I know you are in a difficult decision making position, but imagine
> telling people ten years from now:
>
> A) For the last ten years we worked on fixing every bad design and
> improving all the good ones. That's why we managed to expand our market
> share/mind share 10x-100x to what we had before.

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.

> B) This strange feature you need to know about is here because we chose
> comparability with old code, over building the best language possible.
> The language managed to continue growing (but not as fast as we hoped)
> only because of the other good features. You should use this feature and
> here's a long list of things you need to consider when avoiding it.

There are many components to the decision, not only compatibility with 
old code.

> The majority of D users ten years from now are not yet D users. That's
> the target group you need to consider. And given the overwhelming
> support for fixing this problem by the existing users, you need to
> reevaluate your cost vs benefit metrics.

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.

> This theme (breaking code) has come up many times before and I think
> that instead of complaining about the cost, we should focus on lower it
> with tooling. The problem I currently see is that there is not enough
> support for building and improving tools like dfix and leveraging them
> for language/std lib design process.

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.

>>> This has little to do with
>>> explicit string transcoding in foreach.
>>
>> It is implicit, not explicit.
>>
>>> I don't think anyone has a
>>> problem with it, because it is **opt-in** and easy to change to get the
>>> desired behavior.
>>
>> It's not opt-in.
>
> You need to opt-in by specifying a the type of the iteration variable
> and that type needs to be different than the typeof(array[0]). That's
> opt-in in my book.

Taking exception to language rules for iteration with dchar is not opt-in.

>> There is no way to tell foreach "iterate this array by converting char
>> to dchar by the usual language rules, no autodecoding". You can if you
>> e.g. use uint for the iteration variable. Same deal as with
>> .representation.
>
> Again, off topic.

It's very on-topic. It's surprising semantics compared to the rest of 
the language, for which the user needs to be informed.

> No sane person wants automatic conversion (bitcast)
> from char to dchar, because dchar gives the impression of a fully
> decoded code point, which the result of such cast would certainly not
> provide.

void fun(char c) {
     if (c < 0x80) {
         // Look ma I'm not a sane person
         dchar d = c; // conversion is implicit, too
         ...
     }
}

>>> On the other hand, trying to prevent Phobos from autodecoding without
>>> typesystem defeating hacks like .representation is an uphill battle
>>> right now.
>>
>> Characterizing .representation as a typesystem defeating hack is a
>> stretch. What memory safety issues is it introducing?
>
> Memory safety is not the only benefit of a type system. This goal is
> only a small subset of the larger goal of preventing logical errors and
> allowing greater expressiveness.

This sounds like "no comeback here so let's insert a filler". Care to 
substantiate?

> You may as well invent a memory safe subset of D that works only ubyte,
> ushort, uint, ulong and arrays of those types, but I don't think anyone
> would want to use such language. Using .representation in parts of your
> code, makes those parts like the aforementioned language that no one
> wants to use.

I disagree.


Andrei



More information about the Digitalmars-d mailing list