Re: [9fans] nice quote

[J.R. Mauro]

On Sat, Sep 5, 2009 at 2:26 PM, erik quanstrom  wrote:
> i'm not a lisp fan.  but it's discouraging to see
> such lack of substance as the following (collected
> from a few posts):
>
>> Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
>> Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
>> the one about how he lives in a car in the Bay Area because he's too
>> crazy to get hired?
>
> surely an ad hominum attack like this neither furthers an
> argument nor informs anyone.
>
>> I forgot this: Graham basically accuses programmers who don't find LISP as
>> attractive (or powerful, as he puts it) as he does of living on lower
>> planes of existence from which the "heavens above" of functional (or only
>> LISP) programming seem incomprehensible. He writes/speaks persuasively,
>> he's a successful businessman, but is he also an honest debater?
>
> and here i don't see an argument at all.
>
>> 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.
>
> i'd love to argue this factually, but my knowledge isn't
> that extensive.  i think you'll find in the wiki entry for
> Computer that much of what we take for granted today
> was not obvious at the time.  stored program computers
> with branching didn't come along until about 1948
> (einiac).  i hope someone will fill in the gaps here.
> i think it's worth appreciating how great these early
> discoveries were.

There's a talk Doug McIllroy gave where he joked about how he
basically invented (or rather, discovered) recursion because someone
said ``Hey, what would happen if we made a FORTRAN routine call
itself?'' IIRC he had to tinker with the compiler to get it to accept
the idea, and at first, no one realized what it would be good for.

>
> in the same vein, i don't know anything much about file
> systems that i didn't steal from ken thompson.
>
> - erik
>
>

Re: [9fans] nice quote

[David Leimbach]

On Sat, Sep 5, 2009 at 6:58 PM, Jason Catena  wrote:

> Hailed Eris:
> > 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.
>
> I think one of the reasons there exists little languages, and cliches
> such as "the right tool for the job", is that the "primitives
> available on one's computing platform" are very often not the
> "primitives in which solutions to one's problems are best expressed."
> In this respect rating the "expressive power of C versus LISP" depends
> very much on the problem domain under discussion.
>
> For "systems programming", C has the advantage in both practice (use
> in running systems) and theory: processes which take a lot of system
> resources to execute also tend to take a lot of C code, whereas in
> most higher-order languages, things which represent high-level
> runtime-consuming abstractions tend look little different than simple
> bit-level operations.  The difference is one of approach, I guess:
> whether you want to write optimal code yourself, and see what the
> machine is doing, or trust the compiler to find a good way to
> translate to machine language and run (in real-time) your
> efficient-to-code higher-order functions.  The better the translation
> from the higher-level language, the more this difference becomes a
> matter of taste, programming style, availability of programmers, and
> the body of domain knowledge already represented in language
> libraries.
>
> I would like to see Haskell fill C's niche: it's close to C's
> execution speed now, and pure functions and a terse style gives real
> advantages in coding speed (higher-order functions abstract common
> "patterns" without tedious framework implementations), maintainability
> (typeclasses of parameters in utility functions means you don't write
> different implementations of the same function for different types,
> yet preserve type compatibility and checking), and reliability (pure
> functions don't depend on state, so have fewer moving parts to go
> wrong).
>
>
Well I can think of 3 operating systems written in Haskell now.  One was an
executable specification for validating a secure L4 implementation.  One is
hOp, and then there's also House, based on hOp.

There's also Kinetic, written primarily in Haskell.
http://www.ninj4.net/kinetic/

The newest fork of House has TCP/IP networking uhm working.
http://web.cecs.pdx.edu/~kennyg/house/

There is a haskell file system in development too now
http://www.haskell.org/halfs/, but a lot of links don't work :-).

I've been writing a good bit of Haskell these days at work as well, mainly
due to the fact that it's possible to write some fairly sophisticated code
quickly, and even get pretty darned good performance out of it.



> Jason Catena
>
>

Re: [9fans] nice quote

[Jason Catena]

Hailed Eris:
> 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.

I think one of the reasons there exists little languages, and cliches
such as "the right tool for the job", is that the "primitives
available on one's computing platform" are very often not the
"primitives in which solutions to one's problems are best expressed."
In this respect rating the "expressive power of C versus LISP" depends
very much on the problem domain under discussion.

