4 ms·

You are missing that by "reading" the code in Lisp you don't also "execute it", you can just read it and have a nice tree data structure. If you have any reason

by nnq 13y ago

You are missing that by "reading" the code in Lisp you don't also "execute it", you can just read it and have a nice tree data structure. If you have any reason to eval it, go ahead, but that would be a bad idea for a log or a config file (unless you want a Turing complete configuration or logging DSL... hopefully you know this is a bad idea!) 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.)

saw-lau 13y ago
Now you've kick-started me to start looking at 'Land of LISP' which has been sitting on my shelf for a number of years...
- joeevans1000 13y ago
  +1 that's one of the most awesome books out there.
- nnq 13y ago
  Glad to have resparked the interest. But as cute and witty its comics may be, I couldn't stand Land of LISP and abandoned it after ~25%... not "dense" enough for me I guess. Practical Common Lisp is what grabbed me finally (it's available for free online http://www.gigamonkeys.com/book/ 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.
AnimalMuppet 13y ago
OK, I must be missing something here... 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.
- nnq 13y ago
  In a world where XML with DOM and SAX exist, there is no difference. Now imagine that all this and all related technologies (and there are quite a few...) wouldn't even have had to be invented :) ...because you could have just used one parser, that you developed for the language in the first place. Think of the amount of code duplication in all the parsers for all the languages and file formats! 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.

by nnq 13y ago

saw-lau 13y ago

Now you've kick-started me to start looking at 'Land of LISP' which has been sitting on my shelf for a number of years...

joeevans1000 13y ago
+1 that's one of the most awesome books out there.
nnq 13y ago
Glad to have resparked the interest. But as cute and witty its comics may be, I couldn't stand Land of LISP and abandoned it after ~25%... not "dense" enough for me I guess. Practical Common Lisp is what grabbed me finally (it's available for free online http://www.gigamonkeys.com/book/ 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.

AnimalMuppet 13y ago

OK, I must be missing something here... 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.

nnq 13y ago
In a world where XML with DOM and SAX exist, there is no difference. Now imagine that all this and all related technologies (and there are quite a few...) wouldn't even have had to be invented :) ...because you could have just used one parser, that you developed for the language in the first place. Think of the amount of code duplication in all the parsers for all the languages and file formats! 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.