[OT] What are D's values?

[H. S. Teoh]

On Tue, Oct 05, 2021 at 08:22:48AM +0000, Max Samukha via Digitalmars-d wrote:
> On Monday, 4 October 2021 at 22:15:33 UTC, Walter Bright wrote:
> 
> > This is plasticity, the opposite of brittleness.
> 
> To me, that's just another case of abstraction. D's '.' abstracts the
> details of '.' and '->'. That naturally leads to plasticity - ability
> to swap concrete things without affecting the abstract interface.

It's more than just '.' vs '.' and '->', though. That's just one of the
smaller details that lead to plasticity.

Other factors include type inference: by using type inference where the
code doesn't really depend on a specific concrete type, you allow that
type to be swapped for another one later on without needing to change
that part of the code.  This is particularly powerful in UFCS chains: if
you had to implement the UFCS chain in C, for example, you'd have to
rewrite a whole bunch of types, variable declarations, etc., every time
you need to do something like insert a new component into the chain, or
reorder the chain.  That makes refactoring the equivalent code in C an
onerous task, which naturally incentivizes people *not* to do such a
refactoring in C.  In D, thanks to type inference, it takes just a few
seconds to perform this refactoring.  That opens the door to refactoring
your program in ways you normally don't do in C, and much more
frequently too.

Another factor is built-in unittests: if your code has an adequate set
of unittests, you're far more likely to do larger-scale refactorings,
because the unittests give you confidence that any glaring mistakes
would be instantly caught.  In C, unless you have a solid unittesting
framework in place (how many C projects have you seen that has this?
IME, it's in the far minority), you'd have no confidence at all that
your refactoring wouldn't introduce new bugs, esp. subtle bugs that will
come back to bite you in the worst possible ways.  This factor doesn't
stand by itself; D code tends to be more testable thanks to incentives
to write things like UFCS chains instead of deeply-nested loops.  As a
result, if properly used, unittests tend to be more thorough than an
external testsuite as is common in C projects that have a testsuite
(unfortunately, most C projects don't even have one).  Which in turn
leads to higher confidence level that you won't introduce bugs during
refactoring.

Template functions with DbI also adds to D's plasticity: by using static
if's to discover properties of incoming types and adapting to them
accordingly, a function can retain the same external API while
increasing in functionality.  As I described in my other post with the
example of a serialization function, DbI allows the caller to remain
unchanged in the face of changing types and changing requirements like
excluding certain fields from serialization, or different serialization
strategies for different types.  In the equivalent C code, you'd have to
write a different serialization function per type, or use error-prone
APIs that pass in void* and type sizes (not to mention nested
information for nested types -- the complexity just explodes). And every
time you switch the type being serialized, you'd have to change every
callsite that passes that type.  To handle things like non-serialized
fields, you'd have to hard-code stuff into the serialization functions
or pass unwieldy structures like lists or hashtables of stuff to
exclude, stuff that need special treatment, etc..  It's a lot of tedious
(and error-prone!) busywork just to do a refactoring that in D
constitutes just a few lines of code change.

So naturally, in C you'd rather avoid such refactorings, preferring
instead to keep the existing design so as to avoid breaking things
unintentionally or spending too much time refactoring stuff that already
works.  In D, you're freed from a lot of such concerns, so are more
likely to perform deep refactorings that change the original design in
more drastic ways.


T

-- 
Question authority. Don't ask why, just do it.