For "systems programming", C has the advantage in both practice (use
in running systems) and theory: processes which take a lot of system
resources to execute also tend to take a lot of C code, whereas in
most higher-order languages, things which represent high-level
runtime-consuming abstractions tend look little different than simple
bit-level operations.  The difference is one of approach, I guess:
whether you want to write optimal code yourself, and see what the
machine is doing, or trust the compiler to find a good way to
translate to machine language and run (in real-time) your
efficient-to-code higher-order functions.  The better the translation
from the higher-level language, the more this difference becomes a
matter of taste, programming style, availability of programmers, and
the body of domain knowledge already represented in language
libraries.

I would like to see Haskell fill C's niche: it's close to C's
execution speed now, and pure functions and a terse style gives real
advantages in coding speed (higher-order functions abstract common
"patterns" without tedious framework implementations), maintainability
(typeclasses of parameters in utility functions means you don't write
different implementations of the same function for different types,
yet preserve type compatibility and checking), and reliability (pure
functions don't depend on state, so have fewer moving parts to go
wrong).

Jason Catena

Re: [9fans] nice quote

[erik quanstrom]

> > The instruction most conspicuously absent from the instruction set of the
> > Z3 is conditional branching. [...] but there is no straightforward way to
> > implement conditional sequences of instructions. However, we will show
> > later than conditional branching can be simulated on this machine.

i think your reasoning is going backwards in time.  the fact that
a historian later can note that they *could* have had conditional
branching, if they'd thought of it further bolsters my position
that it is not immediately obvious that conditional branching
is what you want.

in fact, none of the things we take for granted --- e.g., binary,
digital, stack-based, etc. --- were immediately obvious.  and it
might be that we've got these thing that we "know" wrong yet.

i would imagine that in 30 years there will be several "obvious"
things about quatum computers that nobody's thought of
yet.

- erik

Re: [9fans] nice quote

[Eris Discordia]

so you're saying that the table in this section is wrong?

http://en.wikipedia.org/wiki/Computer#History_of_computing

if it is and you can back it up, i sugeest you fix wikipedia.


It isn't wrong.

The exact wording from "The First Computers: History and Architectures" 
goes:



The instruction most conspicuously absent from the instruction set of the
Z3 is conditional branching. [...] but there is no straightforward way to
implement conditional sequences of instructions. However, we will show
later than conditional branching can be simulated on this machine.


On the other hand, Wikipedia's article on Plankalkuel says:


Plankalkül drew comparisons to APL and relational algebra. It includes
assignment statements, subroutines, conditional statements, iteration,
floating point arithmetic, arrays, hierarchical record structures,
assertions, exception handling, and other advanced features such as
goal-directed execution.


-- 

In other words, both statements are correct. Z3 did not have conditional 
branching (given the type of store it used it would be too hard), however 
Plankalkuel did provision conditionals, invocation, and subroutines--all 
that is necessary to implement conditional branching.




--On Saturday, September 05, 2009 20:17 -0400 erik quanstrom 
 wrote:



I wasn't, in this case at least, implying something not backed by firm
evidence. Conditional branching embodied in actual computers goes back
to  Plankalkuel on Z3. The idea is as early as Babbage. It comes as
natural  even to first-timers, following much more difficult conception
of a notion  of control flow, that there must be a manner of
conditionally passing it  around.


so you're saying that the table in this section is wrong?

http://en.wikipedia.org/wiki/Computer#History_of_computing

if it is and you can back it up, i sugeest you fix wikipedia.

- erik

Re: [9fans] nice quote

[erik quanstrom]

> I wasn't, in this case at least, implying something not backed by firm 
> evidence. Conditional branching embodied in actual computers goes back to 
> Plankalkuel on Z3. The idea is as early as Babbage. It comes as natural 
> even to first-timers, following much more difficult conception of a notion 
> of control flow, that there must be a manner of conditionally passing it 
> around.

so you're saying that the table in this section is wrong?

http://en.wikipedia.org/wiki/Computer#History_of_computing

if it is and you can back it up, i sugeest you fix wikipedia.

- erik

Re: [9fans] Disks not detected while installing Plan 9 on Dell OptiPlex GX1

