Just what does “code as data” mean anyway? (2014)

Post by didibus » Fri, Feb 16, 2018, 5:38 PM UTC

3pt14159 wrote: post #25

quadcore wrote: post #12

See what I did there? Despite the good intention, no, because you're trying to explain lisp using lisp. If I knew lisp, I wouldnt need you to explain what code-as-data means. Maybe it's time for a different strategy. As a matter of fact, I've tried to explain code-as-data using OOP just this morning: https://news.ycombinator.com/item?id=16389514

Your linked comment is great but it sweeps one thing under the rug. There is a reason lisp didn't win. We put up with it (I use emacs, so I have to write it at times) but in general it's harder to reason about transformable lists of code than it is about plain old objects and their methods. Almost every problem elegantly solved in lisp has a parallel elegant solution in Ruby (using blocks, dynamic method definition,…

Post by platz » Fri, Feb 16, 2018, 5:40 PM UTC

AnimalMuppet wrote: post #100

platz wrote: post #99

Earlier quoted context omitted.

The hardware is more fundamental. (Unless you want to invoke mathematics e.g. term rewriting) The compiler/seq of bytes example requires von neumann, because in that case it is the behavior of the whole system that is self-modifying. You could not have the beautiful executable and interchangable files of bytes without von neumann.

I don't think that's right. There have been systems that were Harvard architecture (Motorola 88000, I think, and definitely others). But the code to run on them still started out as a sequence of bytes in a text file, that is, as data, and a compiler still took that data file and wrote another data file that was the executable image.

Post by firethief » Fri, Feb 16, 2018, 5:51 PM UTC

taneq wrote: post #66

flavio81 wrote: post #38

Earlier quoted context omitted.

>There is a reason lisp didn't win. We put up with it (I use emacs, so I have to write it at times) but in general it's harder to reason about transformable lists of code than it is about plain old objects and their methods. Sounds like your experience was with Emacs Lisp, a very clunky Lisp. >Though I completely agree that inheritance gets clunky and I strongly favour composition. Check out CLOS (Common Lisp Object…

> Sounds like your experience was with Emacs Lisp, a very clunky Lisp. The lisp that didn't win is not an acceptable lisp.

Post by offlineguy » Fri, Feb 16, 2018, 5:57 PM UTC

skybrian wrote: post #59

flavio81 wrote: post #46

Earlier quoted context omitted.

>It is very possible and practical to parse conventional languages down to an AST tree, work on the tree, and run that code. Yes, of course. >Sometimes I wonder if the LISP cult is just trying to pretend Noam Chomsky was never born. Life is great at our cult, you see? Now, seriously, what you propose is to transforme "conventional language" (say, Java) to AST, work on it, and then spit out conventional language again…

In Lisp, my understanding is that while you can manipulate the AST directly, you will likely introduce a bug unless you use the special functions for handling hygienic macros? And each flavor of Lisp has its own way of doing hygienic macros.

Post by metaobject » Fri, Feb 16, 2018, 6:07 PM UTC

zeveb wrote: post #34

carlmr wrote: post #10

Earlier quoted context omitted.

It's very nice, but with great power comes great responsibility. Some people program so many things with C macros that it becomes very hard to read their code.

That's the beauty of Lisp: it's all very readable, because it's a real language, not a string-substitution preprocessor. Yes, any idiot can write unreadable Lisp — but good Lisp is a work of art. The Art of the Metaobject Protocol should be required reading: it builds an entire object system, complete with classes and generic functions (multimethods), written in the language itself . It's a tour de force .