Eval considered

Using eval is almost always a bad idea. It's a crutch for bad designs, it opens giant security holes in your code, and in practice it's almost never needed to get actual stuff done.

>>9
Your logic is somewhere between illusory and retarded. Anyway, to me it is obvious what he meant, even without his example:

Imagine you've implemented a large program in a purely functional way. All the data is properly threaded in and out of functions, and there are no truly destructive updates to speak of. Now pick the two lowest-level and most isolated functions in the entire codebase. They're used all over the place, but are never called from the same modules. Now make these dependent on each other: function A behaves differently depending on the number of times function B has been called and vice-versa.

In C, this is easy! It can be done quickly and cleanly by adding some global variables. In purely functional code, this is somewhere between a major rearchitecting of the data flow and hopeless.

This is the same problem that Haskellers solve with their Debug.Trace clutch ("shit, I thought this function would be pure, but turns out I need it to print debug output"). This is the same problem that arises in tons and tons of cases: a purely functional design is beautiful and minimalistic, with only the barest minimum of dependencies between functions, but changing that design is a pain in the ass.