Skip to main content

Timeline for answer to Things to avoid when writing challenges by feersum

Current License: CC BY-SA 3.0

Post Revisions

13 events
when toggle format what by license comment
Mar 18 at 10:32 comment added Explorer09 I would discuss something about the "exception" of this point. Normally I would distinguish my challenges between two kinds: "showcases of language features" and "reimplementation of existing functions/algorithms". For the "showcase" kind I won't ban the use of built-ins or libraries; for the "reimplementation" I would ban them. Some built-ins or libs may be in-between (i.e. can cheat on solving a problem but not strong enough to trivialize it entirely), and for them I would request labeling and judge the use of built-ins case by case.
Dec 13, 2021 at 15:30 comment added Xwtek This will exclude computational complexity based challenge, which is much more interesting than just input-output. Most language also allows reasoning about how long a program could take modulo addition/multiplication by a constant.
Feb 25, 2021 at 16:57 comment added rydwolf Mod @SteveBennett I don't think this answer is talking about restricted-source. By "Non-observable program requirements", I think they mean things like the algorithm used, rather than the actual, literal, byte values of the source code. The reason non-observable requirements are often bad is that they assume features of a language, which restricting bytes/characters does not do, or are difficult to objectively judge (i.e., how far you stray from an algorithm), unlike the byte length or contents of the program.
Jun 17, 2020 at 9:03 history edited CommunityBot
Commonmark migration
Apr 29, 2020 at 9:47 comment added Steve Bennett Some of the most interesting challenges I have seen have placed constraints on the source code, such as not using certain characters. There was one that required writing X number of different expressions in your language, where no character could be used in more than one expression. It was awesome.
Jul 8, 2018 at 8:43 comment added primo if you're willing to examine the code, i.e. not treat it as a "black box", then yes.
Jul 8, 2018 at 4:50 comment added feersum @primo I don't understand. Length of a source code and what characters it includes are things which can quite easily be measured.
Jul 7, 2018 at 15:38 comment added primo What a strange consensus. That a programming language actually be a programming language as per "A purported programming language should be accepted as such if and only if it is capable of addition of natural numbers and primality testing of natural numbers," seems to be a non-observable requirement. What about restricted-source? One could even argue that code length a la Starry Night is a non-observable requirement.
Mar 28, 2017 at 22:16 comment added user62131 Note that if you want to force the use of a particular algorithm, you can normally do it observably by requesting that program prints out the intermediate steps of the algorithm.
Sep 5, 2016 at 1:59 comment added feersum @xnor Yes, that's a good example of making false assumptions about the programming language. It falsely assumes that every language has "if" statements.
Sep 4, 2016 at 21:34 comment added trichoplax is on Codidact now I agree with everything except the exception. I think this answer is a good reason to avoid excluding library functions.
Sep 4, 2016 at 21:23 comment added xnor Would you consider the usual definition of truthiness to be unobservable?
Sep 4, 2016 at 21:07 history answered feersum CC BY-SA 3.0