> you have a third option [...] you store your text data as a lisp program.
And now anyone with access to a "text" file can run arbitrary code. Or am I missing something?
And now anyone with access to a "text" file can run arbitrary code. Or am I missing something?
Most other languages don't have an obvious way to just parse a file of source code without actually executing it: `#include <stdio.h>` or `import mycoolpythonlib` or `require __DIR__ . '/goolib.php'` both parse and execute/compile/link the file, so yes, any config/log file becomes a code file and "arbitrary code" gets executed, but it doesn't have to be this way.
(Now, you have things like "import hooks" and access to the AST in Python for example if you want a tree of the imported file, but nothing "simple" and obvious. And this is the thing actually: as much as people consider Lisps too complex and powerful, the nice thing is how "obvious" and "simple" they make things like this - by just parsing sexp tree and manioulating nested lists instead of inventing a file format like XML with its transformation languages, query languages and so on, and all the tools to support them, and all the man-years (or is it decades? ...centuries?) spend to code and maintain them ...just think how much needless effort could have been spared.)
Practical Common Lisp is what grabbed me finally (it's available for free online http://www.gigamonkeys.com/book/ or you can buy the print), and you'll love it if you more "to the point" and practical examples.
I get that reading in an log or config file as an S-expression is kind of cool, in a "one ring to rule them all" sort of way, but... what's different between that and reading it in as a DOM or SAX tree?
Is the claim that Lisp's reader is somehow better than DOM or SAX? Easier to use? The resulting trees are easier to walk? Easier to use? What's the actual improvement from doing it the Lisp way?
It seems to me likely that Lisp can import a file into a tree easier (on the coder) than SAX can, but not significantly so. It's not one line versus dozens; more like one line versus a more complex line or maybe two lines.
I argue that the point should always be to reduce complexity of the systems and keep them DRY, even at the cost of slightly less functionality and slightly worse performance. Mainly because the introduction of complexity in a system tends to be irreversible in practice (whereas performance can always be better tuned and more functions can be added when/if needed).
Now, in the real world, where the complexity of XML and friends (and this is probably not even the best example) has already been introduced, and where you can't make it disappear because you have so many things that depend on it now, you're right, there is no real benefit of the fact that you can also do it in a simpler way. And most pro-Lisp arguments hit the same walls: yes, you have a more elegant way to do things, but the complexity of the other ways of doing the same thing has already been introduced and it's not going away, so there's usually little benefit for also having simpler ways to do things.
This is how you can tell that madness lies that way.