21–30 of 82 posts
Earlier quoted context omitted.
Common Lisp != Lisp. You mean Common Lisp, Lisp is the family of languages (which also includes the Scheme sub-family, Racket, Clojure, Arc, Kernel…).
Its disingenuous to call scheme and racket lisps. They have parenthesis and first class functions but the similarities stop there. So yes I equate Lisp with common lisp. I didn't read the entire article (far too long) but he does mention 'defmacro' which is in Common Lisp.
Earlier quoted context omitted.
Common Lisp != Lisp. You mean Common Lisp, Lisp is the family of languages (which also includes the Scheme sub-family, Racket, Clojure, Arc, Kernel…).
Its disingenuous to call scheme and racket lisps. They have parenthesis and first class functions but the similarities stop there. So yes I equate Lisp with common lisp. I didn't read the entire article (far too long) but he does mention 'defmacro' which is in Common Lisp.
"Sure, it may be homoiconic, use prefix notation, have first-class functions (in additional to all the other usual functional paradigms that aren't unique to lisps) but it's not a lisp."
Big ok to that one. This must be pedantry of the highest caliber, not ignorance.
I found that a rather good introduction to code as data, but I am not sure whether I am supposed to have been hit by the enlightenment he describes… :-)
Yes, for me the first time I read about the lisp syntax I was thinking: "oh cool, it makes (+ 2 2) exactly equivalent to the syntaxic tree + / \ 2 2 " But I don't find it particularly enlightening and I still don't see what cool stuff you can do with macros that you can't do elsewhere.
If you haven't used LINQ, then I'd have a hard time thinking of another example, since most languages have fairly uniform syntax.
To understand Lisp is to understand interpreters. With that understanding you can create domain specific languages which is extremely powerful. But I wouldn't recommend using Lisp itself.. macros in particular are unhygienic.
Common Lisp != Lisp. You mean Common Lisp, Lisp is the family of languages (which also includes the Scheme sub-family, Racket, Clojure, Arc, Kernel…).
Earlier quoted context omitted.
Its disingenuous to call scheme and racket lisps. They have parenthesis and first class functions but the similarities stop there. So yes I equate Lisp with common lisp. I didn't read the entire article (far too long) but he does mention 'defmacro' which is in Common Lisp.
So, homoiconicity is a trifling, meaningless similarity? "Sure, it may be homoiconic, use prefix notation, have first-class functions (in additional to all the other usual functional paradigms that aren't unique to lisps) but it's not a lisp." Big ok to that one. This must be pedantry of the highest caliber, not ignorance.
Earlier quoted context omitted.
Macros extend the power of the language way beyond its core primitives. For instance, I wrote a macro, TEMPORARY-ASSIGN. I use it like this: (TEMPORARY-ASSIGN ((traversing obj) true) ... do stuff ...) In Python, the equivalent code would be. old_trav = obj.traversing obj.traversing = True try: ... do stuff... finally: obj.traversing = old_trav There's no way to abstract out that pattern in Python. Every time you want…
I think I don't understand what your macro does, because the Python code is easily abstractable with a context manager: from contextlib import contextmanager @contextmanager def traverse(obj, attr, val): cached = getattr(obj, attr) setattr(obj, attr, val) yield setattr(obj, attr, cached) with traverse(obj, "traversing", True): # ... do stuff ... Could you explain what your example does that I've missed?
Meaning that the next time you need a feature that doesn't exist in Python, you can't add it.
You should cut these examples some slack; in reality, it's going to be hard to come up with a five line Python example that's ugly, because Python is quite a nice language, and most rough edges have been sanded down over the last 20 years.
That doesn't mean the techniques aren't useful in real world programs, like when you need to build a DSL - just that they're hard to explain in a dozen line HN comment.
Earlier quoted context omitted.
Macros extend the power of the language way beyond its core primitives. For instance, I wrote a macro, TEMPORARY-ASSIGN. I use it like this: (TEMPORARY-ASSIGN ((traversing obj) true) ... do stuff ...) In Python, the equivalent code would be. old_trav = obj.traversing obj.traversing = True try: ... do stuff... finally: obj.traversing = old_trav There's no way to abstract out that pattern in Python. Every time you want…
> There's no way to abstract out that pattern in Python. I'm sure there are macros that can't be abstracted out in Python but this isn't one of them: from contextlib import contextmanager @contextmanager def temp_assign(obj, attr, val): old_val = getattr(obj, attr) setattr(obj, attr, val) yield setattr(obj, attr, old_val) class X: pass x = X() x.a = 1 with temp_assign(x, "a", 2): print x.a # prints 2 print x.a # prin…
I've been doing lisp for several years now. I've built several interpreters. I've never had the enlightenment he describes. The minor epiphanies have been on par with oo design and unit tests. I've travelled far over the months, but it's closer to grok than zen.
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…
Richard Gabriel. Though Peter Gabriel would be good too :)