From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 5 Sep 2009 15:14:04 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <7AAFE4127E1DB57785BB273A@[192.168.1.2]> In-Reply-To: <55D72913-15FB-415F-BE43-7D173E0AC449@storytotell.org> References: <542783.92348.qm@web83904.mail.sp1.yahoo.com> <55D72913-15FB-415F-BE43-7D173E0AC449@storytotell.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] nice quote Topicbox-Message-UUID: 657931da-ead5-11e9-9d60-3106f5b1d025 > Let me be a little pedantic. The 9fans know given the haphazard nature of a hobbyist's knowledge I am=20 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=20 calling it LISP would be strictly wrong. Has LISt Processing become=20 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.=20 Assuming that to be true conditional branching is a fundamental element of=20 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 > Struct (C programming language) In the (small mind?) mental model of small computer there's the row of=20 pigeonholes and the stencil you may slide along the row for "structured"=20 access to its contents. I leave it to you to decide which of the above=20 better corresponds to that. My opinion you already know. Indeed, my only encounter with LISP has been Scheme and through a failed=20 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=20 respect to the primitives available on one's computing platform and=20 primitives in which solutions to one's problems are best expressed. It=20 isn't a matter of whether the language you use is supplemented by good=20 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=20 in LISP. I was trying to give my personal example for why I managed to=20 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=20 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.=20 Loops, arrays, swapping, with _minimal_ syntactic distraction. Simple,=20 naive algorithms should end up in simple, immediately readable (and=20 refutable) code. Compare two implementations and decide for yourself: >> 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=20 for every textbook on a subject there are, I don't know, ten (or more?) on=20 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=20 machines intelligent, whatever that means). While "expert systems" continue = to exist the word causes enough reverb of failure to be replaced by other=20 buzzwords: knowledge-based systems, automated knowledge bases, and whatnot. I think, and may be dead wrong, LISP's ominous appearance came from=20 adhering to an AI paradigm. Now that the paradigm's no more viable why=20 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=20 about Perl. The entry barrier for learning Perl was low enough for me to=20 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=20 general-purpose language good for "system programming"--you seem to call=20 that "being a good OS language"-- and low-level application programming. I=20 probably should have taken more care and wrote the precise term: systems=20 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=20 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=20 costs more to learn and rewards similarly or even less than another=20 language one already has identified a known cause of failure. If failure=20 does occur, causation by the language itself, rather than its surrounding=20 elements (marketers, users, designers, climate, serendipity), cannot be=20 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=20 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=20 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=20 paradigm" but I don't think its (perceived?) failure has to do with the=20 paradigm itself, rather with whether mere mortals can find application=20 areas where the cost of assimilating that paradigm (and therefore learning=20 the language) is justified by measurable gains. --On Friday, September 04, 2009 15:36 -0600 Daniel Lyons=20 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. > > =E2=80=94 > Daniel Lyons > >