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?
