4 ms·

How often is it important to treat code as data (in general) and would you say it makes things less complex than a C-like language?

joshAg 14y ago
You should use that a lot with lisp (or rather use it for projects that require you use it a lot). The secret sauce of lisp is that code is data. Instead of using hacks like c's function pointers, lisp lets you pass code around as easily as any other variable type (1st class functions) instead of just pointers to the code. You can then exploit this ability to make code that will generate code on the fly and then execute it (macros). The homoiconicity of the language itself makes it much easier to make useful macros as opposed to just toy examples. Since lisp and c are both turing complete, anything you can do in one language you can do in the other, but lisp's macros, 1st class functions, and homoiconicity make it possible to actually write something that would be almost impossible in c due to complexity issues. For example, in Cal's old intro cs course which used a lisp dialect, the last project of the course was writing a meta-compiler for the entire language. In contrast, Cal's compiler course uses c++ to compile only a small subset of python2 over an entire semester, and is considered one of the hardest classes due to the project's complexity.
magnusjonsson 14y ago
Imagine unix/C without the ability to create new programming languages such as sh, python, yacc, etc. C would be all you had. In lisp you can create sh, python, and C, and mix between them freely within a program/function/block with almost zero friction. By having a simple universal syntax for all your sub-languages, syntax becomes a non-issue. What in unix may be separate language is just a library in lisp. This is not a water-tight analogy but I hope it illustrates the point. If you want to really understand I recommend actually digging into a language in the lisp family such as Common Lisp, Racket or Clojure.
z92 14y ago
You will need the code as data feature for dealing with macros in a sane maner.
arh68 14y ago
How 'often'? Either all the time or very rarely, depending on your perspective. You wouldn't have 50% of your codebase treating code as data, because only a few lines of macros could define an entire new paradigm on top of what's included in common lisp. Those macros could be used pervasively throughout the codebase; they could be used often but written rarely.

joshAg 14y ago

You should use that a lot with lisp (or rather use it for projects that require you use it a lot). The secret sauce of lisp is that code is data. Instead of using hacks like c's function pointers, lisp lets you pass code around as easily as any other variable type (1st class functions) instead of just pointers to the code. You can then exploit this ability to make code that will generate code on the fly and then execute it (macros). The homoiconicity of the language itself makes it much easier to make useful macros as opposed to just toy examples. Since lisp and c are both turing complete, anything you can do in one language you can do in the other, but lisp's macros, 1st class functions, and homoiconicity make it possible to actually write something that would be almost impossible in c due to complexity issues. For example, in Cal's old intro cs course which used a lisp dialect, the last project of the course was writing a meta-compiler for the entire language. In contrast, Cal's compiler course uses c++ to compile only a small subset of python2 over an entire semester, and is considered one of the hardest classes due to the project's complexity.

magnusjonsson 14y ago

Imagine unix/C without the ability to create new programming languages such as sh, python, yacc, etc. C would be all you had. In lisp you can create sh, python, and C, and mix between them freely within a program/function/block with almost zero friction. By having a simple universal syntax for all your sub-languages, syntax becomes a non-issue. What in unix may be separate language is just a library in lisp. This is not a water-tight analogy but I hope it illustrates the point. If you want to really understand I recommend actually digging into a language in the lisp family such as Common Lisp, Racket or Clojure.

z92 14y ago

You will need the code as data feature for dealing with macros in a sane maner.

arh68 14y ago

How 'often'? Either all the time or very rarely, depending on your perspective. You wouldn't have 50% of your codebase treating code as data, because only a few lines of macros could define an entire new paradigm on top of what's included in common lisp. Those macros could be used pervasively throughout the codebase; they could be used often but written rarely.