Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

adambard.com

Post reply on HN
Print view View original

91–100 of 178 posts

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

#91

Post by kamaal »

flavio81 wrote: post #38
3pt14159 wrote: post #25

Earlier quoted context omitted.

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,…

>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.

Emacs lisp is actually a very practical, easy to use and fun lisp to do a lot of great work in.

Richard Matthew Stallman notes:

It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

From: https://www.gnu.org/gnu/rms-lisp.en.html

Of course if secretaries and regular office people with no prior exposure to programming or STEM education can program Emacs using Emacs Lisp and do useful productive stuff. Programmers most certainly can.

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

#92

Post by Jtsummers »

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.

You can use gensym in common lisp to introduce a new symbol that is guaranteed not to exist already. If you do this your macros become hygienic. In my experience this isn't that big a burden. And sometimes you want to access existing symbols through your macros.

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

#93

Post by dwc »

jstimpfle wrote: post #11
peatmoss wrote: post #7

And, as I wrote in another thread yesterday, it allows you to work with your text editor at a higher level of abstraction than non-lisp-coding people may have seen before ( https://news.ycombinator.com/item?id=16386380 ). Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. I find this really hard to give up after lispy sessions.

I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the b…

> "oatmeal with fingerclips mixed in" (quoting Larry Wall)

I still chuckle at that quote and Larry Wall is great, but given the look of traditional Perl I wouldn't put much stock in Wall's language syntax aesthetic ;-)

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

#94

Post by kamaal »

joshuamorton wrote: post #89
kamaal wrote: post #65

Earlier quoted context omitted.

>>because you're trying to explain lisp using lisp. There is no other way to explain it. Simply put: (1 2 3 4) Is a list (add-all 1 2 3 4) Is also a list (add-all 1 2 (add-all 3 4)) Is also a list In the above example the nested list is data to the main list. And there is all there is to it. In the last example, code just went in as data to another list(code as data). Which is also code.

This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.

True, but.

    sum(1,2,sum(3,4))
isn't a list. so sum() isn't a list member and things passed to it aren't list either.

Lisp code is more consistent.

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

#95

Post by kbp »

joshuamorton wrote: post #89
kamaal wrote: post #65

Earlier quoted context omitted.

>>because you're trying to explain lisp using lisp. There is no other way to explain it. Simply put: (1 2 3 4) Is a list (add-all 1 2 3 4) Is also a list (add-all 1 2 (add-all 3 4)) Is also a list In the above example the nested list is data to the main list. And there is all there is to it. In the last example, code just went in as data to another list(code as data). Which is also code.

This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.

> I see no reason what you just gave isnt isomorphic to

> sum(1,2,sum(3,4))

> Which is not "code as data"

Says who? In Prolog it would be. Whether or not some syntax is a data structure literal depends entirely on the syntax of your language. Your example is isomorphic if you make the corresponding change to your language's data structure literals.

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

#96

Post by AnimalMuppet »

platz wrote: post #61

Code is data does not come from lisp or macros, those are simply affordances. It comes from computer hardware architecture. The von Neumann Architecture is named after the mathematician and early computer scientist John von Neumann. von Neumann machines have shared signals and memory for code and data. Thus, the program can be easily modified by itself since it is stored in read-write memory. Any self-modifying progr…

It's even deeper than that. It's not just how code is handled in a von Neumann architecture, it's how code is created.

Data is just a sequence of bytes. Source code is also just a sequence of bytes - it's just a data file with a particular structure and intent. And then an executable is just a sequence of bytes - it's another data file, though on Unix it's one with the executable permission set. A compiler reads in a data file and writes a data file - they just happen to be source code and executable programs, respectively.

(Now, when Lisp people say "code is data", they mean much more than compile time. For other languages, that is less true, other than self-modifying code...)

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

#97

Post by joshuamorton »

kamaal wrote: post #94
joshuamorton wrote: post #89

Earlier quoted context omitted.

This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.

True, but. sum(1,2,sum(3,4)) isn't a list. so sum() isn't a list member and things passed to it aren't list either. Lisp code is more consistent.

No, it's equally consistent. In lisp, everything is a list. In the example I just gave, everything is a scalar.

Like I said, this is a very bad justification for lisp.

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

#98

Post by joshuamorton »

kbp wrote: post #95
joshuamorton wrote: post #89

Earlier quoted context omitted.

This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.

> I see no reason what you just gave isnt isomorphic to > sum(1,2,sum(3,4)) > Which is not "code as data" Says who? In Prolog it would be. Whether or not some syntax is a data structure literal depends entirely on the syntax of your language. Your example is isomorphic if you make the corresponding change to your language's data structure literals.

Well but that's my point. The given example doesn't take advantage of any code as data features. It's entirely user transparent whether code is data or not.

As a motivating example for why one should use lisp, or what lisp brings to the table, it's very poor, because it is wholly unmotivating and doesn't appear to demonstrate anything unique.

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

#99

Post by platz »

AnimalMuppet wrote: post #96
platz wrote: post #61

Code is data does not come from lisp or macros, those are simply affordances. It comes from computer hardware architecture. The von Neumann Architecture is named after the mathematician and early computer scientist John von Neumann. von Neumann machines have shared signals and memory for code and data. Thus, the program can be easily modified by itself since it is stored in read-write memory. Any self-modifying progr…

It's even deeper than that. It's not just how code is handled in a von Neumann architecture, it's how code is created. Data is just a sequence of bytes. Source code is also just a sequence of bytes - it's just a data file with a particular structure and intent. And then an executable is just a sequence of bytes - it's another data file, though on Unix it's one with the executable permission set. A compiler reads in a…

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.

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

#100

Post by AnimalMuppet »

platz wrote: post #99
AnimalMuppet wrote: post #96

Earlier quoted context omitted.

It's even deeper than that. It's not just how code is handled in a von Neumann architecture, it's how code is created. Data is just a sequence of bytes. Source code is also just a sequence of bytes - it's just a data file with a particular structure and intent. And then an executable is just a sequence of bytes - it's another data file, though on Unix it's one with the executable permission set. A compiler reads in a…

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 reply on HN