[erik quanstrom]

> I have an older Dell OptiPlex GX1 (600MHz PIII) that I am having
> trouble installing Plan 9 onto.  I am using a bootable CD ISO of Plan
> 9 that I downloaded last night so things should be current.
> 
> The system has two 130GB hard drives installed.  Everything works
> under Debian Linux.  

would you be willing to try
ftp://ftp.quanstro.net/other/9atom.iso.bz2
?  could you send me (offlist) the output of dmesg after having
booted debian.  i don't see any reason your drives shouldn't
be recognized, but i could be missing something.

- erik

Re: [9fans] nice quote

[Eris Discordia]

I forgot this: Graham basically accuses programmers who don't find LISP
as  attractive (or powerful, as he puts it) as he does of living on
lower  planes of existence from which the "heavens above" of functional
(or only  LISP) programming seem incomprehensible. He writes/speaks
persuasively,  he's a successful businessman, but is he also an honest
debater?


and here i don't see an argument at all.


I was trying to say the same thing about Paul Graham's view of people who 
don't like, or "grok," LISP. That he doesn't argue the point--he presents 
it as a fact.



i'd love to argue this factually, but my knowledge isn't
that extensive.  i think you'll find in the wiki entry for
Computer that much of what we take for granted today
was not obvious at the time.  stored program computers
with branching didn't come along until about 1948
(einiac).  i hope someone will fill in the gaps here.
i think it's worth appreciating how great these early
discoveries were.


I agree with your point about non-triviality of much about computers that's 
taken for trivial today. However, I happened to have consulted this book 
couple of years ago:




