I think you misunderstood what I was trying to say: Using the pretty printer together with read macros doesn't seem to be easy at all. I cannot imagine how anyone could be more productive with that than with "lispy" Lisp.
On Monday, September 5, 2011 9:35:36 PM UTC+2, Antsan wrote: > I think you misunderstood what I was trying to say: Using the pretty printer together with read macros doesn't seem to be easy at all. I cannot imagine how anyone could be more productive with that than with "lispy" Lisp.
The point is not to be more productive in the context of answering to WJ :)
Marco Antoniotti wrote: > On Monday, September 5, 2011 9:35:36 PM UTC+2, Antsan wrote: > > I think you misunderstood what I was trying to say: Using the pretty printer together with > > read macros doesn't seem to be easy at all. I cannot imagine how anyone could be more > > productive with that than with "lispy" Lisp.
> The point is not to be more productive in the context of answering to WJ :)
Yes, COBOL-Lispers have learned to be very afraid of posting COBOL-Lisp code, because it can so easily be bested by code in superior languages.
On Tuesday, September 6, 2011 5:05:48 PM UTC+2, WJ wrote: > Marco Antoniotti wrote:
> > On Monday, September 5, 2011 9:35:36 PM UTC+2, Antsan wrote: > > > I think you misunderstood what I was trying to say: Using the pretty printer together with > > > read macros doesn't seem to be easy at all. I cannot imagine how anyone could be more > > > productive with that than with "lispy" Lisp.
> > The point is not to be more productive in the context of answering to WJ :)
> Yes, COBOL-Lispers have learned to be very afraid of posting COBOL-Lisp code, > because it can so easily be bested by code in superior languages.
> I can do it in my sleep.
Excellent. You are admirable. You can put us to sleep in your sleep. Oneiros will be pleased. :)
On Friday, 19 August 2011 04:31:46 UTC-4, Tim Bradshaw wrote: > On 2011-08-18 17:14:24 +0100, Jeff M. said:
> > Personally, I think this is what's impossible for "Lisp" - even Common > > Lisp. That's because a *lot* of what programmers today care about, > > Common Lisp doesn't [portably] provide out-of-the-box. That's because > > the CL standard doesn't address sockets, the web, security, threading, > > and a plethora of other "common" technologies in use today.
> This is something that crops up a lot, and I think is generally because > people would rather complain than get work done.
Exactly.
> Pick an > implementation of CL which has the things you need. Now pretend it is > the only implementation: this is the situation you are currently in for > Perl, say, and somehow it is not a problem for Perl.
On Friday, September 9, 2011 3:34:59 AM UTC+2, toby wrote: > On Friday, 19 August 2011 04:31:46 UTC-4, Tim Bradshaw wrote: > > On 2011-08-18 17:14:24 +0100, Jeff M. said:
> > > Personally, I think this is what's impossible for "Lisp" - even Common > > > Lisp. That's because a *lot* of what programmers today care about, > > > Common Lisp doesn't [portably] provide out-of-the-box. That's because > > > the CL standard doesn't address sockets, the web, security, threading, > > > and a plethora of other "common" technologies in use today.
> > This is something that crops up a lot, and I think is generally because > > people would rather complain than get work done.
> Exactly.
> > Pick an > > implementation of CL which has the things you need. Now pretend it is > > the only implementation: this is the situation you are currently in for > > Perl, say, and somehow it is not a problem for Perl.
> > While I'm at it, I would like to ask one question? Why Lisp, despite > > being so easy in terms of syntax and other language related stuff, is > > so difficult when it comes to its ecosystem, is some sort of elite > > Lispers conspiracy to eliminate lazy and not so clever programmers?
The writer perfectly captured thoughts about the software "industry" that have been weighing on my mind in past months. Thanks for the citation! A very important post.
On Friday, 19 August 2011 12:34:29 UTC-4, Bakul Shah wrote: > On 8/17/11 3:04 PM, Anticomuna wrote: > > All Lisp needs is a killer app. That's all.
> I thought Lisp _had_ a killer app. AI. Didn't it kill Lisp for a while? :-)
That's not a killer app. It's a killer cliché.
Kent Pitman: "...Please don’t assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list."
Toby Thain <t...@telegraphics.com.au> writes:
> On Saturday, 20 August 2011 04:54:34 UTC-4, Pascal J. Bourguignon wrote:
>> Bigos <ruby....@googlemail.com> writes:
>> > While I'm at it, I would like to ask one question? Why Lisp, despite
>> > being so easy in terms of syntax and other language related stuff, is
>> > so difficult when it comes to its ecosystem, is some sort of elite
>> > Lispers conspiracy to eliminate lazy and not so clever programmers?
> The writer perfectly captured thoughts about the software "industry"
> that have been weighing on my mind in past months. Thanks for the
> citation! A very important post.
Hmm. I think the article cited above gives the wrong impression that it
is desirable to work in a company where your colleagues are not
fungible. Imagine being the owner of a software shop. Each employee can
leave the company any time he wants, therefore each employee must be
fungible.
It would be irresponsible to depend the existence of a company (and
therefore the jobs of the other employees) on a single employee. (Thats
what it means having a not fungible employee.)
Eric Wolf <e...@boese-wolf.eu> writes: > Toby Thain <t...@telegraphics.com.au> writes:
>> On Saturday, 20 August 2011 04:54:34 UTC-4, Pascal J. Bourguignon wrote: >>> Bigos <ruby....@googlemail.com> writes:
>>> > While I'm at it, I would like to ask one question? Why Lisp, despite >>> > being so easy in terms of syntax and other language related stuff, is >>> > so difficult when it comes to its ecosystem, is some sort of elite >>> > Lispers conspiracy to eliminate lazy and not so clever programmers?
>> The writer perfectly captured thoughts about the software "industry" >> that have been weighing on my mind in past months. Thanks for the >> citation! A very important post.
> Hmm. I think the article cited above gives the wrong impression that it > is desirable to work in a company where your colleagues are not > fungible. Imagine being the owner of a software shop. Each employee can > leave the company any time he wants, therefore each employee must be > fungible.
> It would be irresponsible to depend the existence of a company (and > therefore the jobs of the other employees) on a single employee. (Thats > what it means having a not fungible employee.)
I don't think the article said otherwise.
It established: F ⇒ ¬ L You are saying: C ⇒ F Therefore: C ⇒ ¬ L
which is what we are observing, and what the article explained:
> It would be irresponsible to depend the existence of a company (and
> therefore the jobs of the other employees) on a single employee. (Thats
> what it means having a not fungible employee.)
>>> On Saturday, 20 August 2011 04:54:34 UTC-4, Pascal J. Bourguignon wrote:
>>>> Bigos <ruby....@googlemail.com> writes:
>>>> > While I'm at it, I would like to ask one question? Why Lisp, despite
>>>> > being so easy in terms of syntax and other language related stuff, is
>>>> > so difficult when it comes to its ecosystem, is some sort of elite
>>>> > Lispers conspiracy to eliminate lazy and not so clever programmers?
>>> The writer perfectly captured thoughts about the software "industry"
>>> that have been weighing on my mind in past months. Thanks for the
>>> citation! A very important post.
>> Hmm. I think the article cited above gives the wrong impression that it
>> is desirable to work in a company where your colleagues are not
>> fungible. Imagine being the owner of a software shop. Each employee can
>> leave the company any time he wants, therefore each employee must be
>> fungible.
>> It would be irresponsible to depend the existence of a company (and
>> therefore the jobs of the other employees) on a single employee. (Thats
>> what it means having a not fungible employee.)
> I don't think the article said otherwise.
> It established: F ⇒ ¬ L
> You are saying: C ⇒ F
> Therefore: C ⇒ ¬ L
> which is what we are observing, > and what the article explained:
> No lisp in companies.
The problem with that assessment is that it fails to explain the
emergence of several new programming languages as viable choices for
programming in large companies.
I mean, honestly, if languages like PHP, Perl, Python, or Ruby can
become acceptable languages for corporate development then why should
Lisp remain a backwater? At one point Lisp was popular enough that
people were creating purpose-built hardware to run Lisp. Lisp had
plenty of corporate buy in then. These days, however, it is getting
beaten out by several Free Software scripting languages.
I am just a Lisp newbie, and I am really enjoying playing around with
Lisp, but I think that Lisp really could use some of the "batteries
included" that programmers have come to expect from languages these
days. Don't get me wrong, Quicklisp goes a long way towards making the
issue go away, but realistically it is only a very good start. It is
hardly competitive with what Common Lisps more popular competitors have
to offer in the way of read-made APIs.
I suppose it goes without saying that I also think that it is
counterproductive to say that Lisp is unpopular primarily because
corporations want replaceable coders. Perl, Python, Ruby, etc. were
able to jump that gap because these languages engendered enough
successful projects that programmers were *forced* to learn these
languages. These days companies can *safely* start projects in Python
secure in the knowledge that they can hire Python hackers (or train
them). Is Lisp really that different?
> I suppose it goes without saying that I also think that it is > counterproductive to say that Lisp is unpopular primarily because > corporations want replaceable coders. Perl, Python, Ruby, etc. were > able to jump that gap because these languages engendered enough > successful projects that programmers were *forced* to learn these > languages.
Perl, Python, Ruby, etc. were able to become mainstream because they are simple enough to master that a large number of competent Perl, Python, Ruby, etc. programmers can eventually develop.
Lisp is significantly more difficult to master than any of these languages because to master Lisp is to master metaprogramming - i.e., macro writing. Most programmers will never do this, so there will never be an army of replaceable programmers who have mastered lisp, any more than there will be an army of coders all of whom have written their own Python compiler.
Now, if you want a vast, replaceable horde of people who have mastered all of lisp *except* metaprogramming, fine, you can have it. But what's the point? Now we're just talking about another algol family language, but this one has a fully parenthesized syntax. What's the win?
The whole advantage of that parenthesized syntax is that it enables easy metaprogramming in the *same language* as the base language. This is the win of lisp, but to have it, you have to master metaprogramming. Of necessity, the group of people who have mastered both programming and metaprogramming is going to be smaller than the group of people who have just mastered programming in a fixed language such as Perl, Python or Ruby.
This difference in the number of available programmers will always guarantee that most large organizations will not choose such a language, any more than most large organizations would choose a work flow that required all of their line programmers to write their own compilers.
On Mon, Sep 12 2011, Raffael Cavallaro wrote:
> On 2011-09-12 02:41:03 +0000, Jason Earl said:
>> I suppose it goes without saying that I also think that it is
>> counterproductive to say that Lisp is unpopular primarily because
>> corporations want replaceable coders. Perl, Python, Ruby, etc. were
>> able to jump that gap because these languages engendered enough
>> successful projects that programmers were *forced* to learn these
>> languages.
> Perl, Python, Ruby, etc. were able to become mainstream because they
> are simple enough to master that a large number of competent Perl,
> Python, Ruby, etc. programmers can eventually develop.
> Lisp is significantly more difficult to master than any of these
> languages because to master Lisp is to master metaprogramming - i.e.,
> macro writing. Most programmers will never do this, so there will
> never be an army of replaceable programmers who have mastered lisp,
> any more than there will be an army of coders all of whom have written
> their own Python compiler.
Just because you *can* write fancy macros in Lisp does not mean that you
*must* write them. Most programmers don't even learn all of the tricks
that Perl or Python offer either. However, the fact that these
languages have become popular means that the community as a whole ends
up with far more resources at its disposal.
If the only think that Common Lisp is good for is re-implementing Common
Lisp then it shouldn't surprise anyone that it is not particularly
popular. I don't think that's the case though, and I would guess that
you don't believe that either.
> Now, if you want a vast, replaceable horde of people who have mastered
> all of lisp *except* metaprogramming, fine, you can have it. But
> what's the point? Now we're just talking about another algol family
> language, but this one has a fully parenthesized syntax. What's the
> win?
As someone that hasn't yet mastered metaprogramming I can't help but see
this as a huge win. Right now, if I aspire to that level of wizardry I
have to do so on my own time, probably hacking on a project that would
actually be easier to do in some other language.
Even without meta-programming Common Lisp has all of the requirements
necessary to compete well with languages like Python or Perl. If people
can get used to Python's relevant whitespace then Lisp syntax is hardly
problematic. Feature wise Lisp has Python beat, and there are
implementations of Lisp that are *much* faster as well. I have been
very impressed, for example, with sbcl.
Even if I never become a wizard Common Lisp would seem to be a win, if,
of course, it could actually match Python in usable libraries, and if
some of the deployment wrinkles could be sorted out.
> The whole advantage of that parenthesized syntax is that it enables
> easy metaprogramming in the *same language* as the base language. This
> is the win of lisp, but to have it, you have to master
> metaprogramming. Of necessity, the group of people who have mastered
> both programming and metaprogramming is going to be smaller than the
> group of people who have just mastered programming in a fixed language
> such as Perl, Python or Ruby.
This argument makes it sounds like metaprogramming is actually a
misfeature, and if you *had* to understand metaprogramming to be able to
use Lisp then I would agree, it would be a misfeature. However, that's
not the case.
> This difference in the number of available programmers will always
> guarantee that most large organizations will not choose such a
> language, any more than most large organizations would choose a work
> flow that required all of their line programmers to write their own
> compilers.
Yes, and I remember very well when I was told that large organizations
would never hire Python programmers, and yet that is not really the case
any more. Sure, it is still not as popular a choice as Java, but there
is lots and lots of useful software getting written in Python.
Somehow that does not seem to be the case for Lisp.
> Just because you *can* write fancy macros in Lisp does not mean that you
> *must* write them.
Your argument is rather like saying that a Wusthof chef's knife could compete in popularity with the Slap Chop if it were marketed as a tool whose principal function was making egg salad and unevenly chopped onions. The whole point of the chef's knife is that it is a much more versatile tool - e.g., you can't do a julienne or a chiffonade with a Slap Chop - but the superior tool requires a more highly skilled user to take advantage of that versatility.
If you don't write macros you lose the advantage of lisp. What differentiates lisp from other languages is the ability to do metaprogramming using the base language. If you take that away, all you're left with is yet another algol dialect, but this one just happens to have a fully parenthesized syntax.
> Even without meta-programming Common Lisp has all of the requirements
> necessary to compete well with languages like Python or Perl.
The whole point of Common Lisp is not that it can "compete" with Python or Perl, but that Common Lisp is *better* than Python or Perl. What makes it better is metaprogramming. If you don't use this feature, you might as well use Python or Perl or any other SLDJ (Scripting Language Du Jour).
On Mon, Sep 12 2011, Raffael Cavallaro wrote:
> On 2011-09-12 21:55:15 +0000, Jason Earl said:
>> Just because you *can* write fancy macros in Lisp does not mean that you
>> *must* write them.
> Your argument is rather like saying that a Wusthof chef's knife could
> compete in popularity with the Slap Chop if it were marketed as a tool
> whose principal function was making egg salad and unevenly chopped
> onions. The whole point of the chef's knife is that it is a much more
> versatile tool - e.g., you can't do a julienne or a chiffonade with a
> Slap Chop - but the superior tool requires a more highly skilled user
> to take advantage of that versatility.
If that were actually the case then I suppose that Lisp would deserve to
lose. If it actually *required* more skill, then that would be one
thing. However, that is not the case. I know, I have been able to
write the same sort of software in Common Lisp that I previously wrote
in Python. In a few cases I have even written sample programs in Common
Lisp and Python just to compare. I am convinced that (in those cases
where the libraries available in Common Lisp) Common Lisp is better than
Python.
And that's without any metaprogramming at all.
> If you don't write macros you lose the advantage of lisp. What
> differentiates lisp from other languages is the ability to do
> metaprogramming using the base language. If you take that away, all
> you're left with is yet another algol dialect, but this one just
> happens to have a fully parenthesized syntax.
I realize that macros is the secret sauce that makes Lisp better. I
read through PCL and it convinced me that I really needed to learn how
to use macros. Even if it is hard.
What surprised me was that even without macros Common Lisp is no
slouch. I think that Lispers do Lisp a disservice when they market it
as "for wizards only."
One thing is certain, when it comes to writing useful software the
non-wizards seem to be absolutely drowning out the wizards.
>> Even without meta-programming Common Lisp has all of the requirements
>> necessary to compete well with languages like Python or Perl.
> The whole point of Common Lisp is not that it can "compete" with
> Python or Perl, but that Common Lisp is *better* than Python or
> Perl. What makes it better is metaprogramming. If you don't use this
> feature, you might as well use Python or Perl or any other SLDJ
> (Scripting Language Du Jour).
And that's the problem really. I am convinced that Lisp really is
better in theory. But in the real world having a Python library that
already does most of the work trumps whatever Lisp might bring to the
table. I am just curious as to why Python can go from being obscure to
being popular, while Lisp seems to move in the opposite direction,
despite its many advantages.
Your assertion that it is because Lisp requires more intelligent hackers
simply doesn't hold water. It doesn't require more intelligent hackers,
it just encourages them, and allows them to reach a higher potential.
My guess is the real reason is that most people already see Lisp as a
failed or dead language. They assume that no one is using Lisp today
for the same reason that no one is using Algol today. It has been
supplanted by newer and fancier languages.
On Tuesday, September 13, 2011 4:08:04 AM UTC+2, Raffael Cavallaro wrote:
> On 2011-09-12 21:55:15 +0000, Jason Earl said:
> > Just because you *can* write fancy macros in Lisp does not mean that you
> > *must* write them.
> Your argument is rather like saying that a Wusthof chef's knife could > compete in popularity with the Slap Chop if it were marketed as a tool > whose principal function was making egg salad and unevenly chopped > onions. The whole point of the chef's knife is that it is a much more > versatile tool - e.g., you can't do a julienne or a chiffonade with a > Slap Chop - but the superior tool requires a more highly skilled user > to take advantage of that versatility.
> If you don't write macros you lose the advantage of lisp. What > differentiates lisp from other languages is the ability to do > metaprogramming using the base language. If you take that away, all > you're left with is yet another algol dialect, but this one just > happens to have a fully parenthesized syntax.
> > Even without meta-programming Common Lisp has all of the requirements
> > necessary to compete well with languages like Python or Perl.
> The whole point of Common Lisp is not that it can "compete" with Python > or Perl, but that Common Lisp is *better* than Python or Perl. What > makes it better is metaprogramming. If you don't use this feature, you > might as well use Python or Perl or any other SLDJ (Scripting Language > Du Jour).
On 2011-09-13 03:08:04 +0100, Raffael Cavallaro said:
> If you don't write macros you lose the advantage of lisp. What > differentiates lisp from other languages is the ability to do > metaprogramming using the base language. If you take that away, all > you're left with is yet another algol dialect, but this one just > happens to have a fully parenthesized syntax.
Well said. And in fact this is exactly how I find myself working: if I want a language which has a mass of libraries I use (generally, because of its cultural affinity with CL, but substitute your own choice here) Perl, but if I want to do some hairy macro stuff I obviously use Lisp.
Lisp just doesn't have any advantage over Perl for the things Perl is good at *and it still would not have if it had all the libraries Perl has*.
I'd add another strength: Lisp is really good at some kinds of complicated data structure stuff, particularly when you are not quite sure what the data structures need to be in advance.
Because I'm a pragmatist rather than an idealogue, what I often do is: write something in Perl (again, substitute whatever here) which does the work of acquiring data, and then generate something CL can easily read from the Perl. Then I do the real work in CL.
And actually, if I was writing a big system, that's what I'd do as well: pick a "front-end" language with good library support, and then write an interface between it and whatever Lisp I was using. That works really well in my experience.
On 2011-09-13 03:08:04 +0100, Raffael Cavallaro said:
> The whole point of Common Lisp is not that it can "compete" with Python > or Perl, but that Common Lisp is *better* than Python or Perl. What > makes it better is metaprogramming. If you don't use this feature, you > might as well use Python or Perl or any other SLDJ (Scripting Language > Du Jour).
I don't think it's better, because I don't think the space of programming languages maps onto the reals that way. In particular: it's (clearly) better at metaprogramming, and (for me, anyway) it's better at complicated data structures. But I don't think it's better at various sorts of line-based file grovelling, because Perl is pretty much optimal for that (and, like it or not, that's a useful thing to be good at).
This is not an anti-Lisp post (I think most of the people who would once have leapt on it as such have gone away now, which is a mixed blessing).
> If that were actually the case then I suppose that Lisp would deserve to
> lose. If it actually *required* more skill,
It *does* require more skill to use to its full advantage. Lisp is not just a better Blub <http://www.paulgraham.com/avg.html> It is *different* than Blub because it is a superset of Blub. Being a superset makes it more difficult to master. If you use lisp like you used Blub, you're missing the point.
> then that would be one
> thing. However, that is not the case. I know, I have been able to
> write the same sort of software in Common Lisp that I previously wrote
> in Python.
Then there was no reason to switch - if you're only using Common Lisp in the same way you've used Python, then you're not using Common Lisp to its full advantage. You might as well still be using Python, or Perl, or Ruby…
> But in the real world having a Python library that
> already does most of the work trumps whatever Lisp might bring to the
> table.
Only if your "real world" consists of problems that have been solved dozens of times before by other programmers. Lisp shows its advantages:
- when solving a problem that hasn't been solved before. Lisp shines in exploratory programming, not same-old-same-old programming. By definition, there can be no canned library for an as yet unsolved problem. If you need libraries as components of your exploratory programming, lisp has plenty and to spare, trivially loaded into every implementation I'm aware of - see quicklisp.
- when building a dsl directly from the data using macros.
- when building bridges to other languages with different syntax using reader macros
I'm sure others will think of other ways that lisp's unique metaprogramming advantages come into play.
Don't cheat yourself of the full lisp experience by simply using it as a parenthesized Blub - learn to use its metaprogramming facilities fluently.
>> [...] but the superior tool requires a more highly skilled user
>> to take advantage of that versatility.
> If that were actually the case then I suppose that Lisp would deserve to
> lose. [...]
I have a road bike. It has a high saddle, very thin tyres pumped up very hard so you get a lot of vibration from the road, very closely-spaced gearing. The pedals can hit the front wheel. It couldn't have mudguards if I wanted them, it can't have a rack.
Probably if someone who'd not ridden a proper road bike before tried to ride it they'd fall off. It's an insanely bad commuter bike. But I know which of my bikes I'd want to take up Applecross pass.
On Tue, Sep 13 2011, Raffael Cavallaro wrote:
> On 2011-09-13 04:45:13 +0000, Jason Earl said:
>> If that were actually the case then I suppose that Lisp would deserve to
>> lose. If it actually *required* more skill,
> It *does* require more skill to use to its full advantage.
Yes, it does require more skill to use to its *full advantage*. My
point is that you don't have to use Lisp to its full advantage to see
that it has advantages.
> Lisp is not just a better Blub <http://www.paulgraham.com/avg.html> It
> is *different* than Blub because it is a superset of Blub. Being a
> superset makes it more difficult to master. If you use lisp like you
> used Blub, you're missing the point.
In that essay Paul Graham says precisely what I have been trying to say
all along:
So if Lisp makes you a better programmer, like he [ESR] says, why
wouldn't you want to use it? If a painter were offered a brush that
would make him a better painter, it seems to me that he would want
to use it in all his paintings, wouldn't he? I'm not trying to make
fun of Eric Raymond here. On the whole, his advice is good. What he
says about Lisp is pretty much the conventional wisdom. But there is
a contradiction in the conventional wisdom: Lisp will make you a
better programmer, and yet you won't use it.
>> then that would be one thing. However, that is not the case. I
>> know, I have been able to write the same sort of software in Common
>> Lisp that I previously wrote in Python.
> Then there was no reason to switch - if you're only using Common Lisp
> in the same way you've used Python, then you're not using Common Lisp
> to its full advantage. You might as well still be using Python, or
> Perl, or Ruby…
Of course there was a reason to switch. If I want to learn to use
Lisp. I have to *gasp* use Lisp.
For example, I imagine that your first Lisp programs were crude. They
could just as easily been written in some other language. However, as
you have so eloquently pointed out, Lisp is better than other languages.
Choosing another language is a premature optimization, as the choice
will constrain me down the road. From my experience that is especially
true because Lisp is not really that much harder to learn to do basic
stuff in.
At least I did not think it was that much harder.
>> But in the real world having a Python library that already does most
>> of the work trumps whatever Lisp might bring to the table.
> Only if your "real world" consists of problems that have been solved
> dozens of times before by other programmers. Lisp shows its
> advantages:
Unless you are programming in machine language toggled in with switches
every program builds on software that solves problems that have been
solved before. Lisp might be better at solving the *new* parts of the
problem, but there is little question that it sometimes falls flat when
solving some of the *old* problems.
In short, while syntax and language power matter. So do available
libraries.
> - when solving a problem that hasn't been solved before. Lisp shines
> in exploratory programming, not same-old-same-old programming. By
> definition, there can be no canned library for an as yet unsolved
> problem. If you need libraries as components of your exploratory
> programming, lisp has plenty and to spare, trivially loaded into every
> implementation I'm aware of - see quicklisp.
I am a newbie to Lisp, but you are mostly preaching to the choir here.
I will even go so far as to say that Quicklisp is clearly a step in the
right direction. I probably would be even happier with Quicklisp and
Lisp in general if I had started by choosing sbcl as my Lisp
implementation.
> - when building a dsl directly from the data using macros.
> - when building bridges to other languages with different syntax using
> reader macros
> I'm sure others will think of other ways that lisp's unique
> metaprogramming advantages come into play.
> Don't cheat yourself of the full lisp experience by simply using it as
> a parenthesized Blub - learn to use its metaprogramming facilities
> fluently.
I fully plan on getting to that point. Which is why I want more excuses
to program in Lisp.
Personally, I think that eventually Lisp is going to see a serious
resurgence, but it isn't going to happen until Lisp is competitive for
simple programming languages for doing simple programs. The problems
that need to be overcome are problems of available libraries, and ease
of deployment. I haven't used it, but it appears that Racket is trying
to follow this particular path.
>> Just because you *can* write fancy macros in Lisp does not mean that you
>> *must* write them.
> Your argument is rather like saying that a Wusthof chef's knife could
> compete in popularity with the Slap Chop if it were marketed as a tool
> whose principal function was making egg salad and unevenly chopped
> onions. The whole point of the chef's knife is that it is a much more
> versatile tool - e.g., you can't do a julienne or a chiffonade with a
> Slap Chop - but the superior tool requires a more highly skilled user
> to take advantage of that versatility.
> If you don't write macros you lose the advantage of lisp.
That's not quite true; someone else could write macros for you, and
you'd have all the same advantages. Granted, macro-writing is a valuable
skill to have, but it's more important that macros can be written than
that they are written by a particular programmer.
> Yes, it does require more skill to use to its *full advantage*. My > point is that you don't have to use Lisp to its full advantage to see > that it has advantages.
OK, so let's be specific: if you're not doing metaprogramming of some kind (really, macros), what *are* lisp's advantages?
