| |
| Posted by H. S. Teoh in reply to Max Samukha | PermalinkReply |
|
H. S. Teoh
Posted in reply to Max Samukha
| 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.
|