What are (were) the most difficult parts of D?

[H. S. Teoh]

On Thu, May 12, 2022 at 11:45:47PM +0000, Guillaume Piolat via Digitalmars-d-learn wrote:
> On Thursday, 12 May 2022 at 17:34:30 UTC, H. S. Teoh wrote:
> > 
> > Why is TLS by default a problem?
> > 
> > It's not really for optimization, AIUI, it's more for thread safety:
> > module-global state is TLS by default, so you don't accidentally
> > introduce race conditions.
> 
> What you accidentally have instead is people expecting top-level to be
> global and instead you get TLS, so it's a surprise.
> I mean, a lot of things works like C and C++, but not that.
> 
> It's a problem because it goes from solving "no accidental race
> condition" and you get "people forget to add shared or __gshared and
> their shared library silently fail" situation. You could have none of
> that with explicit TLS.

Valid point.


> > >     - `shared static this()` vs `static this()` is another trap.
> > 
> > One is per-process, one is per-thread.  Why is this a trap?
> 
> Well because you can get that wrong.
> You get to initialize "__gshared" variables in "shared static this".
> It's not hard, but it's something more to explain.

I see.


[...]
> > I wouldn't sweat it if I couldn't easily add `pure` to an entire
> > codebase -- it hardly makes any difference anyway.
> 
> If it doesn't make a difference to the bottom-line then why keep it?

It's useful in smaller pockets of code. Like factory functions that
implicitly cast to immutable, or arithmetic functions whose return
values you want to compute only once in a complex expression.  It's also
useful for maintaining the cleanliness of code (make sure your function
doesn't have inadvertent access to global state where you didn't
intend it to).

But blanket-applying `pure` to an entire codebase?  Don't really see the
value. For things like I/O it's inherently impure anyway.


> > you're on your own and you take responsibility for any problems that
> > you may inadvertently introduce by using the escape hatch.
> 
> Well sizeable @afe code has heaps of @trusted code, so the escape
> hatch is very routine.

IMO, that's a code smell. @trusted should be used as little as possible,
only where it's absolutely unavoidable.  If there's more than a handful
of @trusted in your code, or if you have giant sections of code with
`@trusted:` at the top, you're probably doing it wrong.


> > it's none of the users' business.
> 
> I'm not disagreeing about @trusted in API.
> But I was remarking in practice that @safe would mean different
> invariants.  it's not a big issue, I was probably ranting.

OK, we all rant sometimes. :-) 


[...]
> > So I'm curious, what exactly is it about UFCS chains that make it
> > less maintainable?
> 
> Probably personal preference, I mostly write the pedestrian way, so
> that debugging/optimization goes faster (maybe wrong, dunno).
> 
> In the dlang.org example:
> 
> void main()
> {
>     stdin
>         .byLineCopy
>         .array
>         .sort!((a, b) => a > b) // descending order
>         .each!writeln;
> }
> 
> This code has a number of prerequisites to be able to read: why is
> ".array" needed, why is it ".byLineCopy" vs ".byLine", is the sort
> stable, etc. It's just requires more time spent with the language.

But doesn't reading (and esp maintaining) *any* code require some time
spent with the language anyway?

I've worked in enterprise environments long enough to be extremely
fearful of coders who parachute into a project and make changes without
actually understanding what they're doing ("the code reads that way, I
assumed it worked that way"), and then airlift out afterwards leaving
the resulting mess to long-time fools like myself to clean up.  Maybe
it's a bias from working in a primarily C environment where the language
is inherently fragile and doesn't protect you from many common human
errors, but I'm extremely skeptical of people who expect to just read
code and understand it without actually learning the language for real.
But OK, I'm just ranting, I'll shut up now. :-D


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard