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

91–100 of 248 posts

Re: Why Lisp?

#91

Post by mbrock »

eatonphil wrote: post #78
chaoky wrote: post #53

Earlier quoted context omitted.

A higher order function doesn't serve the same purpose as a macro. A higher order function is meant to be applied, called, composed etc. A lisp macro is a different type of abstraction. For example, many people think that macros are just hiding lambda's of higher order functions. This is wrong. A macro abstracts over implementation details of a construct to make it read naturally. For example, you can write a functio…

In what language are you writing?

That might be pseudo-code, but Dylan has a similar syntax, like Lisp without the explicit S-expressions.

Re: Why Lisp?

#92

Post by swuecho »

kazinator wrote: post #39
swuecho wrote: post #22

Earlier quoted context omitted.

there is two sides. probably, one evil thing is you have to deal with every other's abstraction and it will make you frustrated when there is a large codebase and a deadline.

Let's see, what would I rather deal with. * Another programmer's 15 function API, and a document on how to use it properly? * Or another programmer's 15 function API, along with three macros which use the API properly, and capture all the scenarios I need based on a couple of examples.

generally, even bad api is easier to understand or debug than macro. and not all macros are well written.

Re: Why Lisp?

#94

Post by swuecho »

GFK_of_xmaspast wrote: post #72
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's kind of cool how in lisp you're supposed to do macros to change major aspects of how the language behaves, but in C if you try having a little bit of fun with #define and the pre-processor everybody starts getting just extremely rude at you.

That is part of the reason. everybody think lisp cool, but very few programmer use lisp.

Re: Why Lisp?

#95

Post by stephengillie »

WalterGR wrote: post #86
stephengillie wrote: post #74

Earlier quoted context omitted.

I'm sorry for asking a dumb question; I'm a sysadmin not a software developer: Is this similar to needing a dozen nearly-identical lines of code, writing one, then using Excel to manipulate the other 11 lines into what you want, then copying it back (and cleaning tabs in the process)? Essentially programmatically writing the program - is that what Lisp's macros are?

Essentially programmatically writing the program - is that what Lisp's macros are? Macros are often described that way. "Lisp macros let you write code that writes code!" While that's a true statement, it's kind of useless for coming to an initial understanding of what macros let you really do . Think of it this way. Programming languages have built-in control flow operators like if-then, do, while, and for. Macros l…

Thanks for describing this. In one way it looks like writing a function and calling it. I suppose macros are a faster way.

Re: Why Lisp?

#96

Post by kazinator »

GFK_of_xmaspast wrote: post #79
kazinator wrote: post #39

Earlier quoted context omitted.

Let's see, what would I rather deal with. * Another programmer's 15 function API, and a document on how to use it properly? * Or another programmer's 15 function API, along with three macros which use the API properly, and capture all the scenarios I need based on a couple of examples.

How's this any different than taking a big ugly api and writing three shims around it to call it in the way you want?

The difference isn't whether or not code is written; the question is who/what writes it:

- Does the machine write it, using a reliable syntax rule loaded into the compiler (implemented as a macro); or

- Does the programmer, by hand (or with textual preprocessing, copy and paste, IDE help, ...).

Macros can be as smart as you want them to be.

Re: Why Lisp?

#97

Post by TeMPOraL »

lisper wrote: post #19
WalterGR wrote: post #11

Earlier quoted context omitted.

Seconding the Clozure CL recommendation. It supports threads on Windows, which really expands your options if you want to do web development in Common Lisp. I run Linux on my web servers but develop from a Windows desktop. CCL works great on both.

Thirding CCL :-) The built-in IDE and ObjC integration are awesome for developing on a Mac. And you can deploy finished code on Linux and Windows.

Fourthing CCL - it's stable on Windows and fast enough for writing games :).

Also, it's the best free CL for targeting Raspberry Pi - unlike SBCL, CCL supports native threads there, and with the weak but quad-core processor of RPi2, the difference is very noticeable.

Re: Why Lisp?

#98

Post by TenDecigrams »

snikeris wrote: post #64
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…

My favorite example for this is the lame idiom you see in Java code: if (log.isDebugEnabled()) { log.debug("expensive" + debug + message); } This is "better" than just log.debug(...) because with the latter, your expensive log message argument needs to be evaluated even if debug is disabled. However, in a language w/ macros, you just say: (debug (str "expensive" debug message)) and these considerations are already ta…

Edit: Ohhh! I see! The message isn't evaluated until after! Got it.

I don't understand why this is special?

Why can't you rewrite log.debug to include the check?

    func debug(m string) {
        if log.isDebugEnabled() {
            log.debug(m);
        }
    }
What makes macros special in this case?

Re: Why Lisp?

#99

Post by btilly »

stephengillie wrote: post #74
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…

I'm sorry for asking a dumb question; I'm a sysadmin not a software developer: Is this similar to needing a dozen nearly-identical lines of code, writing one, then using Excel to manipulate the other 11 lines into what you want, then copying it back (and cleaning tabs in the process)? Essentially programmatically writing the program - is that what Lisp's macros are?

Yes, except more reliable.

The fundamental unit of Lisp is expressions of the form (FOO ...). There are three basic cases.

1. FOO is one of a finite list of special forms. Those are the irreducible base of that language.

2. FOO is a function. In which case the ... is evaluated as Lisp (possibly including doing things like expand out other functions) before being passed to that function.

3. FOO is a macro. In which case the ... bit is turned into a list of things, but NOT evaluated, passed to the macro to be rewritten, and then the result is turned into an expression that is then evaluated by the same rule.

This is not completely true. There is a preprocessing step called reader macros that can do things like turn `(this expression) into (QUOTE this expression) to save typing. But those are very sparingly used.

Re: Why Lisp?

#100

Post by dragonwriter »

TenDecigrams wrote: post #98
snikeris wrote: post #64

Earlier quoted context omitted.

My favorite example for this is the lame idiom you see in Java code: if (log.isDebugEnabled()) { log.debug("expensive" + debug + message); } This is "better" than just log.debug(...) because with the latter, your expensive log message argument needs to be evaluated even if debug is disabled. However, in a language w/ macros, you just say: (debug (str "expensive" debug message)) and these considerations are already ta…

Edit: Ohhh! I see! The message isn't evaluated until after! Got it. I don't understand why this is special? Why can't you rewrite log.debug to include the check? func debug(m string) { if log.isDebugEnabled() { log.debug(m); } } What makes macros special in this case?

The point was that "debug" and "message" parts in the example were arbitrarily complex expressions which were computationally expensive to evaluate. Your wrapping of log debug would still require evaluating them to get the message string unconditionally, even when debug logging is not enabled.

Of course, with support for first-class functions, you could do something like:

  func debug(produceMessage ()->string) {
    if log.isDebugEnabled() {
      log.debug(produceMessage());
    }
  }
Post reply on HN