On Tuesday, 5 October 2021 at 14:31:15 UTC, David Gileadi wrote:
> On 10/5/21 6:17 AM, Dukc wrote:
>> On Monday, 4 October 2021 at 20:42:06 UTC, David Gileadi wrote:
>>>
>>> This message was a reference type containing protected values.
>> 
>> Huh, what did you try to do? I tested the snippet before posting and for me, it worked.
>
> Sorry, it was my poor attempt at wordplay. Please ignore.

I got the joke anyway 😅

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.

On Tuesday, 5 October 2021 at 17:53:46 UTC, H. S. Teoh wrote:
> 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,

This is all great, but C is too weak a competitor for it to be persuasive to someone who needs persuading.

Here's a remark on brittleness in Rust:

>I’ve seen this many times in Rust: I write a large chunk of code being a little careless about lifetimes, just to then have to change the types of my variables and functions everywhere in my program to avoid having to clone() things everywhere to make it work.

from https://renato.athaydes.com/posts/how-to-write-slow-rust-code.html

On Tuesday, 5 October 2021 at 20:00:42 UTC, jfondren wrote:
> On Tuesday, 5 October 2021 at 17:53:46 UTC, H. S. Teoh wrote:
>> [...]
>
> This is all great, but C is too weak a competitor for it to be persuasive to someone who needs persuading.
>
> Here's a remark on brittleness in Rust:
>
>>[...]
>
> from https://renato.athaydes.com/posts/how-to-write-slow-rust-code.html

Interesting link about Rust. I think D could/should speak to those wanting to be more productive 🍀

On 10/5/2021 10:53 AM, H. S. Teoh wrote:
> 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.
This is why D's test suite is so crucial. We could never improve D without it.

The *lack* of a test suite for Optlink is what is killing it. It being all written in assembler isn't the issue.

On Tuesday, 5 October 2021 at 20:00:42 UTC, jfondren wrote:
> On Tuesday, 5 October 2021 at 17:53:46 UTC, H. S. Teoh wrote:
>> 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,
>
> This is all great, but C is too weak a competitor for it to be persuasive to someone who needs persuading.
>

C has the whole market of UNIX clones, Khronos standards, and embedded for itself, where C++ after 30 years trying hardly managed to make dent.