|
|
|
|
|
|
by georgeorwell
4898 days ago
|
|
|
I used the word extreme in the assembly language argument to indicate
that I understood you weren't actually advocating people program in
assembly. So I don't consider it a straw man. Rather, it was an
example of extremely flexible control flow. Sometimes this is what
you need. Sometimes you need to modify the stack so that a function
is called in a different way. Sometimes gotos can provide
significantly more efficient code. Sometimes vtables are too
expensive. Rails is at the opposite end of the spectrum, it is very
rigid. As a refutation to your argument against rigid code, a lot of
people consider Rails code to be debuggable and maintainable.
Personally, I like a middle ground and try to be aware of the costs
and benefits of making and using cookie cutters, an example of which
is chained ?:. I was not asking questions to "destroy your argument", I was trying to
establish different contributors to rigidity / flexibility. It seemed
to me that in your argument you were dismissing rigidity - certainly
you weren't praising it - and I wanted to point out that in the use of
any control flow more complicated than test and branch you are in fact
relying on rigidity. If this is a "straw man" in your eyes, then so
be it. Having functions introduces rigidity! Even if-else enforces
some things. If anything, I was just actually interested in the
topic, because I hadn't really thought much about the tradeoffs of
rigid vs. flexible in those specific terms and I wanted to explore
them a bit. What if I revealed myself to you, and then you were like, oh shit, I
better take what he says a little bit more seriously, wouldn't that
just be embarrassing? I don't want to do that to you. |
|
|
About this:
"Plus, I mean, what if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you."
No, by all means, go ahead. I am interested in having a productive discussion about programming, so if you can share your experience in a way that convinces me, I am totally open to it. If it turns out I am wrong, I won't be embarrassed, I will just change my opinion so that I am not wrong any more. This is how one becomes a good programmer in the first place: by paying attention to what is empirically true, rather than what one is originally taught or what seems exciting or what is in theory better.