Re: [9fans] nice quote

[Eris Discordia <eris.discordia@gmail.com>]

> general-purpose language good for "system programming"--you seem to call
> that "being a good OS language"--

I take this part back. I mixed your post with Jason Catena's for a moment.

--On Saturday, September 05, 2009 15:14 +0100 Eris Discordia 
<eris.discordia@gmail.com> wrote:

>> Let me be a little pedantic.
>
> The 9fans know given the haphazard nature of a hobbyist's knowledge I am
> extremely bad at this, but then let me give it a try.
>
>> FYI, it's been Lisp for a while.
>
> As long as Britannica and Merriam-Webster call it LISP I don't think
> calling it LISP would be strictly wrong. Has LISt Processing become
> stigmatic in Lisp/LISP community?
>
>> Like what? The if statement, which was invented by Lisp? The loop
>> statement, for expressing loops? It sounds like you got a dose of Scheme
>> rather than Lisp to me.
>
> I just read in Wikipedia that, "Lisp's original conditional operator,
> cond, is the precursor to later if-then-else structures," without any
> citations. Assuming that to be true conditional branching is a
> fundamental element of control flow and it has existed in machine
> languages ever since early days. There's really very little to brag about
> it.
>
> Regardless, I offer the following comparison:
>
>> 19.2. How to Use Defstruct
> <http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node170.html>
>
>> Struct (C programming language)
> <http://en.wikipedia.org/wiki/Struct_(C_programming_language)>
>
> In the (small mind?) mental model of small computer there's the row of
> pigeonholes and the stencil you may slide along the row for "structured"
> access to its contents. I leave it to you to decide which of the above
> better corresponds to that. My opinion you already know.
>
> Indeed, my only encounter with LISP has been Scheme and through a failed
> attempt to read SICP.
>
>> This hasn't been true for a while. Common Lisp is a general purpose
>> language like any other. The only thing I have ever found obnoxious about
>> CL was the filesystem API. Most CL implementations are compilers these
>> days and they produce surprisingly efficient machine code. The Scheme
>> situation is more diverse but you can definitely find performance if
>> that's what you're eluding to.
>
> I was alluding to the expressive power of C versus LISP considered with
> respect to the primitives available on one's computing platform and
> primitives in which solutions to one's problems are best expressed. It
> isn't a matter of whether the language you use is supplemented by good
> libraries or how fast the binary image you produce can run as I have
> little doubt out there exist lightning fast implementations of complex
> algorithms in LISP. I was trying to give my personal example for why I
> managed to learn C and failed to learn LISP.
>
> If you have a scrawny x86 on your desktop and are trying to implement,
> say, a bubble sort--yes, the notorious bubble sort, it's still the first
> thing that comes to a learner's mind--it seems C is quite apt for
> expressing your (embarrassing) solution in terms of what is available on
> your platform. Loops, arrays, swapping, with _minimal_ syntactic
> distraction. Simple, naive algorithms should end up in simple,
> immediately readable (and refutable) code. Compare two implementations
> and decide for yourself:
>
> <http://en.literateprograms.org/Bubble_sort_(Lisp)>
> <http://en.literateprograms.org/Bubble_sort_(C)>
>
>>> Its claim to fame as the language for "wizards" remains.
>>
>> I think this has more to do with Lisp users being assholes than anything
>> intrinsic about Lisp. This is one of the nice things about Clojure. It's
>> a break from tradition in this regard, as well as many others.
>
> I really did mean "wizards" by "wizards." I intended no insult--merely
> sort of an awed jealousy.
>
>> It's as though you have the up-to-date negative propaganda, but not the
>> up-to-date facts.
>
> Of course. Propaganda has a wider outreach than facts, particularly when
> for every textbook on a subject there are, I don't know, ten (or more?)
> on the competing subject.
>
>> The main benefits it had in AI were features that came from garbage
>> collection and interactive development.
>
> More importantly, LISt Processing which used to be an element of the
> expert systems approach to AI and which is now defunct (as a way of
> making machines intelligent, whatever that means). While "expert systems"
> continue to exist the word causes enough reverb of failure to be replaced
> by other buzzwords: knowledge-based systems, automated knowledge bases,
> and whatnot.
>
> I think, and may be dead wrong, LISP's ominous appearance came from
> adhering to an AI paradigm. Now that the paradigm's no more viable why
> should the appearance persist?
>
>> An advantage it has these days is that it produces code that performs
>> better than, say, Python or Perl.
>
> I cannot comment on this. Have no knowledge of Python and beg to disagree
> about Perl. The entry barrier for learning Perl was low enough for me to
> learn and use it, unlike LISP.
>
>> I definitely would not call being a "general purpose system" and
>> suitability for "application programming" a "specific application area."
>
> Well, for one thing I believe you have misread me. I said C was a
> general-purpose language good for "system programming"--you seem to call
> that "being a good OS language"-- and low-level application programming.
> I probably should have taken more care and wrote the precise term:
> systems programming.
>
>> This is like saying agglutinative languages are worse for conquering the
>> world with than isolating languages because the Ottoman empire fell
>> before the English empire.
>
> Correlation doesn't imply causation--that's true. But there _are_ ways to
> ascertain a correlation is due to a causal relationship. One such way is
> to identify known causes of success or failure. _If_ one claims a
> language costs more to learn and rewards similarly or even less than
> another language one already has identified a known cause of failure. If
> failure does occur, causation by the language itself, rather than its
> surrounding elements (marketers, users, designers, climate, serendipity),
> cannot be ruled out.
>
>> I think it's mostly happenstance. Lots of languages succeed despite
>> having a killer app or app area. Python's a good example.
>
> Despite _not_ having those, you mean, right? I think it's too early to
> talk about Python's success. It has barely lived half as long as C and
> one-third as long as LISP. If you're really going to call Python
> successful I don't know how you're going to describe Java.
>
>> Please don't interpret this as "Lisp kicks C's ass."
>
> I don't, and I certainly weren't implying "C kicks LISP's ass." I don't
> qualify for that sort of assertion.
>
>> There are simply too many variables to lay the blame at Lisp's alleged
>> functional basis.
>
> That's a very good point. I did say "LISP represents a programming
> paradigm" but I don't think its (perceived?) failure has to do with the
> paradigm itself, rather with whether mere mortals can find application
> areas where the cost of assimilating that paradigm (and therefore
> learning the language) is justified by measurable gains.
>
>
>
>
> --On Friday, September 04, 2009 15:36 -0600 Daniel Lyons
> <fusion@storytotell.org> wrote:
>
>> Let me be a little pedantic.
>>
>> On Sep 4, 2009, at 2:18 PM, Eris Discordia wrote:
>>> Above says precisely why I did. LISP is twofold hurtful for me as a
>>> naive, below average hobbyist.
>>
>> FYI, it's been Lisp for a while.
>>
>>> For one thing the language constructs do not reflect the small
>>> computer primitives I was taught somewhere around the beginning of
>>> my education.
>>
>> Like what? The if statement, which was invented by Lisp? The loop
>> statement, for expressing loops? It sounds like you got a dose of Scheme
>> rather than Lisp to me.
>>
>>> For another, most (simple) problems I have had to deal with are far
>>> better expressible in terms of those very primitives. In other
>>> words, for a person of my (low) caliber, LISP is neither suited to
>>> the family of problems I encounter nor suited to the machines I
>>> solve them on.
>>
>> This hasn't been true for a while. Common Lisp is a general purpose
>> language like any other. The only thing I have ever found obnoxious about
>> CL was the filesystem API. Most CL implementations are compilers these
>> days and they produce surprisingly efficient machine code. The Scheme
>> situation is more diverse but you can definitely find performance if
>> that's what you're eluding to.
>>
>>> Its claim to fame as the language for "wizards" remains.
>>
>> I think this has more to do with Lisp users being assholes than anything
>> intrinsic about Lisp. This is one of the nice things about Clojure. It's
>> a break from tradition in this regard, as well as many others.
>>
>>> Although, mind you, the AI paradigm LISP used to represent is long
>>> deprecated (Rodney Brooks gives a good overview of this deprecation,
>>> although not specifically targeting LISP, in "Cambrian Intelligence:
>>> The Early History of the New AI"). One serious question today would
>>> be: what's LISP _really_ good for? That it represents a specific
>>> programming paradigm is not enough justification. Ideally, a
>>> language should represent a specific application area, as does C,
>>> i.e. general-purpose system and (low-level) application programming.
>>
>>
>> It's as though you have the up-to-date negative propaganda, but not the
>> up-to-date facts. Lisp is "really good for" the same kinds of things
>> other general purpose languages are good for. The main benefits it had in
>> AI were features that came from garbage collection and interactive
>> development. You get those benefits today with lots of systems, but that
>> doesn't mean they aren't still there in Lisp. An advantage it has these
>> days is that it produces code that performs better than, say, Python or
>> Perl. I definitely would not call being a "general purpose system" and
>> suitability for "application programming" a "specific application area."
>> This is like saying agglutinative languages are worse for conquering the
>> world with than isolating languages because the Ottoman empire fell
>> before the English empire.
>>
>> Please don't interpret this as "Lisp kicks C's ass." I'm saying, you're
>> only seeing the negative half of the situation, and seeing too much
>> causality. I think it's mostly happenstance. Lots of languages succeed
>> despite having a killer app or app area. Python's a good example.
>> Isolating the exact ingredients for the success of any language is
>> probably impossible. I'd say only with C is it really clear what led to
>> success, and it wasn't exclusively features of the language itself
>> (though it was a part of it), but also that it came with Unix along with
>> the source code. If the quacks had chosen C instead of Lisp for their "AI
>> research" perhaps C would have taken a big hit during the so-called AI
>> winter instead of Lisp. Perhaps if the Lisp machine vendors hadn't
>> misunderstood basic economics so thoroughly, their machines would have
>> become more common and taken Lisp with them the way Unix brought C. There
>> are simply too many variables to lay the blame at Lisp's alleged
>> functional basis. Especially today when languages like Haskell exist that
>> take functional so much further they make Lisp look like a procedural
>> language by comparison.
>>
>> —
>> Daniel Lyons
>>
>>