I could agree with "bad design" (I probably wouldn't in this particular instance - but it's certainly an arguable point).
However "something that doesn't even make sense" is a somewhat stronger statement than "bad design" :-)
The line makes complete sense as a numerical bitwise or, and the reason it does not do what the author expects is non-obvious in my opinion.
| [reply] |
However "something that doesn't even make sense" is a somewhat stronger statement than "bad design"
In some respects, I agree with the statement that the
original code as posted doesn't make sense. It "feels"
to me like something that would be posted as
Obfuscated Code, because instead of going about
solving the problem in any normal way, it attempts
to abuse certain lowlevel features of the dataset in
order to achieve a counterintuitive solution.
Normally, one would not expect to be able to compare
four numbers with a fifth number by bitwise or-ing
the four numbers together and comparing the result
to the fifth number. In the general case, this
would not work. It took me three readings of the
code to understand why the author *expected* it to
work. Of course, it doesn't, because he ignored
something else that is comparably low-level in
nature to the thing he was exploiting.
The code is attempting (and failing) to take
advantage of some lowlevel details not only of how
the language works but also lowlevel details of
the dataset and of the problem. If
256 weren't a power of two, there wouldn't even be
a presumption that it might work. It's a lowlevel
bit-fiddling dirty-trick (attempted) solution to a
higher-level problem, by no means a natural way
to go about the thing at hand. Notice I did not say
it isn't *the* natural way; I said it is not *a*
natural way at all. Id est, it doesn't make sense.
People who write code like this *deserve* to get
bitten by lowlevel details. (Of course, if you're
just fooling around and the results don't matter,
then getting bitten isn't such a big deal.)
;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
| [reply] |
| [reply]
[d/l] |
Normally, one would not expect to be able to compare four numbers with a fifth number by bitwise or-ing the four numbers together and comparing the result to the fifth number. In the general case, this would not work. It took me three readings of the code to understand why the author *expected* it to work.
If 256 weren't a power of two, there wouldn't even be a presumption that it might work. It's a lowlevel bit-fiddling dirty-trick (attempted) solution to a higher-level problem, by no means a natural way to go about the thing at hand. Notice I did not say it isn't *the* natural way; I said it is not *a* natural way at all. Id est, it doesn't make sense.
This is why it's arguable :-) Things like this depend so much on experience with the domain and various programming styles. For me the authors intent was immediately obvious and the style a completely natural one. I can imagine writing the same code myself. I fiddle with IP addresses a great deal in various languages, and you're doing bit-mask type operations on them all of the time. I think about IP addresses and net masks in terms of bits and bytes. So, to me, boolean logic makes complete sense in this particular domain.
The problem for me is that you get bitten by Perl's DWIMary. In Perl you're trained think that Perl will do the "right thing" when given things that look like numbers. In this particular instance Perl doesn't. I think it's a good thing that the Perl 6 folk are giving us separate operators to prevent future confusion.
I can completely see your point of view, and it's nothing I'd start a religious war over, but I do think it's arguable.
| [reply] |