On 04/08/2015 11:54, Neil Van Dyke wrote:
..,
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.)
The funny thing here is you're using /eval/ implicitly all the time but
don't want people to know about its metacircular nature? Just imagine it
would need new /pairs/ all the time to do it's job because - yes - it
might be implement in C but it's using regular Scheme data structures to
do it's job because it's nothing but a C implementation of a Scheme
program (relying heavily on some sort of memory manager providing free
/pairs/ all the time). If that memory manager is coupled with a
mark&sweep garbage collector you will need to allocate these pairs up
until the next garbage collector run: it's exploding and allocating
hundreds of megabytes (about 200 or more) to represent /environments/ as
simple /alists /ever and ever again. Now, the interested in /eval/ is
mostly an accademic one but without that understanding you don't really
know what your doing when you're programming and then the question is:
is it really programming?
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.
Yes! I'm glad again I studied linguistics and made computers and their
"science" a hobby. Tons and tons of practical tidbits, memorized
syntactical fragments of ten different notations with fancy names,
confusing terms and rumors about performance and security. And then that
little noop of a metacircular /eval/ example if it works correctly ...
[*] 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.
I've heard their even using these newbies' answers to their tests in
their software products. Stress test - test on stress - this is how the
world goes ... why program when you have some fifty eager students ready
to solve all your problems in that short hour every year? That is
problem solving capacity! ;-) (Especially when you can evaluate their
answers at will.)
--
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.
