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.
> 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.
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:
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. Someone may find that kind of
coding "bad engineering" that shoul be avoided at all cost. (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.)
I don't think there is much more to see here: A simple C program,
liberties taken for fun in D, pessimization is bad, unmaintainability is
bad, yes.
Ali