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

31–40 of 178 posts

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

#31

Post by pjc50 »

Steltek wrote: post #27
PaulHoule wrote: post #21

Earlier quoted context omitted.

Yep. "Something equivalent" is pretty easy. To be able to regenerate the original input (spacing and other foibles) is a bit harder but also possible. Commercial vendors developed tools that can do this in the 00's to support UML and UML-like tooling. Related to this is getting sensible output structures. For instance, many parsing libraries based on parsing combinators output a "lispy" combination of lists/dicts/sca…

You want a decompiler that produces the original language, not just marked up assembly. For pure VM or interpreted languages, you're right this doesn't seem impossible but has unacceptable tradeoffs for most people. For starters, most companies like that compilation is a one-way action. Whitespace is easy, btw. Just enforce code style in the language like gofmt. You don't need to preserve what you can derive programm…

Not a decompiler, but what would otherwise be called a "pretty-printer" of the AST or intermediate representation.

I've definitely got a use case for an XML version of this - a means of modifying a large file without affecting its indentation or re-ordering attributes in areas that have not changed.

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

#32

Post by TheAceOfHearts »

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…

I totally agree. I'd love to see more languages supporting bidirectional code transforms.

I've used jscodeshift [0] to refactor large JavaScript codebases, and it's absolutely amazing. It's incredibly empowering to write code to update your code. For example: unhappy with your test assertions library? Safely migrate all your tests with a quick script.

The React team has a react-codemod [1] repo which has scripts to help you update to newer APIs. That means they can make changes and iterate on improvements without leaving people behind. Quite frankly, I don't see why more tools, libraries, and frameworks wouldn't do the same.

[0] https://github.com/facebook/jscodeshift

[1] https://github.com/reactjs/react-codemod

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

#33

Post by mmjaa »

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…

> clamor for bidirectional parsing

I get this from Lua. "Everything to a bytecode and back again" ..

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

#34

Post by zeveb »

carlmr wrote: post #10
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.

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.

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

#35

Post by flavio81 »

quadcore wrote: post #29
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,…

I agree, OO is ultimately good enough. Problem is, coding using OOP is like printing ideas on paper: you dont wanna do that because it's hard to discard ideas that's been printed on paper. You wanna use post-its instead because post-its are easy to discard. Refactoring is hard using OO and refactoring is the key difference between waterfall and good software development. Refactoring is easier, even fun, using functio…

>I agree, OO is ultimately good enough.

And Common Lisp has arguably the most flexible and powerful OOP system around, CLOS.

Why don't write OOP in Lisp? It is done successfully by lispers around the world.

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

#36

Post by mmjaa »

dmitriid wrote: post #19

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…

Oddly enough, this code is pretty much completely paste- compatible with Lua, too. (Except the ; of course ..)

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

#37

Post by taeric »

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

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 winning. The reality is they are all impressive. Many newer languages got to make tradeoffs that were not viable years ago. They are still nicely done and I'm glad they are here.

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

#38

Post by flavio81 »

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

>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 System), which is based on multimethods/multiple dispatch. It is very different to "traditional" OOP (most other languages except Julia and Dylan)

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

#39

Post by TheAceOfHearts »

pjc50 wrote: post #9
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…

What do you actually mean by "bidirectional parsing" - re-generating the original input, or something equivalent to it, from the AST?

Check out react-codemod [0] for practical React / JavaScript examples. To give an example with explanation, in the v15.5.0 release they deprecated React.createClass [1] in favor of regular ES2015 classes, with a fallback to a module.

[0] https://github.com/reactjs/react-codemod

[1] https://reactjs.org/blog/2017/04/07/react-v15.5.0.html#migra...

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

#40

Post by taeric »

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

I actually added in that other post that party of the appeal is that you can easily explain most lisp using lisp.

This is a strong reason to keep the common syntax tiny. Learning to eval and what it means to apply code gets you ready to understand pretty much all of it.

That is, I suspect many of us like that you can often think of code in terms of other code. In that language.

Don't fall into the trap that this is the end game, though. I am not arguing that. Just that it is a helpful step along the way.

Post reply on HN