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

171–180 of 248 posts

Re: Why Lisp?

#171

Post by TuringTest »

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…

The first order function is evaluated at runtime, every time the program is executed. Macros are expanded at compile time, so they will be calculated just once. Thus the syntactic sugar added by the macro doesn't incur a time penalty.

This can provide an important speed improvement for complex macros or code used often, in tight loops or frequently called functions (it's like using inline methods in .h files in C++).

Re: Why Lisp?

#172

Post by lisper »

ScottBurson wrote: post #129
lisper wrote: post #111

Earlier quoted context omitted.

> XML was never designed as a data serialization format. It's a markup language. Those two things are not mutually exclusive. > Likewise, JSON is a subset of a general-purpose programming language's literal notation that happened to be very fast to parse in a browser by virtue of the browser implementing that language. That's true. That is not in conflict with anything I said. > The problem is that there's no one-siz…

>> XML was never designed as a data serialization format. It's a markup language. > Those two things are not mutually exclusive. I beg to differ. I just replied to someone else about this: https://news.ycombinator.com/item?id=9509110 I agree with your last paragraph, though. There is a timelessness about S-expressions. As a side point, I would add that the distinction between strings and symbols is important, and nei…

The comment you were responding to got deleted, which makes it a little hard to figure out what's going on there.

But I am completely nonplussed at your assertion that markup and serialization are mutually exclusive. There is a 1-to-1 correspondence (actually multiple 1-to-1 mappings) between XML and S-expressions, so whatever you can do with sexprs you can do with XML modulo some trivial transformation. The ONLY difference is in the amount of punctuation and redundancy.

> the distinction between strings and symbols is important

Yeah, that's a good point.

> neither XML nor JSON has it

That's not quite true. It's not that JSON doesn't have symbols, it's that Javascript doesn't have symbols. And XML doesn't have symbols natively, but you can easily gin them up yourself, e.g. foo or .

Re: Why Lisp?

#173

Post by stickfigure »

WalterGR wrote: post #58
IshKebab wrote: post #16

Earlier quoted context omitted.

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.

When reading other people's code you now effectively have to learn what "language" they use too. That's well said, and in fact it's not uncommon to talk about Lisp's capacity for crafting the language to solve the problem at hand. Paul Graham's essay "Programming Bottom-Up" explains it really really well: "Experienced Lisp programmers divide up their programs differently. As well as top-down design, they follow a pri…

My experience with heavily metaprogrammed Ruby is that this story has a dark side. Yes, when language and program fit one another well, you end up with code which is clear, small, and efficient. That is true... until you need to add a new feature that was not accounted for in the language design. Now you have to wade into the code of the "compiler".

Abstraction generally gives up flexibility to obtain conciseness. Certainly a balance must be struck, but "not flexible enough" has caused me vastly more pain than "not concise enough". As a consultant who frequently wades into other people's code, I generally consider metaprogramming to be a scourge.

Re: Why Lisp?

#174

Post by dschiptsov »

There are whole books which answers that question. The one I am aware of is pg's "On Lisp" which explains everything clearly without any "Haskellish or monadic mysticism".

There is also the famous essay "Beating an average" and this very site as a walk of their talk.

There are also SICP and PAIP and Norvig's Lisp Style Guide.

Read the best thinkers.

Re: Why Lisp?

#176

Post by reddytowns »

For me, I think the most important reason for working with lisp and its variants is that it allows you to (and you should) code from the middle.

When I first started programming, and for a long while, I'd think top down. What do I got? Then, how can I iterate through that to do the operations I want and then build up what I need?

With lisp, the ability to reuse code in closures is so easy, you can afford to think a different way. What are the most basic, clean and simple, operations I need to do? (not necessarily in order I need to do them) This includes conversion, summing results, iterating through a structure, etc.

After writing functions for those, you can quite easily plug them all together without much thought.

You end up with code that is non-redundant, clear, reusable, easy to debug, and flexible.

Re: Why Lisp?

#177

Post by FeepingCreature »

MichaelGG wrote: post #150
ufo wrote: post #132

Earlier quoted context omitted.

You pass a lambda that returns the debug message. With javascripty syntax: debug( function(){ return "my expensive log message" }) BTW, if your language is lazily evaluated (like Haskell) then you don't need to do this because arguments will only ve evaluated when they are needed.

The downside there is you can still end up allocating a closure. Whereas an expanded macro shouldn't cost anything. (A sufficiently smart compiler might be able to optimize the closure allocation.)

A sufficiently modern language (like, saaaaay, D2) could also give you a type like "closure you don't intend to escape" (let's call this a "scoped closure", or if you will, "scope string delegate()"), and eschew allocation entirely without requiring optimization.

Re: Why Lisp?

#178

Post by eru »

dllthomas wrote: post #119
aidenn0 wrote: post #106

Earlier quoted context omitted.

The majority of macros I write could be represented with HOF and lexically-closed lambdas. That adds significant extra syntax when you use them though. Consider a classic pattern of a with macro: (with-mutex-held-macro (some-mutex) (do-stuff)) (call-with-mutex-held-hof some-mutex (lambda () (do-stuff)) A minor advantage is that a macro will be expanded in-line; a Sufficiently Smart Compiler could transform the HOF ve…

One thing to note is that you're using the macro or lambda to delay evaluation. In a lazy-by-default language, that's unnecessary (which is a part of why macros are less useful in Haskell).

True. They are still useful enough for Template Haskell to exist.

Re: Why Lisp?

#179

Post by igravious »

(I have a subtle optimization for S-expression syntax)(I am surprised nobody ever thought of it)(When S-expressions are in a sequence use an extra (special) delimiter plus the regular token separator to separate expressions)(Maybe use dot? (period I think some call it))

Like so. I think it could catch on. And you get rid of so many round bracket block delimiters (at least for S-expressions on the same level. for nesting you obviously need them) that it makes reading a lot easier. Also make the language modal and have the default be the indicative mood. Maybe replace "." with "?" for interrogative mood? Maybe elide ".)" to ")" as another optimization?

Re: Why Lisp?

#180

Post by wtetzner »

platz wrote: post #168
mbrock wrote: post #90

Earlier quoted context omitted.

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 defin…

using macros to deal with boilerplate, although useful, though is of a different order than things that simply cannot be expressed without macros

Which things cannot be expressed without macros? Macros run at compile time, and just output normal code in the language.

I think being able to generate types is a very useful and important use of macros. In fact, (depending on whether or not your macros can have side effects) you could use macros to implement something like F#'s type providers.

Post reply on HN