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

81–90 of 178 posts

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

#81

Post by blain_the_train »

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

I didn't understand those concepts in Ruby until I learned clojure and then I found them to be overly complicated.

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

#82

Post by [deleted] »

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…

[deleted]

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

#83

Post by flavio81 »

mamon wrote: post #77
flavio81 wrote: post #43

Earlier quoted context omitted.

>Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. This was one of the reasons. In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines…

Also, metaprogramming is no longer exclusive to Lisp, other languages are adding advanced features all the time, so there's fewer reasons to move to Lisp.

>Also, metaprogramming is no longer exclusive to Lisp, other languages are adding advanced features all the time, so there's fewer reasons to move to Lisp.

You'll see many people in such languages say things as "please don't use macros", "metaprogramming makes things difficult", "metaprogramming is hard", "macros make the code hard to read" and so on.

Metaprogramming in all other languages is usually difficult to implement OR is limited to text substitution (example: C), which makes them a mess!

Languages with true macros mean the code gets transformed to an AST first; your macro needs to transform this AST. Thus you need to learn a whole host of functions/methods/classes and to learn the structure of this AST.

While in Lisp, macros are written using plain regular Lisp. There is almost nothing new to learn, really. This is because the language is formed of s-expressions, which are really easy to manipulate. So doing metaprogramming is almost no more difficult than writing a regular function. In Lisp, metaprogramming is not an advanced topic; quite the opposite, is a beginners' topic.

If such "other languages" wanted to make metaprogramming easy, then the language would have to be written in s-expressions.

Which means the language would probably be labeled as a "Lisp dialect", or as a "Lisp-like language."

>other languages are adding advanced features all the time

Yes, but in Lisp you can add them yourself, you don't need to wait for Google or Oracle or your Benevolent-dictator-for-life to approve the features you need, and don't need to wait for the next version of the compiler.

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

#84

Post by kbp »

jstimpfle wrote: post #67
kbp wrote: post #47

Earlier quoted context omitted.

> I don't disagree that if all you have is parens, then you want something like paredit. But for a C programmer there is no need for such a thing. If that's a good selection of tools for editing code, then why would Lisp programmers need Paredit? Most of those commands work just as well for editing Lisp. The advantages that Paredit gives over that model are semantic commands rather than character based ones, things l…

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 its next sibling list (the function body) to the end of it. C syntax doesn't make this easy for editors to do, but the operations can still be thought of in terms of lists.

You get nested expressions whenever you use if or a loop or call a function. C programs might be flatter on average than Lisp programs, but there's still plenty of structural editing you could do. Another example is moving an expression out of or into a loop, without concern for how many lines it takes up, whether it's a function call or a loop or anything.

The difficulty that C syntax creates for editing operations like this isn't C not having the need for Paredit-style editing, it's C not having good support for it.

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

#85

Post by kamaal »

mamon wrote: post #77
flavio81 wrote: post #43

Earlier quoted context omitted.

>Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. This was one of the reasons. In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines…

Also, metaprogramming is no longer exclusive to Lisp, other languages are adding advanced features all the time, so there's fewer reasons to move to Lisp.

Most language have token meta programming features. Which most of the times are unusable. Things like C macros and source filters break all the time, and are largely useless for things apart from Global variable declarations.

So sorry, most languages don't have the features lisp has. Not even remotely close.

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

#86

Post by Jtsummers »

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…

Dylan. Dylan offered something like what you're asking for here. You had much the same power as traditionally structured lisps (it even has an alternative s-expression syntax).

https://en.wikipedia.org/wiki/Dylan_(programming_language)

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

#87

Post by kbutler »

oregontechninja wrote: post #42
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

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…

A lisp program will tend to have fewer parentheses than an equivalent Java program has parens + braces. They just stack up at the end of the expression.

For example, see https://gist.github.com/coding4food/1248505

Part of this is because lisp tends to be more concise, so there are fewer expressions required. There are relatively few places where lisp adds parentheses, rather than just moving them - mostly just basic operator expressions: (+ a b) vs a + b. Adding parens (a + b) doesn't make it any harder to read.

For function calls, Algol-descended languages already use parentheses and prefix notation, they just put the parens around the arguments instead of the whole expression:

  (function argument list)
vs

  function(argument, list)

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

#88

Post by flavio81 »

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.

>>use the special functions for handling hygienic macros? And each flavor of Lisp has its own way of doing hygienic macros.

There are two main flavors of Lisp: Common Lisp and Scheme;

Scheme already has hygienic macros as default; and writing hygienic macros is trivial (and easy) in Common Lisp.

>you will likely introduce a bug unless

You won't "introduce a bug" if what you need is specifically an unhygienic macro. They have their uses, so it's good to be able to write unhygienic macros as well.

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

#89

Post by joshuamorton »

kamaal wrote: post #65
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

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

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

#90

Post by jlg23 »

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 have the liberty to write anaphoric macros in CL and with it comes the responsibility not to write them by accident.
Post reply on HN