1. Python, Perl, Ruby, and even Java have support for code as data. If this makes Lisp a risky language, then you should be very worried about all of the above.
2. It is easier to disable code-as-data primitives (eval for example) than it is to add them to a language that lacks such support. I use Lisp for code that is not public-facing; the ability to extend the program at runtime can be very useful when security is not an issue. Languages that lack support for such things are harder to work with for cases like mine.
3. Code-as-data in Lisp is primarily a compile time feature, not a run time feature. Most Lisp programmers are using this feature via the macro system, rather than having programs that compute new functionality based on their inputs. You can disable all runtime support for treating code as data, and still take advantage of it at compile time.
1. Python, Perl, Ruby, and even Java have support for code as data. If this makes Lisp a risky language, then you should be very worried about all of the above.
2. It is easier to disable code-as-data primitives (eval for example) than it is to add them to a language that lacks such support. I use Lisp for code that is not public-facing; the ability to extend the program at runtime can be very useful when security is not an issue. Languages that lack support for such things are harder to work with for cases like mine.
3. Code-as-data in Lisp is primarily a compile time feature, not a run time feature. Most Lisp programmers are using this feature via the macro system, rather than having programs that compute new functionality based on their inputs. You can disable all runtime support for treating code as data, and still take advantage of it at compile time.