(This is Google Books search inside the book with the term "conditional 
branching.")


I wasn't, in this case at least, implying something not backed by firm 
evidence. Conditional branching embodied in actual computers goes back to 
Plankalkuel on Z3. The idea is as early as Babbage. It comes as natural 
even to first-timers, following much more difficult conception of a notion 
of control flow, that there must be a manner of conditionally passing it 
around.




--On Saturday, September 05, 2009 14:26 -0400 erik quanstrom 
 wrote:



i'm not a lisp fan.  but it's discouraging to see
such lack of substance as the following (collected
from a few posts):


Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
the one about how he lives in a car in the Bay Area because he's too
crazy to get hired?


surely an ad hominum attack like this neither furthers an
argument nor informs anyone.


I forgot this: Graham basically accuses programmers who don't find LISP
as  attractive (or powerful, as he puts it) as he does of living on
lower  planes of existence from which the "heavens above" of functional
(or only  LISP) programming seem incomprehensible. He writes/speaks
persuasively,  he's a successful businessman, but is he also an honest
debater?


and here i don't see an argument at all.


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.


i'd love to argue this factually, but my knowledge isn't
that extensive.  i think you'll find in the wiki entry for
Computer that much of what we take for granted today
was not obvious at the time.  stored program computers
with branching didn't come along until about 1948
(einiac).  i hope someone will fill in the gaps here.
i think it's worth appreciating how great these early
discoveries were.

in the same vein, i don't know anything much about file
systems that i didn't steal from ken thompson.

- erik

Re: [9fans] nice quote

[Eris Discordia]

Using your theories, please explain why Lisp and Plan 9 both hover around
the same level of popularity (i.e., not very, but not dead either).


I don't think I can say anything in that respect that cannot either be 
easily refuted or greatly improved upon by someone already reading this 
list and just too busy with their own stuff to post. Some of them 
explicitly avoid feeding the troll (that I be, supposedly).


Anyway, here's what I think: Plan 9 and LISP are different, evolutionarily. 
LISP seems to me like a downsized reptile that has survived and been forced 
to exist in the shadow of mammals after the Mesozoic while Plan 9 looks 
more like a lemur. A rather recently developed mammal driven into a small 
area by its close kin from a common ancestor.


And one primary note: I have come to understand, in part thanks to this 
very list, that popularity isn't really a good measure of merit for 
computer stuff but you asked about popularity so I'll try to focus on that. 
(Case in point, there's a lot I read about on this list that I don't think 
I'd hear about in a lifetime, and this isn't a popular list.)


**

LISP evolved in a parallel path to the line of languages that descended 
from ALGOL. It represented/represents a programming paradigm--whose 
significance is beyond me but visible to CS people--and it used to also 
embody an application area. That application area, at the time, overlapped 
with the ambitions of some of the best experts in computation. LISP gained 
momentum, became an academic staple, was the pride and joy of world's best 
CS/CE departments. The application area got hit but the programming 
paradigm was strong as before.


The paradigm has scientific value--which is again beyond me but I trust CS 
people on that--so it continues to be taught at world's best CS/CE 
departments and to up-and-coming programmers and future computer 
scientists. SICP is witness to that. In the academy, LISP will live on as 
long as the paradigm it's attached to lives on and is deemed significant. 
Those same people who are educated in some dialect of LISP, as well as 
other languages, found businesses and apply their knowledge; occasionally, 
by way of their training in LISP. For whatever reason they see merit in it 
that many self-educated programmers or those trained at lesser institutions 
don't. Obviously, there aren't that many top CS/CE departments and those 
with founder status or strongly influences by founder institutions are 
still fewer. Hence, LISP's living dead state: "popularity" among the elite. 
Mind you, the natural divide between the two groups can sometimes be a 
cause of resentment and get non-LISP people badmouthing it.


**

Plan 9, on the other hand, was supposed to be a drop-in successor to 
UNIX--a natural step forward. It was supposed to satisfy long-time UNIX 
users by deceiving them with a similar-looking toolset while implementing a 
large change of philosophy whose impact would only become clear after 
(previous) UNIX users had already settled in. The factors that kept it from 
actually replacing UNIX everywhere are many.


One factor was timing. It reached various tiers of "ignorant masses" when 
not one but multiple possible continuations of UNIX, all of them FOSS, had 
already gained foothold (GNU/Linux and *BSD).


The other factor was its overly complex arrangement compared to the mundane 
purposes of lowly creatures more or less like me. I have tried arguing why 
Plan 9 as it is is a hassle on desktop systems and have been met with 
criticism that mostly targeted my lack of computer aptitude in general 
rather than my argument. I stressed what I termed "conceptual complexity" 
of Plan 9's model of how things should be and the lack of _any_ user 
friendly, albeit sane, abstraction on top of that complexity.


A third, more important, factor is that it was advocated to people who 
probably couldn't understand how Plan 9 would serve them better than things 
they heard of more regularly, where was this new thing's edge that 
justified the cost of its adoption. I for one am still at a loss on that 
matter. As a hobbyist, I lurk, and occasionally--they say--troll, around 
here but I'm not keeping my huge media collection on a Plan 9 installation 
or using Acme for entering multi-lingual (up to three languages until a 
while ago, four recently) text. Either task would be extremely cumbersome 
to do on Plan 9 (and this really has little to do with the OS itself). In 
short, I won't be doing Plan 9 because it's Plan 9. I, and most of the 
lowly ones, need further justification that either hasn't been presented or 
is way above my, or our, head.


The fourth factor I can think of is Plan 9's owners' attitude towards it. I 
once dared go as far as saying it was actually "jettisoned." For reasons 
that are beyond me Plan 9 isn't seeing much attention from Bell Labs or its 
creators. It currently seems to lack the Benevolent Dictator for Life 
figure many FOSS pro

[9fans] Disks not detected while installing Plan 9 on Dell OptiPlex GX1

[Matt Adams]

Hi folks:

I have an older Dell OptiPlex GX1 (600MHz PIII) that I am having
trouble installing Plan 9 onto.  I am using a bootable CD ISO of Plan
9 that I downloaded last night so things should be current.

The system has two 130GB hard drives installed.  Everything works
under Debian Linux.  

*** Plan 9 is not able to detect the hard drives. *** 

Here is what I see during the boot process:

PBS1...
Plan 9 from Bell Labs
ELCR: 0C20
islba: drive 0x80 extensions version 33.0 cx 0.5
extgetsize: drive 0x80 info flags 0x1
bios0: drive 0x80: 137,438,952,960 bytes, type 3
islba: drive 0x81 extensions version 33.0 cx 0.5
extgetsize: drive 0x81 info flags 0x1
bios0: drive 0x81: 137,438,952,960 bytes, type 3
reading drive 0x80 offset 0 into seg:off 600:0...
biosdiskcall: int 13 op 0x42 drive 0x80 failed, ah error code 0x80
sectread: bios failed to read 512 @ sector 0 of 0x80
probing cd...dev A0 port 170 config 85C0 capabilities 0F00 mwdma 0407
found partition sdD0!cdboot; 52978+1440
reading drive 0x80 offset 0 into seg:off 600:0...
biosdiskcall: int 13 op 0x42 drive 0x80 failed, ah error code 0x80
sectread: bios failed to read 512 @ sector 0 of 0x80
reading drive 0x80 offset 1 into seg:off 600:0...
biosdiskcall: int 13 op 0x42 drive 0x80 failed, ah error code 0x80
sectread: bios failed to read 512 @ sector 1 of 0x80

During the partdisk step of the install process Plan 9 only sees sdD0
as possible disks.

I have tried saying "yes" and "no" to DMA for disk drives before the
windowing system starts up and there is no difference in detected
disks.

Does anyone have any suggestions as to what I might to do overcome
this problem?  I would appreciate anything here as I am flying pretty
blind.

I am running the most recent version of the BIOS (A10) from Dell.


Thanks in advance,

Matt

Re: [9fans] nice quote

[Daniel Lyons]

Eris,

Using your theories, please explain why Lisp and Plan 9 both hover  
around the same level of popularity (i.e., not very, but not dead  
either).


—
Daniel Lyons

Re: [9fans] nice quote

[erik quanstrom]

i'm not a lisp fan.  but it's discouraging to see
such lack of substance as the following (collected
from a few posts):

> Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
> Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
> the one about how he lives in a car in the Bay Area because he's too
> crazy to get hired?

surely an ad hominum attack like this neither furthers an
argument nor informs anyone.

> I forgot this: Graham basically accuses programmers who don't find LISP as 
> attractive (or powerful, as he puts it) as he does of living on lower 
> planes of existence from which the "heavens above" of functional (or only 
> LISP) programming seem incomprehensible. He writes/speaks persuasively, 
> he's a successful businessman, but is he also an honest debater?

and here i don't see an argument at all.

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

i'd love to argue this factually, but my knowledge isn't
that extensive.  i think you'll find in the wiki entry for
Computer that much of what we take for granted today
was not obvious at the time.  stored program computers
with branching didn't come along until about 1948
(einiac).  i hope someone will fill in the gaps here.
i think it's worth appreciating how great these early
discoveries were.

in the same vein, i don't know anything much about file
systems that i didn't steal from ken thompson.

- erik

Re: [9fans] nice quote

[Eris Discordia]

Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
the one about how he lives in a car in the Bay Area because he's too
crazy to get hired?


Patience, brother. Search "Paul Graham" on that page and let your mind do 
the free association. And I did say it was about wondering, didn't I?


--On Saturday, September 05, 2009 07:36 -0700 John Floren 
 wrote:



On Sat, Sep 5, 2009 at 7:27 AM, Eris Discordia
wrote:

One serious question today would be: what's LISP _really_ good for?


http://www.paulgraham.com/avg.html


I could do a similar thing:



... and leave you wondering (or not). I won't.



Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
the one about how he lives in a car in the Bay Area because he's too
crazy to get hired?


John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] nice quote

