[racket] Use of map and eval to evaluate symbol in namespace
+1
In the grand scheme of things, using `eval` to solve a problem (because
you want to get something done now) is nowhere near as bad as, say,
using/building an interpreter that is implemented in C (because I want
to get something done "now", circa 1995).
:)
At Sun, 10 Aug 2014 10:38:24 -0400, Sean Kanaley wrote:
> ***The ultimate (programming) concern is what will produce the highest
> average correct-and-useful-running-program-output per second over my
> lifespan.***
>
> (philosophical extensions: provided it doesn't hurt other people, unless
> they are "bad", where bad = ...etc...)
>
> Or anyone else who programs. The average decreases when something new is
> learned, and increases later as a payoff from the new knowledge
> (ideally...). This is especially important to experts in other fields who
> want a quick solution instead of a theoretically maximally correct and
> beautiful and least upsetting to experts solution.
>
> So I didn't need keyword-apply. I had the following choices:
>
> 1. build literal expression, call eval (~1 min dev time)
>
> 2. search documentation or google for "apply keyword", reach page of
> documentation, *carefully* read all relevant-sounding functions on it,
> choose keyword apply, THEN implement it (~10+ min?) (in reality after
> trying apply for a bit since it seems like it would work, and for fear of
> just using eval and being branded a C programmer, eventually concluding it
> can't work = additional 5 min)
>
> 3. make a mistake with step 2, make post to user's list asking about this
> case, receive feedback that it wasn't necessary to use it, go back and fix
> code to be "correct" (unsure of time to type the first post, but the
> overall energy spent on this process exceeds #1 and #2 for sure)
>
> In my case, I'm glad I now know about keyword-apply because I will be using
> Racket until I die. Those 15 minutes will *hopefully* save over 15 minutes
> by the end of my life. They might not though, and time now > time later,
> but I'm still glad because I enjoy programming as a hobby and want to be
> good at it, but in terms of maximizing output I should have just used eval.
>
> Taken further, there is some optimal level of knowledge that allows for all
> tasks that need to be completed to be completed as quickly and accurately
> as possible, where further knowledge represents time spent wasted acquiring
> it. Professionals in fields other than programming itself will probably
> have a low level of optimal knowledge, and the attitude that some seem to
> have about "dumb newbies with their dumb evals" is incorrect. They should
> possibly do whatever is as fast as possible, regardless of how bad the code
> is.