Re: rules (FWIW)
Generally speaking, you can always obfuscate code by making a lot of unnecessary complexity. I don't think this is the kind of obfuscation that is best grasped and appreciated by others though. For example, you could put together a 6-deep nested case structure that, in the end, performs only a simple Boolean logic function. Or you could simply route your wires in a pattern that's hard to trace visually. Sure it's obfuscation, but not the kind I'd want to encourage.
That's why I liked JP's "Hello World" example so much. It was simple and concise, but still capable of confounding. I think it's exactly
because the code was simple enough to understand that the result was
able to confound. It's more a matter of misdirection than complexity -- kinda like magic.
Anyhow, if there are to be rules, I think we should expect entries to practice reasonable wiring style. Messy wiring is like removing whitespace in C -- too trivial to reward. And we shouldn't use stacked sequences or nested cases solely to prevent anyone from viewing all the code at once. The C analogy might be so much excess whitespace that a single line of code extends over several sheets of the printout -- again, not really worthy of reward. And stacking functions on one another to hide the actual function is too much like overuse of #define to redefine C.
Just some thoughts.
One category of obfuscation I think could be neat to play with is calculation or algorithm obfuscation. Like, implement a vi for integer division where only the addition operation is allowed. (I don't know if it's actually possible). Hmmm, maybe that's more of a mini code challenge than an obfuscated multiplication. Oh well, gotta go now.
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.