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".
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).
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.
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.
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".