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

121–130 of 178 posts

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

#121

Post by Karunamon »

rootlocus wrote: post #63
accatyyc wrote: post #53

I think there’s a much simpler example of how code is data: (hello world) That’s a list containing two symbols. So it’s data. However, if I evaluate that list, it will call the function “hello” with the argument “world”. So it’s also code. Incidentally, lists and function calls are identical in lisp, hence code is data. I think the article just complicates it by introducing macros.

'(hello world) is a list (hello world) is a function call

Well, technically they're both lists, it's just that the ' prefix makes it a list literal rather than having the compiler try to macro expand it. A bit pedantic, but of massive importance when macros are in play.

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

#122

Post by kamaal »

scottmsul wrote: post #26

Would it be possible to do the same thing in Haskell using partial function application, where the first argument is the name of the tag and the second argument makes the " " tags and applies string concatenation?

Haskell comes from a family of languages called ML. And ML was known as Lisp without parentheses.

So its again Lisp all over again.

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

#123

Post by joshuamorton »

kamaal wrote: post #115
joshuamorton wrote: post #97

Earlier quoted context omitted.

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.

Everything isn't a scalar in the example you mentioned. sum() is a function and other things are numbers. In lisp there is only rule, everything is a list and the first element of the list is a operation to the remainder of the list. This is basically the whole language.

>In lisp there is only rule, everything is a list

Well no. `print` is not a list. `4` is not a list. `(print 4)` is a list containing the scalars `print` and `4`. The mechanics of lisp then say "apply the thing in the first position to the remainder of the list", but that's just notation.

In python, `sum` is a function that can apply to a splatted sequence of scalars (note that it can also apply to a list, but this is different), so `sum(1,2,3,4,5)` works. It returns a scalar value.

In lisp, `+` is a function that can apply to a list. It returns a scalar. `(+ 1 2 3)` resolves to `6`, not `(6)`. This is no different than python (or C actually, for this example).

I understand lisp, I understand why "code is data" is a powerful tool. Your example is a bad one, it does not demonstrate why "code is data" is a powerful tool, because it does not actually demonstrate that code is data.

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

#124

Post by kamaal »

lloeki wrote: post #71
oregontechninja wrote: post #42

Earlier quoted context omitted.

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…

Sweet expressions are a bridge too far IMHO. I would be perfectly content with merely getting rid of those dangling ))))) thanks to simple parentheses insertion† based on a single very simple indent/dedent rule: > if the next line is indented, anything from the beginning of the current line starting at the indent till a dedent matching the current line indent is wrapped in one set of parentheses. Seriously, what abou…

You might want to take a look at Haskell. It comes from a family of languages called ML. And ML was known at one point as Lisp without parenthesis.

Modern incarnations of the same like F# are attractive too.

But Lisp is what it is, List processing.

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

#125

Post by dmitriid »

dmitriid wrote: post #22
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.

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.

I wish people who downvote my comment would explain what they disagree with.

The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands.

Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code.

The full power of those tools put both vi and paredit to shame when it comes to actually working with code.

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

#126

Post by thedirt0115 »

kbp wrote: post #84
jstimpfle wrote: post #67

Earlier quoted context omitted.

But there is no such thing as "parent lists" in C. There are much less parentheses. You don't make nested functions or data. You write simple, procedural code, and therefore you simply move lines up or down, and at most change the indentation level. (To fix indentation in vim, select a block of lines and use =. To shift left or right, use >).

Sure there is. Imagine you had this function: int f(void) { int x = 1; return x * 2; } Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in…

Tooling is getting better for non-Lisp languages. In C#, with Visual Studio and ReSharper, for example, you could highlight the "int x = 1;" line, and hit your keyboard shortcut for ReSharper:Introduce_Parameter, which would do pretty much exactly what you're saying. Same for turning a chunk of code into a method, etc.

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

#127

Post by yetanotheruser »

kbp wrote: post #60
yetanotheruser wrote: post #13

Earlier quoted context omitted.

I'm still wrapping my head around macros, but I have been able to come up with a couple use cases that I quickly realized were already covered by existing macros, the most recent one being a less flexible -> macro. Anyways, I kept reading places that lisp macros and c macros were completely distinct, which seems untrue after a couple years of trying clojure.

> I kept reading places that lisp macros and c macros were completely distinct, which seems untrue after a couple years of trying clojure. They're similar in that they're both compile-time functions that generate code, but they're very different in practice, because C macros are written in a text substitution language that knows virtually nothing about C, which naturally makes writing even simple macros very error-pr…

Right, that makes sense

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

#128

Post by didibus »

dmitriid wrote: post #125
dmitriid wrote: post #22

Earlier quoted context omitted.

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.

I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually…

You were downvoted because what you said shows that you do not understand what paredit is.

I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept.

If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.

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

#129

Post by kamaal »

joshuamorton wrote: post #123
kamaal wrote: post #115

Earlier quoted context omitted.

Everything isn't a scalar in the example you mentioned. sum() is a function and other things are numbers. In lisp there is only rule, everything is a list and the first element of the list is a operation to the remainder of the list. This is basically the whole language.

>In lisp there is only rule, everything is a list Well no. `print` is not a list. `4` is not a list. `(print 4)` is a list containing the scalars `print` and `4`. The mechanics of lisp then say "apply the thing in the first position to the remainder of the list", but that's just notation. In python, `sum` is a function that can apply to a splatted sequence of scalars (note that it can also apply to a list, but this i…

You seem to be suggesting

    (sum 1 2 3 4 5)
and

    sum(1, 2, 3, 4, 5)
are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things.

Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought.

There is a reason we are insisting on everything being list and them being uniform that way. That's because eventually we can use structures to modify themselves(recursion and macros).

Which is why Lisp's (sum 1 2 3 4 5) and Python's sum(1 ,2, 3, 4, 5) can't be judged on what they return alone, they have to judged on the structure they represent.

There is a interesting macro in Clojure named '-->'.

This basically helps:

    (task3
      (task2
        (task1 work)))
to be

    (--> work
         task1
         task2
         task3)
These sort of transformations are not easy with sum(1,2,3,4,5) kind of syntax or even possible in many cases.

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

#130

Post by jstimpfle »

kbp wrote: post #84
jstimpfle wrote: post #67

Earlier quoted context omitted.

But there is no such thing as "parent lists" in C. There are much less parentheses. You don't make nested functions or data. You write simple, procedural code, and therefore you simply move lines up or down, and at most change the indentation level. (To fix indentation in vim, select a block of lines and use =. To shift left or right, use >).

Sure there is. Imagine you had this function: int f(void) { int x = 1; return x * 2; } Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in…

Regarding the loop: that's exactly what I described, you just move lines and fix the indentation. It's super quick. There just isn't significant nesting in good code. It's almost always bad style to nest function calls. In statement-blocks you don't have the "trailing parentheses" problem that you have in LISP, since the closing brace is on its own line - so it really boils down to cutting and pasting lines >90% of the time.

Aside: in original C, this is how you wrote functions:

  int f(x, y)
          int x;
          int y;
  {
          int z;
          ...
  }
Post reply on HN