I can not believe for once that this guy obtained hacking nirvana through Arc. Not once! Why? because the Arc documentation is so meager as to be non-existent. You will need serious feet-wetting with more established Lisp dialects before you can "get there" with Arc.
All the epiphanies he lists are easily experienced with most modern Lisp dialects; either he "got it" before and just needed to extend the credit to Arc, for some reason .. or he isn't there yet, at least not to its full potential.
It had to be said, as much as I hate to be rude and blunt like this :-|
I have a lot of experience with Arc, Scheme, and Common Lisp, and I find Arc significantly more pleasant to program in. When I have to shift into Scheme (some parts of Arc are written in Scheme), it feels like there is a lot of extra drag.
It was noticing this difference that made me decide Arc was ready to release. If it (a) felt significantly better to me, who (b) am experienced with existing Lisp dialects, and (c) writing a type of application (HN) that's not wildly specialized, then it had the "quantum of utility" I usually use as the test for releasing a version 1.
Any chance of releasing a book or spec alongside Arc at some point? Or are you encouraging people to just play around with it for now? I'm just wondering whether the idea here is to encourage exploration through scarcity, or that there's insufficient resources to produce the documentation, or if it's just too early on at this stage.
Paul, you're fit to prefer Arc over the rest because: 1) you're an experienced Lisper, and 2) it's your own creation, you know it inside and out and the language spec, manual, tutorial and research papers are somewhere between your ears (the most convenient type of bookshelf ;-)
However, it's IMO, unacceptable for a fairly new Lisp programmer to cast aside 50 years of Lisp research, development and deployment while brushing aside the industry's backbone languages, and herald Arc as the best thing ever when it isn't even finished.
I can accept personal choice and opinion, if kept to one's self and made in private. Even if someone sings Arc, or Clojure or Common Lisp or Scheme, praises, I am fine with it. But to say "Languages X, Y, Z suck because they don't allow me to write succinct programs", well, you're just trolling for X, Y and Z programmers to come out and straighten you out. The sort of macrology he is after (code-compacting type, not language extension) is pretty basic and could be done with the C pre-processor and M4. You can even write compact assembly programs with GASP, HLA, and NASM macros; it's not rocket science.
I reserve my judgment for Arc until it's done. There is no manual yet to hold the compiler accountable, and to save me from guess-work. However, what I can't ignore is blind fanboyism; if everybody here sang Arc praises, when it is just arc-tutorial.txt and arc.arc, and there were no "dissenting" honest voices, well, the place just wouldn't be the same.
I think you're being unnecessarily argumentative in this discussion. The author likes Arc, feel is makes him more productive, and he wanted to share that with the community.
He did not say other languages suck. What he said was he prefers Arc over those languages, and explained why.
The guy expressed an opinion... this isn't a Draft Proposal For The Official Unanimous Worldwide Opinion On The Best Programming Language Ever And For All Time.
I can summarize the whole thing as:
"I really like working with arc, and it makes me happy enough to blog about it."
So yeah, while I didn't find it particularly worth upvoting, I'm not sure why you are trying to convince this guy he is somehow _wrong_ about being happy, and telling him he shouldn't dare write about it. You can no more do that than convince someone who claims their favorite color is red that it is in fact blue.
I will be the first to admit that this has been an unnecessary verbal body-slam on my part and I do owe the poster an apology, but:
> The guy expressed an opinion...
In technical circles even opinions have to be defensible. You can't just accept "X sucks and Y rocks" as an opinion and let it pass. The whole place will become abuzz with irrational thought, and overrun with "we are all right" group-think liberal-arts type BS.
> You can't just accept "X sucks and Y rocks" as an opinion and let it pass.
Why not? The only reason that 'the whole place will become abuzz with irrational thought, and overrun with "we are all right" group-think liberal-arts type BS' is because people can't just accept things like this as somebody's opinion... they have to create a language war out of simple blog post about liking something.
(To everyone else, I'll quit now I promise, obviously I'm not helping the matter!)
This is why I stopped reading C.L.L. - The notion that it's inconceivable to genuinely like any other language than Common Lisp. It's a bizarre idea, and one that carries much more fervor than I think CL has earned. If this were still 1990, then I suppose it would have a stronger leg to stand on.
Don't get me wrong, I really like Common Lisp (well, all I've ever played with is SBCL, so maybe I would like another variant more or less). I just don't see why it's impossible for someone to actually like Arc, or Clojure, or PLT Scheme or any other little-L lisp instead of Common Lisp.
So it's a personal-preference choice made after sufficient deliberation and experience in all the options on the table, I hope.
Ok. I will accept that.
Here is my take on your personal essay, it's also a matter of personal opinion made after sufficient technical evaluation of the matter: I think you need to be a little more critical of your own reasoning, specially when writing for programmers. The spirit of your essay has been largely positive, IMO, but go easy on the snide remarks and the dismissive attitude of other technologies you have very little experience in (yeah, it shows.) Otherwise a much less sympathetic reader than I, and a far more competent one, will come aboard and tear your argument to pieces.
A better way to frame your enthusiastic writing would be "I can do X in Arc, I really wish ${LISP_DIALECT} would let me do the same". This is both curious and also accepting of one's own self-limitations. Someone will come aboard and show you what you have been missing, and you might as well get pointers to the literature that further your understanding of Arc or whatever other technology.
Can you give me an example of a snide remark that could be rewritten?
(I appreciate your suggestion to say that I wish another Lisp dialect was more like Arc, but I'm not sure how I'd choose one since I don't really have a favorite aside from Arc).
> Can you give me an example of a snide remark that could be rewritten?
Here is a quick list of what I think needs further deliberation and scrutiny on your part.
> I’ve long liked Lisp, but hadn’t been programming in Lisp for a long time because I hadn’t found any features in Lisp compelling enough to overcome the advantage other languages had in having large libraries available and such like.
[You came to the wrong Lisp then, as Arc has no libraries compared to all the mainstream lisp dialects]
> I found the [Scheme] rationale of hygienic macros -- avoiding all possibility of conflicting identifiers in macro expansions -- to be compelling. After all, who would want to write a macro that breaks just because the user happens to be using a variable of the same name as one used in the macro?
[Actually, scheme's hygienic macros shift the burden of capture-avoidance to the compiler. It's CL that has to use gensym.]
>I now understand that all these language features that people work hard to create solve some problem, and it can be a useful and important problem to solve, and yet it can be a problem I don’t care about, a problem I don’t have. That doesn’t necessarily make it a bad language feature, but it can make it one that I don’t want to pay the cost of using.
[This is fraught with reasoning errors. If you want a language that only has the features you want, create your own DSL. And even after that, you might apply that a la carte reasoning to the runtime and question why you might need a certain garbage collector, if any at all, or why you might need your runtime to have bindings for the OS system calls when you don't use them. Slippery slope. Richness is usually a good thing, not bad.]
>Yet in Java, it’s hard to get anything shorter than ten or twenty lines of code. See some code duplication, and by the time you’ve written the classes and interfaces and methods you need to write to remove the duplication, the code is just as long as it was before.
[A personal opinion that will send java programmers in uproar. not that java doesn't suck ;-]
>Languages written by hackers for hackers like Perl and Ruby and Python are lots better (and, I find for myself, a lot more productive for me for the kinds of projects I work on), and I can write shorter programs in them, yet they don’t help me go further
[and now the Perl, Python and Ruby programmers feel trolled and will jump at your neck. You requirements are of the DWIM kind.]
>they don’t help me make my program shorter.
[Yes, and an Aston Martin can't tow a boat. Right tool for the job]
>Now I see some pattern in my code, if I’m doing more typing than I want to be doing, BAM I write a macro and use it. Just like that
[and the Lisp programmer collective is surprised by your surprise.]
[You came to the wrong Lisp then, as Arc has no libraries compared to all the mainstream lisp dialects]
I'm not saying that Arc has better libraries than other Lisps, I'm saying that for me the advantages of Arc outweigh for me the disadvantages of not having the libraries that other languages do.
[Actually, scheme's hygienic macros shift the burden of capture-avoidance to the compiler. It's CL that has to use gensym.]
Yes, what I was saying was that when I learned about hygienic macros I thought they were a good idea for that reason.
Richness is usually a good thing
If I can choose to use a feature or not (as it typical with libraries: I can choose to use a library or not) then the cost to me of a feature that I don't want is zero; if I have to use a feature or it is harder to avoid then it matters to me whether the cost to me of that feature outweighs the benefit to me.
A personal opinion
Not at all. While it wasn't the purpose of my thank-you to do such a demonstration, it's easy to compare the relative length of code needed to do a particular implementation in different languages.
feel trolled
Yes, perhaps it is common for people who like X to be mad if I say that I prefer Y.
DWIM kind
I'm not following you.
and the Lisp programmer collective is surprised by your surprise
Perhaps they have had better luck than I have at writing hygienic macros.
His intent has been "largely positive", but what do you expect people to say after his "Perl, Python, Ruby, Java, Scheme and Common Lisp suck because they didn't allow me to write compact code" remarks?
Here is what will happen: Perl and Ruby programmers will ask you to show code and they will rewrite it in one-liners. Java and Python programmers will stuff code into packages/modules and write a tiny 5-line "client" for it. And Scheme and Common Lisp programmers will take absolute pleasure in skinning your argument about macrology and hygiene, the Common Lispers keeping a bucket of salt nearby for the rubbing.
"Yet in Java, it’s hard to get anything shorter than ten or twenty lines of code."
I am a Java programmer, I find much to like about Java, and I agree totally with this statement. I tried writing some functionality in Clojure, then re-writing in Java. It was a factor of 2 or 3 increase in lines of code.
I see CatDancer's touched a bit of a raw nerve. You've been compelled to respond with about a dozen (didn't count them) posts all quite attacking of both CatDancer and Arc.
What the hell is your problem with a) someone creating their own Lisp implementation, and b) someone else enjoying using it?
you wouldn't understand it, and it's not a personal problem of mine: just consider my behavior in this discussion a throw-back to a long-dead form of communication from when programmers where held accountable to their words :-)
I should have been nice, we're all equally-right in some way. hugs.
He does say that he has long liked Lisp, and that he generally liked Scheme, so he already had his feet wet. And although the documentation is, well, scarce, he did read through the source code file arc.arc.
Read what he wrote again and you will be surprised by the logic:
"I’ve long liked Lisp, but hadn’t been programming in Lisp for a long time because I hadn’t found any features in Lisp compelling enough to overcome the advantage other languages had in having large libraries available and such like."
I mean, come ON. If Lisp wasn't compelling enough because of the perceived lack of libraries, then Arc is the last way to come back to Lisp as it has NIL.
It's completely acceptable to have a preferred Lisp, but it's unacceptable to do so for irrational reasons ;-) Every time you need a new library/feature in Arc you're most likely to call out to the MzScheme runtime and FFI. It's highly hypocritical of you to dismiss a language for lack of libraries, then jump on another language it hosts.
If Lisp wasn't compelling enough because of the perceived lack of libraries, then Arc is the last way to come back to Lisp as it has NIL.
I think you've misunderstood this sentence, which explains why you don't understand the logic.
He is dismissing Lisp because [library pain] is not alleviated by [compelling language features]. For him, in Arc, [compelling language features] do alleviate [library pain], so he is happy to use Arc. This logic is fine even if the [library pain] in Arc is actually worse than the [library pain] he experienced in Lisp, because [compelling language features] differs too.
So, no hypocrisy. You could still argue that he should have experienced less library pain in Lisp than he did experience, or that Lisp might have compelling features that he overlooked, or even that library pain cannot in principle be alleviated by language features, though I won't comment there.
For me it's a cost/benefit analysis. Programming in MzScheme or Arc has a cost to me in that the libraries I typically use for my projects are mostly available in other languages, so they are harder to get to. I may decide to program in a language despite such a cost if it has other benefits for me that I find outweigh the cost. While I liked MzScheme, I didn't find its benefit to me great enough to outweigh the inconvenience of the library issue. The scale tipped in the other direction for me with Arc, where I'm happy enough with the benefits I find in Arc that they outweigh the other disadvantages for me.
Your article doesn't list any of the library features that tipped the scale in favor of Arc. It's unfair to the MzScheme developers and users to dismiss their platform without telling them what's lacking. Please revise the article and flesh it further, if you have the time, because as it stands, it doesn't stand well under scrutiny.
Public technical rationales aught to be a little more than "just cuz" and personal preference. If you wanted a discussion that is ..
I'm sorry but this seems an aggressive comment to me. CatDancer did mention the preference of simple macros over MzScheme's more complicated hygienic macros. Beyond that, Arc is different from Scheme and everyone knows it. The differences are documented and they are the reason why Arc is not Scheme. You do not have to challenge the piece just because you don't particularly like the changes Arc made in comparison to Scheme.
Your article doesn't list any of the library features that tipped the scale in favor of Arc.
The features of Arc are well described in the Arc tutorial, http://ycombinator.com/arc/tut.txt would you recommend that I include a link to that?
it doesn't stand well under scrutiny ... public technical rationales aught to be a little more than ...
Well, I had posted it to the Arc forum, where people are already familiar with Arc. I expect that your criticism is valid if it had been intended to be a technical article.
I don't know about 'hacking nirvana', but I found the Arc tutorial coupled with help from an appropriate newsgroup to grok macros (#arc? I don't remember now) was enough to write a ray tracer (LightMakesRight in the anarki distribution). Arc was my first exposure to a lisp dialect.
Comments
and now for the anti-pandering anti-pattern ;-)
I can not believe for once that this guy obtained hacking nirvana through Arc. Not once! Why? because the Arc documentation is so meager as to be non-existent. You will need serious feet-wetting with more established Lisp dialects before you can "get there" with Arc.
All the epiphanies he lists are easily experienced with most modern Lisp dialects; either he "got it" before and just needed to extend the credit to Arc, for some reason .. or he isn't there yet, at least not to its full potential.
It had to be said, as much as I hate to be rude and blunt like this :-|
I have a lot of experience with Arc, Scheme, and Common Lisp, and I find Arc significantly more pleasant to program in. When I have to shift into Scheme (some parts of Arc are written in Scheme), it feels like there is a lot of extra drag.
It was noticing this difference that made me decide Arc was ready to release. If it (a) felt significantly better to me, who (b) am experienced with existing Lisp dialects, and (c) writing a type of application (HN) that's not wildly specialized, then it had the "quantum of utility" I usually use as the test for releasing a version 1.
Hi Paul,
Any chance of releasing a book or spec alongside Arc at some point? Or are you encouraging people to just play around with it for now? I'm just wondering whether the idea here is to encourage exploration through scarcity, or that there's insufficient resources to produce the documentation, or if it's just too early on at this stage.
That's one of the things I'm going to do next.
Paul, you're fit to prefer Arc over the rest because: 1) you're an experienced Lisper, and 2) it's your own creation, you know it inside and out and the language spec, manual, tutorial and research papers are somewhere between your ears (the most convenient type of bookshelf ;-)
However, it's IMO, unacceptable for a fairly new Lisp programmer to cast aside 50 years of Lisp research, development and deployment while brushing aside the industry's backbone languages, and herald Arc as the best thing ever when it isn't even finished.
I can accept personal choice and opinion, if kept to one's self and made in private. Even if someone sings Arc, or Clojure or Common Lisp or Scheme, praises, I am fine with it. But to say "Languages X, Y, Z suck because they don't allow me to write succinct programs", well, you're just trolling for X, Y and Z programmers to come out and straighten you out. The sort of macrology he is after (code-compacting type, not language extension) is pretty basic and could be done with the C pre-processor and M4. You can even write compact assembly programs with GASP, HLA, and NASM macros; it's not rocket science.
I reserve my judgment for Arc until it's done. There is no manual yet to hold the compiler accountable, and to save me from guess-work. However, what I can't ignore is blind fanboyism; if everybody here sang Arc praises, when it is just arc-tutorial.txt and arc.arc, and there were no "dissenting" honest voices, well, the place just wouldn't be the same.
I think you're being unnecessarily argumentative in this discussion. The author likes Arc, feel is makes him more productive, and he wanted to share that with the community.
He did not say other languages suck. What he said was he prefers Arc over those languages, and explained why.
I realized that pretty much by now. I had a WTF moment earlier and wished I had spent those few hours I spent on this thread doing something else.
Lesson learned. Modded you up for the truth. Thank you :-)
The guy expressed an opinion... this isn't a Draft Proposal For The Official Unanimous Worldwide Opinion On The Best Programming Language Ever And For All Time.
I can summarize the whole thing as:
"I really like working with arc, and it makes me happy enough to blog about it."
So yeah, while I didn't find it particularly worth upvoting, I'm not sure why you are trying to convince this guy he is somehow _wrong_ about being happy, and telling him he shouldn't dare write about it. You can no more do that than convince someone who claims their favorite color is red that it is in fact blue.
I will be the first to admit that this has been an unnecessary verbal body-slam on my part and I do owe the poster an apology, but:
> The guy expressed an opinion...
In technical circles even opinions have to be defensible. You can't just accept "X sucks and Y rocks" as an opinion and let it pass. The whole place will become abuzz with irrational thought, and overrun with "we are all right" group-think liberal-arts type BS.
> You can't just accept "X sucks and Y rocks" as an opinion and let it pass.
Why not? The only reason that 'the whole place will become abuzz with irrational thought, and overrun with "we are all right" group-think liberal-arts type BS' is because people can't just accept things like this as somebody's opinion... they have to create a language war out of simple blog post about liking something.
(To everyone else, I'll quit now I promise, obviously I'm not helping the matter!)
This is why I stopped reading C.L.L. - The notion that it's inconceivable to genuinely like any other language than Common Lisp. It's a bizarre idea, and one that carries much more fervor than I think CL has earned. If this were still 1990, then I suppose it would have a stronger leg to stand on.
I haven't mentioned Common Lisp by name, and if it makes you feel any better, every CLer has a pet-Lisp trapped inside him, including yours truly ;-)
Don't get me wrong, I really like Common Lisp (well, all I've ever played with is SBCL, so maybe I would like another variant more or less). I just don't see why it's impossible for someone to actually like Arc, or Clojure, or PLT Scheme or any other little-L lisp instead of Common Lisp.
Those are all "modern lisp dialects", none of my tone or phrasing suggested CL-centrism. Please re-read.
I hope any pre-conceived notion of Lisper hostility isn't getting in the way you read my prose above.
Demand for rigor in thought shouldn't be mistaken for hostility.
I have achieved hacking nirvana through Arc because I like Arc more than I like Scheme or Common Lisp.
So it's a personal-preference choice made after sufficient deliberation and experience in all the options on the table, I hope.
Ok. I will accept that.
Here is my take on your personal essay, it's also a matter of personal opinion made after sufficient technical evaluation of the matter: I think you need to be a little more critical of your own reasoning, specially when writing for programmers. The spirit of your essay has been largely positive, IMO, but go easy on the snide remarks and the dismissive attitude of other technologies you have very little experience in (yeah, it shows.) Otherwise a much less sympathetic reader than I, and a far more competent one, will come aboard and tear your argument to pieces.
A better way to frame your enthusiastic writing would be "I can do X in Arc, I really wish ${LISP_DIALECT} would let me do the same". This is both curious and also accepting of one's own self-limitations. Someone will come aboard and show you what you have been missing, and you might as well get pointers to the literature that further your understanding of Arc or whatever other technology.
Regards.
Can you give me an example of a snide remark that could be rewritten?
(I appreciate your suggestion to say that I wish another Lisp dialect was more like Arc, but I'm not sure how I'd choose one since I don't really have a favorite aside from Arc).
> Can you give me an example of a snide remark that could be rewritten?
Here is a quick list of what I think needs further deliberation and scrutiny on your part.
> I’ve long liked Lisp, but hadn’t been programming in Lisp for a long time because I hadn’t found any features in Lisp compelling enough to overcome the advantage other languages had in having large libraries available and such like.
[You came to the wrong Lisp then, as Arc has no libraries compared to all the mainstream lisp dialects]
> I found the [Scheme] rationale of hygienic macros -- avoiding all possibility of conflicting identifiers in macro expansions -- to be compelling. After all, who would want to write a macro that breaks just because the user happens to be using a variable of the same name as one used in the macro?
[Actually, scheme's hygienic macros shift the burden of capture-avoidance to the compiler. It's CL that has to use gensym.]
>I now understand that all these language features that people work hard to create solve some problem, and it can be a useful and important problem to solve, and yet it can be a problem I don’t care about, a problem I don’t have. That doesn’t necessarily make it a bad language feature, but it can make it one that I don’t want to pay the cost of using.
[This is fraught with reasoning errors. If you want a language that only has the features you want, create your own DSL. And even after that, you might apply that a la carte reasoning to the runtime and question why you might need a certain garbage collector, if any at all, or why you might need your runtime to have bindings for the OS system calls when you don't use them. Slippery slope. Richness is usually a good thing, not bad.]
>Yet in Java, it’s hard to get anything shorter than ten or twenty lines of code. See some code duplication, and by the time you’ve written the classes and interfaces and methods you need to write to remove the duplication, the code is just as long as it was before.
[A personal opinion that will send java programmers in uproar. not that java doesn't suck ;-]
>Languages written by hackers for hackers like Perl and Ruby and Python are lots better (and, I find for myself, a lot more productive for me for the kinds of projects I work on), and I can write shorter programs in them, yet they don’t help me go further
[and now the Perl, Python and Ruby programmers feel trolled and will jump at your neck. You requirements are of the DWIM kind.]
>they don’t help me make my program shorter.
[Yes, and an Aston Martin can't tow a boat. Right tool for the job]
>Now I see some pattern in my code, if I’m doing more typing than I want to be doing, BAM I write a macro and use it. Just like that
[and the Lisp programmer collective is surprised by your surprise.]
and so on and so forth.
[You came to the wrong Lisp then, as Arc has no libraries compared to all the mainstream lisp dialects]
I'm not saying that Arc has better libraries than other Lisps, I'm saying that for me the advantages of Arc outweigh for me the disadvantages of not having the libraries that other languages do.
[Actually, scheme's hygienic macros shift the burden of capture-avoidance to the compiler. It's CL that has to use gensym.]
Yes, what I was saying was that when I learned about hygienic macros I thought they were a good idea for that reason.
Richness is usually a good thing
If I can choose to use a feature or not (as it typical with libraries: I can choose to use a library or not) then the cost to me of a feature that I don't want is zero; if I have to use a feature or it is harder to avoid then it matters to me whether the cost to me of that feature outweighs the benefit to me.
A personal opinion
Not at all. While it wasn't the purpose of my thank-you to do such a demonstration, it's easy to compare the relative length of code needed to do a particular implementation in different languages.
feel trolled
Yes, perhaps it is common for people who like X to be mad if I say that I prefer Y.
DWIM kind
I'm not following you.
and the Lisp programmer collective is surprised by your surprise
Perhaps they have had better luck than I have at writing hygienic macros.
None of the remarks you list seem snide to me.
His intent has been "largely positive", but what do you expect people to say after his "Perl, Python, Ruby, Java, Scheme and Common Lisp suck because they didn't allow me to write compact code" remarks?
Here is what will happen: Perl and Ruby programmers will ask you to show code and they will rewrite it in one-liners. Java and Python programmers will stuff code into packages/modules and write a tiny 5-line "client" for it. And Scheme and Common Lisp programmers will take absolute pleasure in skinning your argument about macrology and hygiene, the Common Lispers keeping a bucket of salt nearby for the rubbing.
"Yet in Java, it’s hard to get anything shorter than ten or twenty lines of code."
I am a Java programmer, I find much to like about Java, and I agree totally with this statement. I tried writing some functionality in Clojure, then re-writing in Java. It was a factor of 2 or 3 increase in lines of code.
I see CatDancer's touched a bit of a raw nerve. You've been compelled to respond with about a dozen (didn't count them) posts all quite attacking of both CatDancer and Arc.
What the hell is your problem with a) someone creating their own Lisp implementation, and b) someone else enjoying using it?
you wouldn't understand it, and it's not a personal problem of mine: just consider my behavior in this discussion a throw-back to a long-dead form of communication from when programmers where held accountable to their words :-)
I should have been nice, we're all equally-right in some way. hugs.
He does say that he has long liked Lisp, and that he generally liked Scheme, so he already had his feet wet. And although the documentation is, well, scarce, he did read through the source code file arc.arc.
Read what he wrote again and you will be surprised by the logic:
"I’ve long liked Lisp, but hadn’t been programming in Lisp for a long time because I hadn’t found any features in Lisp compelling enough to overcome the advantage other languages had in having large libraries available and such like."
I mean, come ON. If Lisp wasn't compelling enough because of the perceived lack of libraries, then Arc is the last way to come back to Lisp as it has NIL.
It's completely acceptable to have a preferred Lisp, but it's unacceptable to do so for irrational reasons ;-) Every time you need a new library/feature in Arc you're most likely to call out to the MzScheme runtime and FFI. It's highly hypocritical of you to dismiss a language for lack of libraries, then jump on another language it hosts.
If Lisp wasn't compelling enough because of the perceived lack of libraries, then Arc is the last way to come back to Lisp as it has NIL.
I think you've misunderstood this sentence, which explains why you don't understand the logic.
He is dismissing Lisp because [library pain] is not alleviated by [compelling language features]. For him, in Arc, [compelling language features] do alleviate [library pain], so he is happy to use Arc. This logic is fine even if the [library pain] in Arc is actually worse than the [library pain] he experienced in Lisp, because [compelling language features] differs too.
So, no hypocrisy. You could still argue that he should have experienced less library pain in Lisp than he did experience, or that Lisp might have compelling features that he overlooked, or even that library pain cannot in principle be alleviated by language features, though I won't comment there.
For me it's a cost/benefit analysis. Programming in MzScheme or Arc has a cost to me in that the libraries I typically use for my projects are mostly available in other languages, so they are harder to get to. I may decide to program in a language despite such a cost if it has other benefits for me that I find outweigh the cost. While I liked MzScheme, I didn't find its benefit to me great enough to outweigh the inconvenience of the library issue. The scale tipped in the other direction for me with Arc, where I'm happy enough with the benefits I find in Arc that they outweigh the other disadvantages for me.
Your article doesn't list any of the library features that tipped the scale in favor of Arc. It's unfair to the MzScheme developers and users to dismiss their platform without telling them what's lacking. Please revise the article and flesh it further, if you have the time, because as it stands, it doesn't stand well under scrutiny.
Public technical rationales aught to be a little more than "just cuz" and personal preference. If you wanted a discussion that is ..
I'm sorry but this seems an aggressive comment to me. CatDancer did mention the preference of simple macros over MzScheme's more complicated hygienic macros. Beyond that, Arc is different from Scheme and everyone knows it. The differences are documented and they are the reason why Arc is not Scheme. You do not have to challenge the piece just because you don't particularly like the changes Arc made in comparison to Scheme.
Your article doesn't list any of the library features that tipped the scale in favor of Arc.
The features of Arc are well described in the Arc tutorial, http://ycombinator.com/arc/tut.txt would you recommend that I include a link to that?
it doesn't stand well under scrutiny ... public technical rationales aught to be a little more than ...
Well, I had posted it to the Arc forum, where people are already familiar with Arc. I expect that your criticism is valid if it had been intended to be a technical article.
> It had to be said, as much as I hate to be rude and blunt like this
Actually it didn't, but that hasn't stopped you before;
I don't know about 'hacking nirvana', but I found the Arc tutorial coupled with help from an appropriate newsgroup to grok macros (#arc? I don't remember now) was enough to write a ray tracer (LightMakesRight in the anarki distribution). Arc was my first exposure to a lisp dialect.