Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lisp?

blog.rongarret.info

Post reply on HN
Print view View original

41–50 of 248 posts

Re: Why Lisp?

#41

Post by [deleted] »

dorfsmay wrote: post #34
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

Aren't macros breaking the homocionicity of the lisps? And making maintenance more difficult (aren't you re-inventing a new language with macros?)? Where does the "First rule of the macro club" coming from? When should you break it?

[deleted]

Re: Why Lisp?

#42

Post by demilicious »

orthecreedence wrote: post #3

The interactive model is insanely cool. When building a toy game engine a while back ( https://github.com/orthecreedence/ghostie ) I saved probably half the development time by being able to redefine functions/values while the game was running . The old way of lisping is to prototype in lisp, then build in a "real" language (c/java). However nowadays the lisp implementations (CCL/SBCL specifically) are fast/advanced…

What sort of tools are required for this? I'd like to start taking Lisp seriously, but workflow stories like this tend to hinge on using Emacs/SLIME. Is that always the case?

EDIT: I suppose what I'm asking is whether you could elaborate more on what this looks like, in practice.

Re: Why Lisp?

#43

Post by PuercoPop »

IshKebab wrote: post #16
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

On the other hand, this really hurts readability. When reading other people's code you now effectively have to learn what "language" they use too. I'd say it's probably worth that cost, if used judiciously.

> I'd say it's probably worth that cost, if used judiciously.

Can be said of anything so it really doesn't say anything at all.

This is could be a good criticism in theory, in practice

you can observe how it works out. Fukamachi uses @ everywhere, attila-lendvai uses his def-star library ej (def (class foo) ...) instead of (defclass foo ...), some people use iterate, etc and all is good.

People can write shit code sans macros no problem. I'd rather have them than don't. After all macros embody the whole point of programming[0]

[0]: http://axisofeval.blogspot.com/2011/05/why-of-macros.html

Re: Why Lisp?

#44

Post by dragonwriter »

dorfsmay wrote: post #34
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

Aren't macros breaking the homocionicity of the lisps? And making maintenance more difficult (aren't you re-inventing a new language with macros?)? Where does the "First rule of the macro club" coming from? When should you break it?

> Aren't macros breaking the homocionicity of the lisps?

No. How would that be the case?

> And making maintenance more difficult

If used poorly, sure; the same is true of most features of most languages.

> (aren't you re-inventing a new language with macros?)

You are extending the existing language with them, much as you are when using a language with user-definable functions rather than only builtins.

Re: Why Lisp?

#45

Post by parfe »

don_draper wrote: post #20
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

It would help if I saw a real world problem and how you can solve it Lisp and not in say Python.

The best you'll get are examples of something solvable in Python being "beautiful" in Lisp. Then some real world Lisp examples will be references to a 20 year old storefront generator and the initial release of reddit.

Lisp(s) are certainly better than Python in every way, except when it comes to successful projects completed.

Re: Why Lisp?

#46

Post by sjolsen »

dorfsmay wrote: post #34
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

Aren't macros breaking the homocionicity of the lisps? And making maintenance more difficult (aren't you re-inventing a new language with macros?)? Where does the "First rule of the macro club" coming from? When should you break it?

>Aren't macros breaking the homocionicity of the lisps?

No. How would macros break homoiconicity? They expand into atoms and lists (and other datatypes), the same stuff of which macro-free programs are made.

>And making maintenance more difficult?

No. Unless you intentionally write unmaintainable macros. It's the same as if you write unmaintainable functions, classes, etc. They're just abstracting a different thing— syntax.

>aren't you re-inventing a new language with macros?

No, you're expanding the language; you're just expanding the grammar instead of the vocabulary.

>Where does the "First rule of the macro club" coming from? When should you break it?

What is the "first rule of the macro club?"

Re: Why Lisp?

#47

Post by orthecreedence »

demilicious wrote: post #42
orthecreedence wrote: post #3

The interactive model is insanely cool. When building a toy game engine a while back ( https://github.com/orthecreedence/ghostie ) I saved probably half the development time by being able to redefine functions/values while the game was running . The old way of lisping is to prototype in lisp, then build in a "real" language (c/java). However nowadays the lisp implementations (CCL/SBCL specifically) are fast/advanced…

What sort of tools are required for this? I'd like to start taking Lisp seriously, but workflow stories like this tend to hinge on using Emacs/SLIME. Is that always the case? EDIT: I suppose what I'm asking is whether you could elaborate more on what this looks like, in practice.

Actually no, I use vim/slimv almost exclusively. I think Sublime2 might also have features that let you "hook into" a remote REPL, but I'm not very familiar. There may be other editors with lisp integration as well, but I'm not sure what they are.

If you do like vim, slimv is a really great option for lisping.

Re: Why Lisp?

#48

Post by PuercoPop »

Foxboron wrote: post #24
PuercoPop wrote: post #17

Earlier quoted context omitted.

Just to expand on your comment. One can write the equivalent code for a for in python[0] but one can't make python rewrite itself. [0]: https://gist.github.com/PuercoPop/9d192f94f88074d06625

cough I'd love to say it's possible, but with a few modifications. https://github.com/hylang/hy http://docs.hylang.org/en/latest/language/api.html?highlight...

It is possible with macropy as well. But both hylang and macropy depend on the load module hook to run the transformation iirc. So the transformation don't work the the __main__ module.

Re: Why Lisp?

#49

Post by beeworker »

Xophmeister wrote: post #26
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…

One difference is flow control. When you call a function, all the arguments are evaluated before being passed into the function. If you want to delay evaluation, you have to wrap the argument values in a function. When you call a macro, the text forms get passed with no evaluation.

Say Clojure forgot to ship with the boolean "or". "or" should evaluate its arguments one at a time (to allow for short circuiting) and return the first non-false value. You could do this with functions, but you have the source-level overhead of manually wrapping everything, and performance overhead of defining and passing an anonymous function for each argument. With a macro, at compile time you just translate the "or" macro into a simpler form that uses "if". This is how Clojure actually implements "or":

    (defmacro or
      "Evaluates exprs one at a time, from left to right. If a form
      returns a logical true value, or returns that value and doesn't
      evaluate any of the other expressions, otherwise it returns the
      value of the last expression. (or) returns nil."
      {:added "1.0"}
      ([] nil)
      ([x] x)
      ([x & next]
          `(let [or# ~x]
             (if or# or# (or ~@next)))))

Re: Why Lisp?

#50

Post by kazinator »

dfan wrote: post #37
Xophmeister wrote: post #26

Earlier quoted context omitted.

Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…

One qualitative difference in expressive power comes from the fact that functions first evaluate all their arguments and macros don't.

Ah, but that is not the case in some languages in which arguments are evaluated lazily. Usually the iron-man version of this question is: "if I have a non-strictly evaluated language with higher order functions, do I still need macros?"

A part of the answer is: you probably don't need the kinds of macros which cover up machine-generated lambdas, which simulate non-strict evaluation in strictly evaluated Lisp programs! The compiler for your language already has these "macros" in its compiler.

The argument why "you always need macros no matter what else you have" is that your language has "hard-coded macros": the grammar rules in a compiler, which match patterns and transform bits and pieces to produce AST fragments. If you don't have macros, then that set of "hard-coded macros" is all you have.

So, even in a functional language with nonstrict evaluation, you're using macros. It's hard to make a convincing argument that they provide all the expressivity you would conceivably ever need. (And their existence and use defeats any argument that you don't need macros at all).

Post reply on HN