Hacker News Reader

Comment by AnimalMuppet | Hacker News Reader

Well, let's see.

Lisp has no syntactic cruft? It has (almost) no syntax, so there's less room for cruft. That said... cons? car? cdr? That's your syntax? That's not cruft? Seriously? There may be less total cruft, but the percentage of cruft might still be higher...

There's less overall to learn? If you mean to master the syntax, sure, that's true.

You'll be writing real, useful programs in Lisp sooner than you could with other languages? That's a much more arguable point. There's more to being able to effectively program in Lisp than learning the syntax (as there is for every language). Is that "more" easier to learn for Lisp than for other languages? I have no data, but for the web site's claim, I'd at least say "citation needed".

View on HN

I believe that Lisp requires years to master.

If you're a bright developer, who puts in time eagerly, it will take at least six months before you begin to "get it".

At that time you may start itching to evangelize to others, but those who have not put in the time will not get it.

It's not realistic to try to make someone see in one or two e-mails or postings what took you a year to see for yourself.

I think the whole enlightenment thing w.r.t. lisp is overblown.

From what vantage point?

I'm not the above poster but I think the power of macros is way overhyped and not nearly as strong as people claim. I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true.

A recent example from personal use is continuations. Scheme has them as a first-class object. Common Lisp does not, but a common claim is that you can write macros to provide continuations. Some people have: there's "cl-cont" available on Quicklisp, which is a macro that will code-walk your functions to turn them into continuation-passing style and thus allow you to use continuations in those functions.

So that's great, right? Common Lisp now totally has continuations? Not at all. In order to get this feature, you need to wrap ahead of time (specifically, at compile time) the functions you want to be continuable, and all of their callers, in this macro. You cannot simply use a function that you've been given as part of a continuation, it had to have been compiled under this macro.

That's where the power of macros completely falls down and, in my opinion, gets completely overblown. Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time. You can't apply any of that power to already-existing artifacts.

That's right; macros need a target language to expand to, and that target language needs to seamlessly inter-operate with the surroundings and with the forms that are inserted into it. Some semantics is simply not available without transforming the entire program in which the macro call occurs.

Yes, exactly my point. Macros are very powerful but not a magic sauce that makes Common Lisp infinitely extendable. Some things you actually need to change the underlying implementation for.

> I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true.

Which is not surprising. Actually nobody with a clue makes such a claim.

Still, Lisp macros have a wide variety of very useful applications.

> Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time.

Still quite useful. From relatively simple stuff which makes to code more readable to complex macros like ITERATE.

You'll note that I never said it was not useful, but rather it was not this powerful magic sauce that can do anything.

> Which is not surprising. Actually nobody with a clue makes such a claim.

Most Lisp books make this claim.

> Most Lisp books make this claim.

For sure not.

I worked through SICP years ago and used scheme as my primary language for a couple of years. I write in an ML dialect at my day job.

1. lisp got a lot of stuff wrong; there's really no reason not to use scheme.

2. lisp syntax is more something to overcome than something to become "enlightened" about. Language syntax no longer has to be motivated by ease of parsing.

3. Dynamic typing only gets so enlightening. At the end of the day, type theories are where the rubber hits the road.

4. Macros don't excite me much. I mean, they're cool, sure. Okay.

At the end of the day, there's a lot more exciting stuff out there (e.g. any math class beyond the calculus sequence or so) that people get way less worked up about.

It's possible to understand lisp, think that there are important ideas there, but not go around evangelizing. Most smart people who study something non-trivial don't evangelize.

The Lisp language syntax is not motivated by 'ease of parsing'. It is motivated by the 'code as data' idea, which enables a lot of useful source transformations to be implemented AND used in a relatively easy way. One of the applications of that are macros.

Scheme got a lot wrong from a practical perspective. Use Lisp instead.

Type theories are over-hyped. 99.99% of all software is written in languages without advanced type systems.

Macros are nothing for 'excitement'. They are a tool. They enable the user to write source transformations, which has several applications in Lisp: control structures, compile-time computation, etc etc.

Lisp's macros don't even get variable binding right. Treatment of bound variables was one of the explicit purposes for the development of lambda calculus in the first place. Imho if you get something as fundamental as this wrong, you don't get to play.

But Im not going to get into a language war.

Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.

Given that macros 'don't get variable binding right', they are still amazingly useful.

> Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.

Many of the powerful ideas in software development are available in Lisp.

I mean, a really solid understanding of substitution is probably one of the major contributions of lambda calculus. For what's effectively an implementation to get that wrong is pretty pathological. And also, there's no reason to defend it. It's a bug. Period. Yet here we are.

And there's a whole hell of a lot more in the world than software development...

To the extent that lisp captures any of these other foundational ideas/theories/techniques, type theory does better (which is what I was pre-empting with my original reference, not the role of type systems in the world of practical software development).

> Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.

Lisp is not a version of lambda calculus. It's a programming language. Macro programming in Lisp works fine in many cases.

> type theory does better ... not the role of type systems in the world of practical software development).

Lisp is about practical software development.

Right, okay, so lisp is primarily a programming language for practical software development. That's really my whole point.

I'd argue that there are lots of other settings with ideas a powerful or more powerful than whatever it is each individual evangelist feels someone should get out a lisp. Yet none of these other things have enlightened evangelists pushing the product.

That's all I'm saying.

lol @ random downvotes for criticizing lisp. Set and match.

I don't think that any Lisp programmer downvoted him.

Reply on news.ycombinator.com