Dicebot on leaving D: It is anarchy driven development in all its glory.

[Manu]

On Tue, 28 Aug 2018 at 00:55, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 8/26/2018 11:16 PM, Manu wrote:
> >> The code looks the same, and in fact, is about 98% the same.
> > This code appears to be a mechanical translation.
>
> It's not. It's by hand. But I had a specific goal of minimizing the diffs, so
> that if the translation didn't work, it reduced the number of places to look for
> the mistake. And in fact, this has saved me a LOT of grief :-)
>
>
> > That's not what
> > happened in this case; he wrote his game in D from scratch.
> > It was just that he arrived at mostly the same place. He was googling
> > for styling and sample material, but I suspect the problem was a lack
> > of topical material demonstrating how he might write his D code
> > differently.
>
> It takes time to learn how to write idiomatic D effectively. I'm still learning
> how to do it right, too.
>
>
> > It's also the case that the significant difference between C++ and D
> > (in my experience) mostly come down to: D has modules, tidier meta,
> > UDA's, slices, and ranges/UFCS. In trade, D struggles with const, and
> > ref is broken.
> > If your code doesn't manifest some gravity towards one of those
> > features, it will tend to be quite same-ey, and advantage may not be
> > particularly apparent.
>
> I suspect that is still a bit stuck on looking at individual instruments and not
> seeing the orchestra.
>
> Let's take the much-maligned D const. It isn't C++ const (let's call that
> "head-const", because that's what it is). Head-const for a function parameter
> tells us very little about what may happen to it in the function. You can pass a
> head-const reference to a container, and have the function add/change/delete
> every element of that container, all without a peep from any C++ tool. Looking
> at the function signature, you've really got no clue whatsoever.
>
> The reason people have trouble with transitive-const is that they are still
> programming in C++, where they *do* add/change/delete every member of the
> "const" container.

We understand... really. I've spent a decade digesting this, and I'm
not one of those that has ever really complained about D's const. I've
always mostly bought into it philosophically.

The reality is though, that D's const is not actually very useful, and
C++'s const is. D has no way to express head-const, and it turns out
it's a tremendously useful concept.
As I said, I tend to create a head-const hack to use in its place, and
that gets me out of jail... but it's specified as undefined behaviour,
which isn't great.

> That includes me. I try to add transitive-const, and it won't compile, because I
> as well am used to replacing the engine and tail lights in my head-const car. In
> order to use transitive-const, it's forcing me to fundamentally re-think how I
> organize code into functions.

I often walk the same path, but sometimes it doesn't yield success,
and in many cases, it just doesn't actually model the problem.
If the problem is that I want a const container class; I don't want a
function I pass a vector to mutate the container structure, that is,
add/remove/reorder/reallocate the array, but I DO intend it to
interact with mutable elements.
That's a perfectly valid problem structure, and it turns out, it's
very common. I would attribute the given element type as const if I
wanted the const-ness to propagate to the elements, that's obvious and
convenient.

It might be that we can sufficiently rearrange all manner of
conventional wisdom to interact successfully with D's const, but I've
been watching this space for 10 years, and nobody has produced any
such evidence, or articles that we can read and understand how to
wrangle successful solutions.
This particular class of problem reeks of the typical criticism for
Rust... that is, I have better things to be doing with my time than
trying to find awkward alternative code structures to pacify the
const-checker, when in reality, const-container-of-mutable-elements is
simply the correct conceptual modeling of the problem.

Anyway, I'm not fighting that battle. I have enough of my own.

> For example, dmd is full of functions that combine data-gathering with
> taking-action. I've been reorganizing to separate data-gathering and
> taking-action into separate functions. The former can be transitive-const, maybe
> even pure. And I like the results, the code becomes much easier to understand.

I've also had occasional success refactoring to support const, but
it's certainly the case that success is not guaranteed. And it's
always time consuming regardless.