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

11–20 of 178 posts

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

#11

Post by jstimpfle »

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 basic line operations like dd, p, and Shift+V (line range select). Also, I often use just { and } to navigate to the next/previous empty line. These keyboard shortcuts get those >90% covered.

Beyond that, you can use Control+V (block select), and XaY where X can be c (change) or d (delete) or v (visual select), and Y can be things like " (string literals), w (identifier), { (braced block) or ( (parenthesized expression).

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.

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

#12

Post by quadcore »

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

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

#13

Post by yetanotheruser »

tombert wrote: post #8

When I was first learning C, I wondered the point of macros; especially with inline functions. It wasn't until I taught myself Racket and Clojure a few years later that I realized the utility, and it was immediately one of those "the world is different now" moments; I could actually augment the language without having to contribute to the core compiler.

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.

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

#14

Post by peatmoss »

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…

I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference.

Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility.

I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax.

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

#15

Post by icebraining »

PaulHoule wrote: post #5

One of the failures of conventional programming libraries is that parsing libraries such as yacc work in only one direction. In 2018 we could easily have libraries that work both ways by default, but we don't. Bidirectional parsing is great for code generation and opens up a lot of things you could do easily, but because common parsing libraries are unidirectional, people aren't aware of what you can do and don't cla…

If by code you mean actual text (as opposed to macropy, which generates ASTs that get directly compiled), what does that open up? I've found code generation to be mostly annoying, unless it's just fixing up code written by humans. What's the point of generating a bunch of code, so that it can be re-parsed to be executed? Might as well skip the intermediate step.

To me it seems like having the computer physically press its own keys rather than just generating virtual events.

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

#17

Post by jstimpfle »

peatmoss wrote: post #14
jstimpfle wrote: post #11

Earlier quoted context omitted.

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…

I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference. Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility. I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’…

It's obviously a lot shorter and more distinctive. It's highly optimized for assignments, pointer and array dereferences, address-of operations and data definitions. If that's what you do most of the day, you want C syntax.

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

#18

Post by arethuza »

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…

For a while in early 90's I was paid to mainly write Lisp (along with C and PostScript) having previously mostly done C.

My initial reaction to Lisp syntax was pretty much exactly what you describe. However, within a few months I was preferring Lisp over C.

It's really just what you are used to - both C and Lisp are great designs.

Edit: More recently when I started using Python I thought the significant whitespace thing was awful - I went on to completely change my mind (a bit like drinking G&T).

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

#19

Post by dmitriid »

One of the greatest lies that Lispers have is: "Lisp has no syntax". Syntax is defined as "the structure of statements in a computer language."

What Lisp has, and is, is a syntax to describe an AST. If you get the syntax wrong, your program won't run. And even that syntax isn't uniform across the various Lisps (some will throw in weird chars and constructs here and there to make dealing with common structures easier etc.)

It does make it somewhat easier to manipulate code as data if you wish to. And it does somewhat make reasoning about some parts of your code somewhat easier. Is it that good as it's glorified to be?

The author links to Korma as an example of the power of code as data, and macros:

    (select users 
      (where {:active true})
      (order :created)
      (limit 5)
      (offset 3))
:-\

To me, it's a chain of 5 functions which are neither shorter to write nor better than Java's jOOQ [1]:

       create.select(a.FIRST_NAME, a.LAST_NAME, countDistinct(s.NAME))
             .from(a)
             .join(b).on(b.AUTHOR_ID.eq(a.ID))
             .join(t).on(t.BOOK_ID.eq(b.ID))
             .join(s).on(t.BOOK_STORE_NAME.eq(s.NAME))
             .groupBy(a.FIRST_NAME, a.LAST_NAME)
             .orderBy(countDistinct(s.NAME).desc())
             .fetch();
Look, it even has a similar number of parentheses ;)

[1] Example from https://www.jooq.org/doc/3.10/manual-single-page/#sql-buildi...

Post reply on HN