![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
liam_on_linuxA chap on CIX responded to my last piece on Lisp, and it led to a long answer, which my CIX client then crashed and threw away. So if I have to rewrite it, I'll do it here and it will maybe be read by a few more people. Perhaps, ooh, a dozen.
> Trouble is, it comes across a bit as a "lost wisdom of the ancients"
> story.
Yes, it does. But I am OK with that, if I can turn it into a coherent article that tells a comprehensible story.
> Lisp was a niche language in 1960, it's a niche language today. It
> has been a niche language for all the intervening period and I expect it
> to be a niche language for all time to come.
It's a fair point, but there are ways around that. One of the problems, though, is that the Lisp community are very resistant to them.
The thing that my research and my various discussions online are leading me to believe is this:
There are many things about Lisp that used to be distinctive, powerful features decades ago – not merely the functional programming model, but lambda calculus, closures, higher-order functions, tail recursion, lazy evaluation and so on. However, today, other languages can do these things. Perhaps some can do all of them, others only a subset, but that doesn't matter if these are the tools you need to crack your particular problematic nut. And the other languages that include these features do not have the feature that is the biggest problem with Lisp: its obfuscatory syntax, or as the Lisp advocates would have it, its *lack* of syntax. (Of course, as in the case of Perl, for example, they may have their own obfuscatory issues.)
But the problem is that that syntax is both the biggest obstacle to learning and using it, and yet at one and the same time, also absolutely integral to the one feature that sets Lisp apart from pretty much all other languages: its syntactic macros.
Lisp manipulates structured lists. Lisp code comes in the form of just such structured lists. Therefore, it is possible to write Lisp code that transforms parts of itself as required to solve particular problems. It seems to me that what sets the various Lisps apart from other languages are Lisp macros.
This seems to be the core of the thing. The power of Lisp is in its macros; you need the syntax to make the macros work; so even though the syntax is really hard to deal with, you do so anyway, because it facilitates the macros. This seems to be an article of faith among Lisp programmers, as discussed by Xah Lee here (among other places):
http://xahlee.info/comp/lisp_syntax_vs_perl_syntax.html
As he says, it's like a religion, or more to the point, a cult.
And Lisp macros are really hard to explain. I can illustrate this a bit, albeit perhaps poorly, by unpacking a blog post in reverse.
Here, on the original Ward Cunnigham Wiki, is an interesting if flawed attempt to explain Lisp macros. It's long and it's not entirely successful but it's one of the better ones I've found so far.
http://c2.com/cgi/wiki?LispMacro
The trouble is, it doesn't entirely work. This frustrating inability to convey what they are, how they work and more to the point, why they are so powerful seems to be a familiar sensation to Lisp gurus - for example:
https://news.ycombinator.com/item?id=645338
Which finally leads me to the blog post that is the source of those links:
http://www.loper-os.org/?p=401
It makes some good points, but I am not sure that it will stand alone very well unless you've read a lot of the other posts on that site - which I have now. It's not very long - worth a go.
So this is one of the key things. Lisp's biggest weakness is also Lisp's biggest strength, in a sort of demented yin-yang relationship which erects a high wall around the whole language – and it doesn't really help to try to persuade people of how wonderful it would be if they only climbed that wall.
And that is what is sometimes called the Lisp Curse:
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Or, expressed more prosaically, in the title of another Stanislav Datskovskiy blog post:
"Where Lisp Fails: at Turning People into Fungible Cogs."
http://www.loper-os.org/?p=69
Which incidentally has a wonderful footnote:
<<
[1] Ever wonder why it is customary to speak of the wildly different Common Lisp, Scheme, ZetaLisp, Emacs Lisp, etc. as though they were a single language? I would like to suggest that we start referring to C/C++, Java, Python, etc as ALGOL.
>>
- - - - - -
But the thing is, it's becoming increasingly apparent to me that actually, this Big Problem *is* fixable. Yes, Lisp's prefix notation makes it much easier to write macros which can manipulate and transform Lisp code, but you *can* actually write a set of macros that transforms Lisp into an infix-notation, algebraic style language. And if you do that, it suddenly becomes quite a clear, simple, readable one.
And once done, while it becomes harder to write syntactic macros, it is still possible.
There have been multiple attempts to do this, again, as documented by the estimable Xah Lee:
http://xahlee.info/comp/lisp_sans_sexp.html
Since then, I've rewritten the Wikipedia article on CGOL to make it clear that it doesn't only run on the obsolete MacLisp dialect but was also ported to Common Lisp:
https://en.wikipedia.org/wiki/CGOL
I've also discovered a new one that I was previously unaware of – PLOT: "Programming Language for Old Timers".
Discussion: http://lambda-the-ultimate.org/node/3253
Homepage: http://users.rcn.com/david-moon/PLOT/
PLOT was devised by one of the less-well-known old-time Lisp gurus, David Moon, meaning it has an impeccable pedigree.
The discussion page there talks a little bit about how an algebraic-notation language can still have syntactic macros. This page, from one of the other recent projects to give Lisp a more familiar, readable syntax, goes into more depth:
http://www.dwheeler.com/readable/
He has a more specific discussion about the syntax issues here:
http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html
And a more recent presentation as a movie, here:
http://readable.sourceforge.net/
- - - - -
(I said this on Facebook a while ago, in the discussion here: https://www.facebook.com/lproven/posts/10151634320686691 )
So, one possible answer to the problem of Lisp being such a niche language might be, much though the Puritan Lisp illuminati scorn it, to incorporate one, or better still all, of these approaches to making a more readable, more familiar, infix-notation Lisp.
After all, JMC himself only ever intended S-expressions to be the low-level language. But it became apparent that some Giant Brains are able to learn to work in S-expressions and need nothing more. Good for them. Mere mortals, I fear, need something more.
There are at least 4 candidates that readily spring to mind as simpler meta-languages that could be implemented on top of raw Lisp.
#1 CGOL - (as just mentioned and linked to above)
#2 Logo - https://en.wikipedia.org/wiki/Logo_(programming_language)
#3 Dylan - https://en.wikipedia.org/wiki/Dylan_(programming_language)
#4 PLOT
I put CGOL first because it already exists; it's there, it's freeware and it works on Common Lisp.
Logo is simple enough for children -- and me -- to grasp.
And Dylan, I think, is possibly the single biggest missed opportunity in the history of pre-NeXT-merger Apple.
All were bootstrapped on Lisp before. All are FOSS. It's possible.
Sorry if this is a bit disjoint. It's an attempt to recreate a long, more coherent post that was lost. Best I can do.
> Trouble is, it comes across a bit as a "lost wisdom of the ancients"
> story.
Yes, it does. But I am OK with that, if I can turn it into a coherent article that tells a comprehensible story.
> Lisp was a niche language in 1960, it's a niche language today. It
> has been a niche language for all the intervening period and I expect it
> to be a niche language for all time to come.
It's a fair point, but there are ways around that. One of the problems, though, is that the Lisp community are very resistant to them.
The thing that my research and my various discussions online are leading me to believe is this:
There are many things about Lisp that used to be distinctive, powerful features decades ago – not merely the functional programming model, but lambda calculus, closures, higher-order functions, tail recursion, lazy evaluation and so on. However, today, other languages can do these things. Perhaps some can do all of them, others only a subset, but that doesn't matter if these are the tools you need to crack your particular problematic nut. And the other languages that include these features do not have the feature that is the biggest problem with Lisp: its obfuscatory syntax, or as the Lisp advocates would have it, its *lack* of syntax. (Of course, as in the case of Perl, for example, they may have their own obfuscatory issues.)
But the problem is that that syntax is both the biggest obstacle to learning and using it, and yet at one and the same time, also absolutely integral to the one feature that sets Lisp apart from pretty much all other languages: its syntactic macros.
Lisp manipulates structured lists. Lisp code comes in the form of just such structured lists. Therefore, it is possible to write Lisp code that transforms parts of itself as required to solve particular problems. It seems to me that what sets the various Lisps apart from other languages are Lisp macros.
This seems to be the core of the thing. The power of Lisp is in its macros; you need the syntax to make the macros work; so even though the syntax is really hard to deal with, you do so anyway, because it facilitates the macros. This seems to be an article of faith among Lisp programmers, as discussed by Xah Lee here (among other places):
http://xahlee.info/comp/lisp_syntax_vs_perl_syntax.html
As he says, it's like a religion, or more to the point, a cult.
And Lisp macros are really hard to explain. I can illustrate this a bit, albeit perhaps poorly, by unpacking a blog post in reverse.
Here, on the original Ward Cunnigham Wiki, is an interesting if flawed attempt to explain Lisp macros. It's long and it's not entirely successful but it's one of the better ones I've found so far.
http://c2.com/cgi/wiki?LispMacro
The trouble is, it doesn't entirely work. This frustrating inability to convey what they are, how they work and more to the point, why they are so powerful seems to be a familiar sensation to Lisp gurus - for example:
https://news.ycombinator.com/item?id=645338
Which finally leads me to the blog post that is the source of those links:
http://www.loper-os.org/?p=401
It makes some good points, but I am not sure that it will stand alone very well unless you've read a lot of the other posts on that site - which I have now. It's not very long - worth a go.
So this is one of the key things. Lisp's biggest weakness is also Lisp's biggest strength, in a sort of demented yin-yang relationship which erects a high wall around the whole language – and it doesn't really help to try to persuade people of how wonderful it would be if they only climbed that wall.
And that is what is sometimes called the Lisp Curse:
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Or, expressed more prosaically, in the title of another Stanislav Datskovskiy blog post:
"Where Lisp Fails: at Turning People into Fungible Cogs."
http://www.loper-os.org/?p=69
Which incidentally has a wonderful footnote:
<<
[1] Ever wonder why it is customary to speak of the wildly different Common Lisp, Scheme, ZetaLisp, Emacs Lisp, etc. as though they were a single language? I would like to suggest that we start referring to C/C++, Java, Python, etc as ALGOL.
>>
- - - - - -
But the thing is, it's becoming increasingly apparent to me that actually, this Big Problem *is* fixable. Yes, Lisp's prefix notation makes it much easier to write macros which can manipulate and transform Lisp code, but you *can* actually write a set of macros that transforms Lisp into an infix-notation, algebraic style language. And if you do that, it suddenly becomes quite a clear, simple, readable one.
And once done, while it becomes harder to write syntactic macros, it is still possible.
There have been multiple attempts to do this, again, as documented by the estimable Xah Lee:
http://xahlee.info/comp/lisp_sans_sexp.html
Since then, I've rewritten the Wikipedia article on CGOL to make it clear that it doesn't only run on the obsolete MacLisp dialect but was also ported to Common Lisp:
https://en.wikipedia.org/wiki/CGOL
I've also discovered a new one that I was previously unaware of – PLOT: "Programming Language for Old Timers".
Discussion: http://lambda-the-ultimate.org/node/3253
Homepage: http://users.rcn.com/david-moon/PLOT/
PLOT was devised by one of the less-well-known old-time Lisp gurus, David Moon, meaning it has an impeccable pedigree.
The discussion page there talks a little bit about how an algebraic-notation language can still have syntactic macros. This page, from one of the other recent projects to give Lisp a more familiar, readable syntax, goes into more depth:
http://www.dwheeler.com/readable/
He has a more specific discussion about the syntax issues here:
http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html
And a more recent presentation as a movie, here:
http://readable.sourceforge.net/
- - - - -
(I said this on Facebook a while ago, in the discussion here: https://www.facebook.com/lproven/posts/10151634320686691 )
So, one possible answer to the problem of Lisp being such a niche language might be, much though the Puritan Lisp illuminati scorn it, to incorporate one, or better still all, of these approaches to making a more readable, more familiar, infix-notation Lisp.
After all, JMC himself only ever intended S-expressions to be the low-level language. But it became apparent that some Giant Brains are able to learn to work in S-expressions and need nothing more. Good for them. Mere mortals, I fear, need something more.
There are at least 4 candidates that readily spring to mind as simpler meta-languages that could be implemented on top of raw Lisp.
#1 CGOL - (as just mentioned and linked to above)
#2 Logo - https://en.wikipedia.org/wiki/Logo_(programming_language)
#3 Dylan - https://en.wikipedia.org/wiki/Dylan_(programming_language)
#4 PLOT
I put CGOL first because it already exists; it's there, it's freeware and it works on Common Lisp.
Logo is simple enough for children -- and me -- to grasp.
And Dylan, I think, is possibly the single biggest missed opportunity in the history of pre-NeXT-merger Apple.
All were bootstrapped on Lisp before. All are FOSS. It's possible.
Sorry if this is a bit disjoint. It's an attempt to recreate a long, more coherent post that was lost. Best I can do.
