Josh, right you are, that a bare statement of "don't use eval" can come
off as unhelpful or patronizing.
I'll go meta...
My day job is practitioner, not professor. Among many-many nits, I'm
tired of seeing bad uses of eval in real-world code. Even more than
that, I'm frustrated that eval is often presented to newbies such that
they think it's something they should use, leading to future real-world
messes. It's the ongoing bad influence that frustrates me, not each new
enthusiastic and impressionable newbie.
Someone more dedicated to this particular nit than I am *could* invest a
lot of time in writing checklists of criteria for when to use and not
use eval. And could invest another lot of time developing a suite of
code pattern examples for numerous programming situations in which a
newbie might conceivably think they need to use eval, but instead show a
better way to do it. Personally, I don't have the time to develop all
that sufficiently well (I fear the book would sell tens of copies), and
I'm not sure the effect would be all upside, anyway.[*]
If someone has the time and inclination to develop that, more power to them.
Until such a volunteer emerges, I think the first step is to have the
Racket documentation strongly discourage people from using eval.
(Second step: go through all the copies of Scheme-based textbooks in
libraries and bookstores, and stick a clarifying "Pro Tip" decal on the
metacircular evaluator chapter.)
Funny: One of the very first things that some CS 101 professors like to
tell students about is eval. But, for practical software engineering,
you might consider eval to be one of the *last* things you tell people
about, after they're already experienced in using the other facilities.
In the software engineering case, you then don't have much explaining
to, because the programmer will have a solid foundation by that time.
But, when they don't have that foundation, you can try to throw tons of
relevant background at them, but they don't yet have much context for
anchoring it, so they have to accept it on faith and memorizing the
words of your teachings. If they're going to have to accept on faith
anyway, I'd rather just have them accept the concise noble lie "don't
use eval" on faith, until they've gone off and gotten the foundation to
know how to develop without eval, and to immediately intuit some of the
practical implications of eval.
[*] Regarding not all upside to developing criteria and pattern
examples: there seem to be relevant phenomena. One is the proliferating
clerical worker type of programmer, who has been given the impression
that programming is more about mechanically following checklists and
copying&pasting solutions, than about understanding and reasoning about
systems -- I don't want to encourage the mechanical thinking. Another
phenomenon seems to be, when someone is new to a domain, they seem to
often reason until they can think of *one* plausible solution,
contrasted with someone more familiar, who might reason among many
better solutions that come easily to mind -- I want to remove eval from
the newbie's consideration. Another phenomenon seems to be that, when
someone learns of some powerful feature or technique, they often seem
overly anxious to apply it -- I fear that, the more eval is talked
about, the more it will be used. This is mostly speculation, of course,
but it's merely why I'm not sure the effect would be all upside.
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