[Eris Discordia]

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




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:





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,

Re: [9fans] nice quote

[Eris Discordia]

I forgot this: Graham basically accuses programmers who don't find LISP as 
attractive (or powerful, as he puts it) as he does of living on lower 
planes of existence from which the "heavens above" of functional (or only 
LISP) programming seem incomprehensible. He writes/speaks persuasively, 
he's a successful businessman, but is he also an honest debater?


--On Saturday, September 05, 2009 12:02 +0100 Richard Miller 
<9f...@hamnavoe.com> wrote:



One serious question today would be: what's LISP _really_ good for?


http://www.paulgraham.com/avg.html

Re: [9fans] nice quote

[John Floren]

On Sat, Sep 5, 2009 at 7:27 AM, Eris Discordia wrote:
 One serious question today would be: what's LISP _really_ good for?
>>
>> http://www.paulgraham.com/avg.html
>
> I could do a similar thing:
>
> 
>
> ... and leave you wondering (or not). I won't.
>

Oh, yay, a Xah Lee quote, he's surely a trusted source on all things
Lisp. Didja read his page about hiring a prostitute in Las Vegas? Or
the one about how he lives in a car in the Bay Area because he's too
crazy to get hired?


John
-- 
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] nice quote

[Eris Discordia]

One serious question today would be: what's LISP _really_ good for?


