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

41–50 of 178 posts

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

#41

Post by Retric »

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…

Refactoring lisp gets harder the more complex the program gets. Approachs that are clever and reasonable for a 1000 line program can become hell in a 100,000 line program.

Effectively programming languages get less powerful the longer the program becomes. Breaking up programs into more powerful little pieces is never a clean separation and you need to make real trade offs between more separation and more power.

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

#42

Post by oregontechninja »

taeric wrote: post #37
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,…

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 prettier lisp would do the world good, but things like sweet expressions are confusing for absolutely new devs to implement and veterans feel like they don't need them.

Short version: Lisp wallows in obscurity thanks to it's "look"

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

#43

Post by flavio81 »

taeric wrote: post #37
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,…

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…

>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 (MIT CONS, etc) were able to run Lisp fast but those were dedicated, specialized hardware. And expensive.

Enter the late 80s; Lisp ran great on personal computers but implementations AFAIK were mostly commercial, so reserved to big budgets. I'd say Common Lisp did have success on the industry, used for many things (3D, CAD/CAM, simulation, etc).

Meanwhile the rest of the world was on Pascal, C, and C++.

Nowadays things are different, there are many Common Lisp implementations that are free and are good (SBCL and CCL, for example, are lightning fast).

But additionally, it is difficult to understand what advantages would Lisp bring. For this, the developer would have to grok (completely understand) the enormous value of metaprogramming, and to understand as well how flexible is CLOS.

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

#44

Post by pdkl95 »

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

> you're trying to explain lisp using lisp

You may prefer this[1] explanation that uses XML (ant) to explain the basic idea.

[1] http://www.defmacro.org/ramblings/lisp.html

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

#45

Post by laythea »

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…

The way I look at it, it is difficult enough to do "1d" programming correctly. This is "2d" programming, in a sense - programming at multiple levels, if I understand correctly. I would absolutely hate to try to parse code from someone else written in this manner. In my mind, this is wasted brain cells. Professional use of software favours simple, clean maintainable code. Simple style code, saves brain cells for the actual problem, rather than the implementation of said problem. Or do I misunderstand what you mean by bidirectional parsing?

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

#46

Post by flavio81 »

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…

>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. This is fine.

The problem is that in those cases, when you write a "macro" (an AST->AST function), you then need to learn:

* the semantics and structure of the AST

* all the functions/methods/classes your Conventional Language tells you to use for manipulating the AST

The point of Lisp is that you are writing the code in what is an AST as well.

And this AST is written as Lisp lists.

And Lisp is very good at manipulating lists, it has a ton of built-in functions for them.

And thus, for writing the AST->AST function ("macro"), you don't need to learn anything new, if you already know Lisp.

An additional bonus is that your macros are mostly clear, easy to read. Because they are written in a mostly similar way to the rest of your code.

Another bonus is that Lisp was created with AST->AST transformation in mind from the ground up. Macros work almost transparently; you can specify them to work on read-time or on compile-time. They can also work at run-time if necessary. You can do AST->AST at runtime and have the Lisp implementation compile it to machine language at runtime.

This isn't so easy (or practical) to do with conventional languages...

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

#47

Post by kbp »

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 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 like easily slurping and splicing things into parent lists (a block, the arguments to a function call, whatever) without having to think about the syntax needed for that transformation.

There's nothing about Lisp that makes the vi commands you use for editing C less useful for editing Lisp; people use things like Paredit because they allow for a much more semantic style of editing.

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

#49

Post by skybrian »

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…

You'll have to substantiate that, because refactoring Java is pretty easy if you have a good IDE. In many other languages, you're lucky if you can reliably rename a function without having to manually check for false positives, let alone something complicated like change signature or extract superclass.

Also, in any statically typed language, you can fall back on changing the function and using compile errors to tell you all the calls that need to be updated.

Post reply on HN