Live data from Hacker News

Why Lisp?

blog.rongarret.info

81–90 of 248 posts

Re: Why Lisp?

#81
post #75

Earlier quoted context omitted.

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

I don't think there are very many "real world" problems that you CAN solve in Lisp, and CANNOT solve in Python. Anything [0] you can write in Python, you can likely solve in Lisp, probably in similar line count (without macros). One thing I __really__ miss from working in lisp is the idea that I can reload things in the repl. In Python, once I've imported something, I can't really redefine it without pasting in the d…

I reload things in ipython all the time, just do an execfile (and maybe be sure to define __name__ to something besides '__main__' so it doesn't trigger the usual checks).

The sage version, and maybe this is backported to ipython by now, I don't know, you can do an %attach on a file and it gets reloaded into the workspace every time it changes.

Re: Why Lisp?

#82

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…

The sheer number of answers you've got should tell you that indeed there is something about those macros. But you need to 'get' them yourself to appreciate them.

Each answer exposes one or more facets of macros. Indeed, there is not just 'one' thing that make them worthwhile.

Re: Why Lisp?

#83

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 agree. Macros are what made lisp, not parentheses.

However, if we broaden the concept a little, we can do this type of macros for any language with a meta-layer such as MyDef. e.g. if you observe certain foreach pattern in Java, you can make a macro for that pattern and have the meta-layer look out and translate that for you (like having an automatic translator between you and javac. All you need is a scope type macro. Conventional macro packages like M4 does not provide such, but MyDef does. Example:

    &call each_member, AList
        # java code that work on $(member)
where the macro may be defined as

    subcode: each_member(list)
        Enumeration e = $(list).elements();
        while (e.hasMoreElements()){
            String name = (String) e.nextElement();
            $(set:member=name)
            BLOCK
        }
  
Where it is understood that the definition can be any literal block pattern.

Re: Why Lisp?

#84

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?

Not a dumb question at all, and yes, that's more-or-less what Lisp macros are, albeit more elegant because you're using the same language to write your code as you use to write the macros that manipulate the code.

Re: Why Lisp?

#85

Earlier quoted context omitted.

How about syntactic extensions: (defmacro unless (test &body body) `(if (not ,test) ,@body))

That's a theoretical problem, not a real world problem.

I'm not quite sure how being able to extend syntax is a theoretical problem. It was just a basic example for brevity.

There are many more examples of macros that solve real world problems, such as writing a compiler for an embedded DSL that is tuned to solving your real problem that allows expressivity and brevity that you would never see without the use of macros.

Re: Why Lisp?

#86

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?

    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 let you write your own operators - that work just like the ones built into the language itself.

Here's an example. Let's say you want to print a list of names.

In a language without an operator specifically for going over lists - and without macros - you may have to write:

    ListIterator iterator = namesList.GetListIterator();
    while(iterator.HasMoreItems()) {
        string name = iterator.GetNextItem();
        print(name);
    }
If you have a language that supports macros, you can create a macro called forEachItemInList. And then it'll work just like it came with the language all along:

    forEachItemInList(string currentName in namesList)
    {
        print(currentName);
    }
If you count how many words the non-macro solution took, it's 13. The macro solution takes 7. Having to solve a problem with more code means more time to understand, teach, write, test, debug, and document - so savings like this can really add up.

And there's also the subjective part. Having to write code like in the first example just isn't satisfying. You have to repeat yourself constantly. You may think, "Look, I loop over lists all the time. And it's always the same pattern: I call GetListIterator(), I do a 'while' loop while it HasMoreItems(), then I call GetNextItem(), etc. Why can't I just inform the compiler of the general pattern - and then tell it how to fill in the blanks when I need to actually loop over a list?"

And that's what macros let you do.

Re: Why Lisp?

#87

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.

All Turing-complete languages are equivalent and can solve the same set of problems. The issue is not whether you can or can't do it, but how much work it will take and how painful the process will be.

Also when you learn some Lisp, you start to realize how often people are greenspuning[0] things in their projects.

[0] - http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Re: Why Lisp?

#88

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…

Macros are great.

I'm writing a hy-like lisp language that compiles to lua. A lot of features (Simple OO, list/dict comprehensive etc.) are written in macros.

https://github.com/larme/hua/tree/master/hua/core

On the other hand, they may be difficult to debug.

Re: Why Lisp?

#89
post #75

Earlier quoted context omitted.

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

I don't think there are very many "real world" problems that you CAN solve in Lisp, and CANNOT solve in Python. Anything [0] you can write in Python, you can likely solve in Lisp, probably in similar line count (without macros). One thing I __really__ miss from working in lisp is the idea that I can reload things in the repl. In Python, once I've imported something, I can't really redefine it without pasting in the d…

ipython has a killer autoreload function: http://ipython.org/ipython-doc/stable/config/extensions/auto...

In [1]: %load_ext autoreload

In [2]: %autoreload 2

In [3]: from foo import some_function

In [4]: some_function()

Out[4]: 42

In [5]: # open foo.py in an editor and change some_function to return 43

In [6]: some_function()

Out[6]: 43

It's nothing like a proper lisp repl, but you can sorta do this in vanilla python too, if you don't mind some annoyances. `reload` reloads a module:

>>> import mymodule

>>> print mymodule.myfunction()

3

>>> reload(mymodule)

>>> print mymodule.myfunction()

5

Downside is you have to use the module, `from mymodule import function` won't reload.

Re: Why Lisp?

#90
post #69

Earlier quoted context omitted.

Or, once you have lazy evaluation (like in Haskell), for that matter.

Laziness can achieve a similar thing in that case (less elegantly, IMO), but there are other uses for macros that can't be solved with laziness.

Look at the uses for Template Haskell, for example.

That's basically Haskell's macro system. And it's used quite a lot, though it's kind of arcane.

If you want to create an abstraction that defines one or several data types, you'll think hard about whether you can use some kind of type-level programming instead—but if that's not possible, or not convenient, you can use TH macros.

For example, the `lens` package defines TH macros for creating special kinds of accessors that are tedious to write by hand.

Post reply on HN