http://www.paulgraham.com/avg.html


I could do a similar thing:



... and leave you wondering (or not). I won't.

Paul Graham's essay/article consists of a success story, _his_ success 
story (which, in minor part, depends on continued sales of his two LISP 
books), and a variety of claims I am unqualified to verify or refute. What 
is there for me to learn? That there exists/existed one successful LISP 
application? Is that really what I had tried to negate?


Besides, if quoting ESR were a measure of credibility I'd be given some 
when I appeared to 9fans out of the blue and quoted him saying something to 
the effect that Plan 9 is dead and buried because it wasn't up to replacing 
UNIX (at the moment, that is _not_ my opinion).




--On Saturday, September 05, 2009 12:02 +0100 Richard Miller 
<9f...@hamnavoe.com> wrote:



One serious question today would be: what's LISP _really_ good for?


http://www.paulgraham.com/avg.html

Re: [9fans] nice quote

[Eris Discordia]

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




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:






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 

Re: [9fans] nice quote

[Anthony Sorace]

Akshat said:

// Considering that Plan 9 has only two inherent languages...

I'm curious which two you meant. Most of the code running on my Plan 9
installations is written in either C or rc. For code I've written running on it,
Limbo is about as high. And of course there's a little assembly down deep.
And a bunch of awk and mk, obviously. And acid is invaluable for the set
of tasks for which it was designed.

I also don't really know what "inherent" means. "Thing which generates
machine code directly"? Or maybe "compiler/interpreter included in the
distribution"? That's closest, I guess.

// ...and its users often push for work to be done in only those...

Simply disagree. Good Unix (and, here, by extension) Plan 9 folks tend to
be fond of "little languages" - they coined the term, after all. I think in that
sense, I'd be very surprised to find many Plan 9 folks argue against using
the right tool (language) for the job.

What I think you might be thinking of is that Plan 9 folks are a little more
conservative in their selection of languages. You're not likely to see much
perl here, because overall people aren't really convinced it offers anything
over awk, maybe awk+rc. You're not likely to see much sh because we've
got rc. Just because a tool exists doesn't mean it's the right tool for
anything.

This has its costs, mainly in application support. We might not like C++
because we don't see much advantage over C, and we might be right, but
that doesn't change the fact that we've now got a higher barrier between
us and application authors that made a different decision. That's often a
good thing (less crap), but it does hurt us in places, too.

Re: [9fans] nice quote

[tlaronde]

On Sat, Sep 05, 2009 at 07:22:37AM -0400, Akshat Kumar wrote:
>   "Programming languages are just tools, after all."
> 
> Considering that Plan 9 has only two inherent languages,
> and its users often push for work to be done in only those,
> what is the Plan 9 perspective of languages and tools in
> relation to each other?

I don't know for "the Plan 9 perspective" and have no authority to talk
"for Plan 9", but since almost all interpreters or compilers are written
in C, whether completely or the bootstapping procedure (a C core that is
able to interpret a subset of the language to generate a binary for the
non optimized version of a complete compiler etc.), there are all the
tools as long as there is a C compiler for the machine.

The remaining is, IMHO, user stuff: one has all tools needed to
customize.

The only "lack" in C is perhaps defined full control for
arithmetic/calculus. That's probably why FORTRAN is still here and has
still its strength in this area.

Just my 2 centimes, 
-- 
Thierry Laronde (Alceste) 
 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] nice quote

[Akshat Kumar]

> http://www.paulgraham.com/avg.html
  "Programming languages are just tools, after all."

Considering that Plan 9 has only two inherent languages,
and its users often push for work to be done in only those,
what is the Plan 9 perspective of languages and tools in
relation to each other?
Is it in agreement with this statement?


ak

Re: [9fans] nice quote

[Richard Miller]

>> One serious question today would be: what's LISP _really_ good for?

http://www.paulgraham.com/avg.html