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.
Comments
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.