Completing C code with D style

[Stanislav Blinov]

On Thursday, 11 November 2021 at 21:56:19 UTC, Ali Çehreli wrote:
> On 11/11/21 11:34 AM, Stanislav Blinov wrote:
>
> > Pessimization, though, is laughably easy, and
> > should be avoided at all costs.
>
> I am not passionate about this topic at all and I am here 
> mostly because I have fun in this forum. So, I am fine in 
> general.
>
> However, I don't agree that pessimization should be avoided at 
> all costs. I like D because it allows me to be as sloppy as I 
> want to fix my code later on when it really matters.

And when is that? And why is it not now? You mean prototyping? 
You can do that in any language, not sure what's special about D 
here. Sure, prototype away. No one gets everything right in a 
single keystroke.

> > Not caring about *that* is just bad engineering.
>
> There wasn't a problem statement with the original code. So, we 
> understood and valued it according to our past experiences. For 
> example, most of us assumed the program was about 10 integers 
> but I am pretty sure that array was just an example and the 
> program was meant to deal with larger number of arrays.

What difference does that make? You still don't want to do any 
unnecessary work, whether you're dealing with one puny array or a 
million of them.

> Another example is, you seem to value performance over 
> maintainability because you chose to separate the selection 
> letters without getting any programmatic help from any tool:

I didn't "choose" that. That's Siarhei Siamashka's version, fixed 
up to use `each` instead of `map!text.join`, because latter 
serves no useful purpose.

That is a weird comparison anyway. Performance OVER 
maintainability? There's nothing "more performant" or "less 
maintainable" in the input handling code, as it's the same as 
original.

>   write("Would you like in list (e=evens, o=odds, b=both)? ");
>   readf(" %c", &even);
>
>   if ((negativity == 'b') && (even == 'b'))
>
> For example, the 'b's in that last line may be left behind 
> unmodified if someone changes the help text alone.

Let me see if I get this straight now... are you seriously 
talking about protecting against this program being altered by a 
goldfish? Because in that case, I'd best not write any code 
altogether. Someone someday may put an extra semicolon somewhere, 
the thing would stop compiling, and I'll be totally ruined.
...Perhaps let's actually stay on this planet?

> Someone may find that kind of coding "bad engineering" that 
> shoul be avoided at all cost.

Sure. Someone definitely may. It'd certainly be nice to decouple 
input from logic. That doesn't take 14 times more code and AAs to 
do though. Just sayin' ;)

> (Not to defend myself but my associative array was exactly 
> because I could not bring myself to separate those selection 
> letters from the help text. I simply could not show 
> unmaintainable code to a beginner.)

The original UI code is four lines. Four. Not fool-proof, input's 
not even validated. But four lines. Yours is fifty five, just to 
construct and present the UI and read input. Consequently, 
original program is about 14 times easier to maintain than yours. 
What did I miss?