Live data from Hacker News

The Nature of Lisp

defmacro.org

41–50 of 82 posts

Re: The Nature of Lisp

#41
post #11

Earlier quoted context omitted.

You can do cool stuff with unhygienic macros, however, like anaphoric macros. Interested readers should check out On Lisp by Paul Graham, as well as Let Over Lambda by Doug Hoyte.

You can still do anaphoric macros with hygienic macros. http://blog.racket-lang.org/2008/02/dirty-looking-hygiene.ht... And http://blog.racket-lang.org/2011/04/writing-syntax-case-macr...

[deleted]

Re: The Nature of Lisp

#42
post #9

Very good article, though I doubt it'll convince the usual mass of unbelievers. (I love Lisp, for the record, though my primary exposure has been through Emacs Lisp - so shoot me). A really great book that helps you get appreciate the concepts in Lisp, without really talking about Lisp directly too much, is "Patterns of Software" by Peter Gabriel. http://amzn.to/TxDKGG I found it to be a very enlightening read. Defin…

Please don't use link shorteners, especially ones which don't allow me to edit your link to remove the kickback if that's what I want to do.

Re: The Nature of Lisp

#43
I passionately hate XML so this could not possibly resonate with me.

I never had the enlightenment he talks about. Actually I think that learning Lisp/Scheme might have made me a bit of a worse programmer in a way. It made me "dread" repetitive code so much to the point that I almost could not do anything with any language that's not highly dynamic.

Anyways.

I had 2 epiphanies with lisp.

1. Macros. Very powerful concept, but in practice difficult to use properly in your code. It's too difficult to reason about what's going on, like say, if you're maintaining or modifying a set of macros. I think it's more useful not as a construct that you would often use in your own code, but as a construct that's very useful for making libraries.

2. Continuations. This is not really related to lisp itself, and can be done in other languages, like javascript[0]. Understanding a continuation as an even higher level construct than closures .. and the fact that scheme had it built-in was very mind blowing for me.

It makes sense though that a lisp language must have it built-in. It's a concept that's very fundamental to the theory of computation, but in most programming languages it's not explicit at all.

Before continuations, I thought no lisp language can ever have equivalents of "break", "return", or "continue". After understanding continuations, I see that these constructs can built using continuations as a basic building block.

So this to me suggests that the concept of "continuation" is a very basic and fundamental concept that all students of Computer Science should be familiar with. Unfortunately I was never taught about it in University.

[0]: https://github.com/laverdet/node-fibers

Re: The Nature of Lisp

#44

It would seem to me that some variety of Lisp would be the ideal candidate as a sort of runs-everywhere language, a thin portable base language that runs on top of different runtimes, offering easy integration with whichever it is running on. Basically, something like a minimalist Clojure but not just for Java. It would be able to run atop the CLR, JavaScript or the Objective-C runtime as well. The interface with the…

You more or less just described Kernel Lisp - http://www.lambdassociates.org/blog/nextlisp(3).htm.

Re: The Nature of Lisp

#45
post #43

I passionately hate XML so this could not possibly resonate with me. I never had the enlightenment he talks about. Actually I think that learning Lisp/Scheme might have made me a bit of a worse programmer in a way. It made me "dread" repetitive code so much to the point that I almost could not do anything with any language that's not highly dynamic. Anyways. I had 2 epiphanies with lisp. 1. Macros. Very powerful conc…

That "in practice" makes it sound like macros are so hard to understand that they're not worth using in real applications, which is definitely not true. Between the facts that (a) one uses them in deliberately restricted ways, (b) one gets increasingly familiar with them, and (c) they are are, token for token, way more powerful than ordinary code, macros end up being used a lot.

Re: The Nature of Lisp

#46
Replacing XML with YAML will make it much more clear and much more shorter.

Concept of bindings (of symbols to values) and lexical scope (frames of the environment) must be described.

DSLs must be introduced to show how a list structure and uniform function application syntax glue everything together.

The much better advice - read SICP for Christ's sake.) People who wrote it spend much more time thinking what ideas to illustrate, in which order and why.

Then watch the Lectures, to feel the bliss.)

The true piece of mind comes after you finish reading On Lisp and then the contents of arc3.tar

Before that it is still just as being blinded and puzzled by a sudden flash of premature enlightenment.)

Re: The Nature of Lisp

#47
post #38

It would seem to me that some variety of Lisp would be the ideal candidate as a sort of runs-everywhere language, a thin portable base language that runs on top of different runtimes, offering easy integration with whichever it is running on. Basically, something like a minimalist Clojure but not just for Java. It would be able to run atop the CLR, JavaScript or the Objective-C runtime as well. The interface with the…

So something like Clojure, but that runs on the CLR and Javascript as well? CLR - https://github.com/richhickey/clojure-clr JS - https://github.com/clojure/clojurescript Python - https://github.com/halgari/clojure-py Lua - https://github.com/raph-amiard/clojurescript-lua C - https://github.com/schani/clojurec (Sorry, couldn't resist.)

Ruby - https://github.com/unnali/rouge

Re: The Nature of Lisp

#48
...a bit offtopic, but I was wondering while reading the example of using C itself as the C preprocessor language: why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature? (I know, it's easy enough to write a small preprocessor that does it, and it's just primitive string based macros, but having a standard way to do it baked into the building tools or the interpreter for an interpreted language seems ...neat ...even cool if some more "magic sauce" would be added to it to make these "macros" hygienic :) ).

Re: The Nature of Lisp

#49
post #48

...a bit offtopic, but I was wondering while reading the example of using C itself as the C preprocessor language: why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature? (I know, it's easy enough to write a small preprocessor that does it, and it's just primitive string based macros, but having a sta…

> why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature?

There's certainly already languages that do this type of thing. Haskell has Template Haskell which lets you execute Haskell code at compile time to generate code. I'm pretty sure multiple ML's also have similar meta-programming features.

It works rather nice, actually.

Re: The Nature of Lisp

#50

Replacing XML with YAML will make it much more clear and much more shorter. Concept of bindings (of symbols to values) and lexical scope (frames of the environment) must be described. DSLs must be introduced to show how a list structure and uniform function application syntax glue everything together. The much better advice - read SICP for Christ's sake .) People who wrote it spend much more time thinking what ideas…

Yes, XML reminds the terrible XSL experience; YAML would be pythonesque.

1. To the beginners, we need to explain; why code/data unity opens up broad possibilities and separation is simplistic. Otherwise some people claim that the best LISP DSL you ll write, will end up separating your data from your code, and tell you the virtues of von Neumann architecture.

2. Also the macro expansion time, and run time separation for non-interpreted LISP seems to be a restriction; mainly if all macros are to be defined at design time and expanded at macro expansion time, the advantages of macros seem to be limited against languages without macros. Namely, macros seem to be a way to modularize code by generalizing, and simpler languages may do it with text editing and module/source code organization features.

Post reply on HN