[9fans] nice quote

[9fans] nice quote

[ron minnich]

Q: "Will C continue to be important into the future?"
(Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"

ron

Re: [9fans] nice quote

[Rodolfo (kix)]

I believe OS/2 is destined to be the most important operating system,
and possibly program, of all time.
(Bill Gates, OS/2 Programmers Guide, November 1987)

... we are all human ...

:-)

On Wed, Sep 2, 2009 at 4:29 PM, ron minnich<rminnich@gmail.com> wrote:
> Q: "Will C continue to be important into the future?"
> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>
> ron
>
>



-- 
Rodolfo García "kix"
EA4ERH - IN80ER

Re: [9fans] nice quote

[Enrique Soriano]

> (Dave Kirk, Nvidia) A: "No, I think C will die like Fortran has"

http://developer.nvidia.com/page/cg_main.html

Re: [9fans] nice quote

[erik quanstrom]

On Wed Sep  2 10:33:07 EDT 2009, rminnich@gmail.com wrote:
> Q: "Will C continue to be important into the future?"
> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"

isn't this the same company that claims that the cpu is dead?
it may be true, but given nvidia's propensity to make
claims that stretch credulity a wee bit that all just so happen
to lead one to the conclusion — that nvidia will dominate the
computer world in the near future with massive gpus, directx,
and a tiny cpu.

- erik

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Wed, Sep 2, 2009 at 9:38 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Wed Sep  2 10:33:07 EDT 2009, rminnich@gmail.com wrote:
> > Q: "Will C continue to be important into the future?"
> > (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>
> isn't this the same company that claims that the cpu is dead?
> it may be true, but given nvidia's propensity to make
> claims that stretch credulity a wee bit that all just so happen
> to lead one to the conclusion — that nvidia will dominate the
> computer world in the near future with massive gpus, directx,
> and a tiny cpu.
>

I know people claiming the GPU is dead.  (The folks who make the Unreal
gaming engine to start).


>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1269 bytes --]

Re: [9fans] nice quote

[Robert Raschke]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Wed, Sep 2, 2009 at 5:38 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Wed Sep  2 10:33:07 EDT 2009, rminnich@gmail.com wrote:
> > Q: "Will C continue to be important into the future?"
> > (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>
> isn't this the same company that claims that the cpu is dead?
> it may be true, but given nvidia's propensity to make
> claims that stretch credulity a wee bit that all just so happen
> to lead one to the conclusion — that nvidia will dominate the
> computer world in the near future with massive gpus, directx,
> and a tiny cpu.
>
> - erik
>
>
Gamers have a lot to answer for. Not just social decline ... ;-)

Robby

[-- Attachment #2: Type: text/html, Size: 1123 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Wed, Sep 2, 2009 at 9:58 AM, Robert Raschke <rtrlists@googlemail.com>wrote:

> On Wed, Sep 2, 2009 at 5:38 PM, erik quanstrom <quanstro@quanstro.net>wrote:
>
>> On Wed Sep  2 10:33:07 EDT 2009, rminnich@gmail.com wrote:
>> > Q: "Will C continue to be important into the future?"
>> > (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>>
>> isn't this the same company that claims that the cpu is dead?
>> it may be true, but given nvidia's propensity to make
>> claims that stretch credulity a wee bit that all just so happen
>> to lead one to the conclusion — that nvidia will dominate the
>> computer world in the near future with massive gpus, directx,
>> and a tiny cpu.
>>
>> - erik
>>
>>
> Gamers have a lot to answer for. Not just social decline ... ;-)
>
> Robby
>

Found the reference:

http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

Re: [9fans] nice quote

[Eric Van Hensbergen]

Clarifying context: this was at a hpc clusters conference -- their
view of fortran is not your view of fortran.

Sent from my iPhone

On Sep 2, 2009, at 9:29 AM, ron minnich <rminnich@gmail.com> wrote:

> Q: "Will C continue to be important into the future?"
> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>
> ron
>

Re: [9fans] nice quote

[erik quanstrom]

> Found the reference:
>
> http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

on p. 43/44 i believe it is claimed that one
cannot do CSP without pure functional
programming.

the thread library is clearly better than i thought.
it can turn ordinary c into a functional programming
language!  ☺

- erik

Re: [9fans] nice quote

[Richard Miller]

>> http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
>>
> on p. 43/44 i believe it is claimed that one
> cannot do CSP without pure functional
> programming.

(p ⇒ q) ⇏ (¬p ⇒ ¬q)

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Wed, Sep 2, 2009 at 10:31 AM, Eric Van Hensbergen <ericvh@gmail.com>wrote:

> Clarifying context: this was at a hpc clusters conference -- their view of
> fortran is not your view of fortran.
>
> Having supported Fortran for MPI implementations before, I know what you
mean :-)


> Sent from my iPhone
>
> On Sep 2, 2009, at 9:29 AM, ron minnich <rminnich@gmail.com> wrote:
>
>  Q: "Will C continue to be important into the future?"
>> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>>
>> ron
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1167 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller <9fans@hamnavoe.com> wrote:

> >> http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
> >>
> > on p. 43/44 i believe it is claimed that one
> > cannot do CSP without pure functional
> > programming.
>
> (p ⇒ q) ⇏ (¬p ⇒ ¬q)
>
>
That's interesting because pure functional programming doesn't exist at all
in the strictest sense on a computer.  One MUST be able to cause side
effects during computation or your CPU will just get hot... if even that.

Dave

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [9fans] nice quote

[erik quanstrom]

> > > on p. 43/44 i believe it is claimed that one
> > > cannot do CSP without pure functional
> > > programming.
> >
> > (p ⇒ q) ⇏ (¬p ⇒ ¬q)
> >
> >
> That's interesting because pure functional programming doesn't exist at all
> in the strictest sense on a computer.  One MUST be able to cause side
> effects during computation or your CPU will just get hot... if even that.

i read the slides as contrasts, not as
logical conjunctions.

i still don't understand the claim that message passing
requires "thousands of message protocols"
and can't do syncronization.

- erik

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

On Wed, Sep 2, 2009 at 11:35 AM, erik quanstrom <quanstro@coraid.com> wrote:

> > > > on p. 43/44 i believe it is claimed that one
> > > > cannot do CSP without pure functional
> > > > programming.
> > >
> > > (p ⇒ q) ⇏ (¬p ⇒ ¬q)
> > >
> > >
> > That's interesting because pure functional programming doesn't exist at
> all
> > in the strictest sense on a computer.  One MUST be able to cause side
> > effects during computation or your CPU will just get hot... if even that.
>
> i read the slides as contrasts, not as
> logical conjunctions.
>
> i still don't understand the claim that message passing
> requires "thousands of message protocols"
> and can't do syncronization.
>
>
I also don't get that. What was meant by his usage of "protocol".  Erlang
uses only a handful of patterns that work really well for interaction in
each subsystem.  If they think of messaging and protocols in a smalltalky
way, then each class has a protocol of messages (methods) that must be
implemented, but I don't get why that's bad.  It's called an API.

I mean HTTP has a small protocol, but if you count all the things you can do
with REST, then it looks like a lot more.

Dave


> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1860 bytes --]

Re: [9fans] nice quote

[ron minnich]

On Wed, Sep 2, 2009 at 7:29 AM, ron minnich<rminnich@gmail.com> wrote:
> Q: "Will C continue to be important into the future?"
> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"

let me explain the joke. In HPC circles, people have been predicting
the death of fortran for 30 years. Fortran has continued to grow and
thrive. The predictions continue, but the latest fortran standard
includes objects.

So, what Dave is saying, tongue in cheek, is that C will die in the
way fortran has -- i.e., not at all.

ron

Re: [9fans] nice quote

[Jonathan Cast]

On Wed, 2009-09-02 at 11:27 -0700, David Leimbach wrote:
> On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller <9fans@hamnavoe.com>
> wrote:
>         >>
>         http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
>         >>
>         > on p. 43/44 i believe it is claimed that one
>         > cannot do CSP without pure functional
>         > programming.

>         (p ⇒ q) ⇏ (¬p ⇒ ¬q)


> That's interesting because pure functional programming doesn't exist
> at all in the strictest sense on a computer.  One MUST be able to
> cause side effects during computation or your CPU will just get hot...
> if even that.

*delurk*

That's an excessively strict view.  You need *output* for a program to
be useful, but producing that output doesn't need to be intermixed with
the program's algorithm to be useful; you can compute first, then output
the results.

Furthermore, I don't think it's sophistry to say that you don't need
side effects to do output.  ALGOL-derived languages use side effects for
output, because (to take C as an example) the type of an expression like

    print("Hello, world\n")

is taken to be `int', and thus the `value' of that expression must be
some integer --- say, 13.  Then you need to add a concept of `side
effects' to express the fact that there's more going on here than just
calculating the number 13.

Purely functional programming doesn't eschew I/O (although it encourages
a style that separates I/O from algorithms --- as does good programming
style in any language); rather, it re-works the types of the I/O
operations so that, if you have a function

    foo :: String -> Int

the value of

    foo "Hello, world!\n"

really is just an integer (and there's nothing else going on to
introduce side-effects to talk about).  Whereas if you have a function

    bar :: String -> IO Int

then the value (as expressed in the language and understood by the
programmer) of

    bar "Hello, world!\n"

is a combination of I/O behavior, concurrency, etc.  So you don't need
to introduce a concept of `side effects' to talk about those things.

If you were building a denotational semantics for C, this how you would
deal with I/O.  The value (denotation) of a C expression of type int
would be a combination of I/O behavior, assignment behavior, etc., as
well as (possibly, due to the possibility of non-termination) an
integer.  Purely functional programming just reduces the degree of
difference between the denotational semantics of the language and the
programmer's mental model of it.

Which is very likely all I have to say on the subject.

jcc

Re: [9fans] nice quote

[Brian L. Stuart]

> > Q: "Will C continue to be important into the future?"
> > (Dave Kirk, Nvidia)A: "No, I think C will die like
> Fortran has"
>
> let me explain the joke. In HPC circles, people have been
> predicting
> the death of fortran for 30 years. Fortran has continued to
> grow and
> thrive. The predictions continue, but the latest fortran
> standard
> includes objects.
>
> So, what Dave is saying, tongue in cheek, is that C will
> die in the
> way fortran has -- i.e., not at all.

I just hope standards committees don't "enhance" C into
Frankenstein's monster.

That reminds me of another amusing story.  It seems that
back in the 70s or 80s someone asked some big name in CS
what people would be programming with in the year 2000.
His response: "I don't know, but it'll be called FORTRAN."

This isn't your father's FORTRAN...

BLS

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Wed, Sep 2, 2009 at 12:11 PM, Brian L. Stuart <blstuart@bellsouth.net>wrote:

> > > Q: "Will C continue to be important into the future?"
> > > (Dave Kirk, Nvidia)A: "No, I think C will die like
> > Fortran has"
> >
> > let me explain the joke. In HPC circles, people have been
> > predicting
> > the death of fortran for 30 years. Fortran has continued to
> > grow and
> > thrive. The predictions continue, but the latest fortran
> > standard
> > includes objects.
> >
> > So, what Dave is saying, tongue in cheek, is that C will
> > die in the
> > way fortran has -- i.e., not at all.
>
> I just hope standards committees don't "enhance" C into
> Frankenstein's monster.
>
>
I actually think they might enhance C in this way in the ISO standard one
day.  The only nice bit is this is like C + a taped on block "thingy".  You
don't have to use it, and your other C is not affected by this change. (I
think)

It's not like they're changing the semantics of the ; or anything. (or did
they?)

[-- Attachment #2: Type: text/html, Size: 1480 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Wed, Sep 2, 2009 at 12:10 PM, Jonathan Cast <jonathanccast@fastmail.fm>wrote:

> On Wed, 2009-09-02 at 11:27 -0700, David Leimbach wrote:
> > On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller <9fans@hamnavoe.com>
> > wrote:
> >         >>
> >
> http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
> >         >>
> >         > on p. 43/44 i believe it is claimed that one
> >         > cannot do CSP without pure functional
> >         > programming.
>
> >         (p ⇒ q) ⇏ (¬p ⇒ ¬q)
>
>
> > That's interesting because pure functional programming doesn't exist
> > at all in the strictest sense on a computer.  One MUST be able to
> > cause side effects during computation or your CPU will just get hot...
> > if even that.
>
> *delurk*
>
> That's an excessively strict view.  You need *output* for a program to
> be useful, but producing that output doesn't need to be intermixed with
> the program's algorithm to be useful; you can compute first, then output
> the results.
>

Compute what first?  You compute input, to produce output.  You have no
choice really.  In haskell the entry point is

main :: IO ().

I rest my case.

Note that I didn't say  "some code can't be pure", that's for the most part
false (some would argue that even floating point math must be done in an
impure way because one can set up the representation of floats differently,
and that changes the purity of what would have been a pure function).  Some
code certainly can be executed in a pure sense, but at some point those
values came in via a very dirty input process.

The best part about Haskell is you can know by a functions type that no
impure actions took place in a subset of your code.  This does not falsify
my claim that even pure functional programming languages require impure
code.

And if you prefer a plea to authority over logic, I haven't said anything
that Simon Peyton Jones hasn't himself said about Haskell.

Dave

[-- Attachment #2: Type: text/html, Size: 2754 bytes --]

Re: [9fans] nice quote

[Jonathan Cast]

On Wed, 2009-09-02 at 13:02 -0700, David Leimbach wrote:


> And if you prefer a plea to authority over logic, I haven't said
> anything that Simon Peyton Jones hasn't himself said about Haskell.

Well, I disagree quite strongly about Simon Peyton Jones about a number
of things.  Which I think I indicated by contradicting his stated
positions on several of those points in my original post.

My original message still stands as a reply to the rest of your post, so
I won't repeat it.

jcc

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Wed, Sep 2, 2009 at 1:23 PM, Jonathan Cast <jonathanccast@fastmail.fm>wrote:

> On Wed, 2009-09-02 at 13:02 -0700, David Leimbach wrote:
>
>
> > And if you prefer a plea to authority over logic, I haven't said
> > anything that Simon Peyton Jones hasn't himself said about Haskell.
>
> Well, I disagree quite strongly about Simon Peyton Jones about a number
> of things.  Which I think I indicated by contradicting his stated
> positions on several of those points in my original post.
>
> My original message still stands as a reply to the rest of your post, so
> I won't repeat it.
>
>
Fair enough! :-)


> jcc
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1112 bytes --]

Re: [9fans] nice quote

[Roman V Shaposhnik]

On Wed, 2009-09-02 at 12:11 -0700, Brian L. Stuart wrote:
> > > Q: "Will C continue to be important into the future?"
> > > (Dave Kirk, Nvidia)A: "No, I think C will die like
> > Fortran has"
> >
> > let me explain the joke. In HPC circles, people have been
> > predicting
> > the death of fortran for 30 years. Fortran has continued to
> > grow and
> > thrive. The predictions continue, but the latest fortran
> > standard
> > includes objects.
> >
> > So, what Dave is saying, tongue in cheek, is that C will
> > die in the
> > way fortran has -- i.e., not at all.
>
> I just hope standards committees don't "enhance" C into
> Frankenstein's monster.

A friend of mine, who is still serving on the C committee, once
mentioned who lucky they were to have C++ around as a perfect
dumping ground for all the "cool" enhancements that got proposed
along the way.

Thanks,
Roman.

P.S. Another friend of mine still feels sad that Fortress didn't
become that same sort of dumping ground for Fortran ;-)

Re: [9fans] nice quote

[Greg Comeau]

In article <3096bd910909020751o12086713m4291e2f1b77daf8f@mail.gmail.com>,
Rodolfo kix <kix@kix.es> wrote:
>On Wed, Sep 2, 2009 at 4:29 PM, ron minnich<rminnich@gmail.com> wrote:
>> Q: "Will C continue to be important into the future?"
>> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
>
>I believe OS/2 is destined to be the most important operating system,
>and possibly program, of all time.
>(Bill Gates, OS/2 Programmers Guide, November 1987)
>
>... we are all human ...
>
>:-)

When push comes the shove, these are probably both said in the
same spirit (I doubt Kirk feels C will die, nor Gates that
OS/2 was such (nor that MS products have no bugs))....
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <1251932394.16936.3741.camel@work.SFBay.Sun.COM>,
Roman V Shaposhnik <rvs@sun.com> wrote:
>On Wed, 2009-09-02 at 12:11 -0700, Brian L. Stuart wrote:
>> > > Q: "Will C continue to be important into the future?"
>> > > (Dave Kirk, Nvidia)A: "No, I think C will die like
>> > Fortran has"
>> >
>> > let me explain the joke. In HPC circles, people have been
>> > predicting
>> > the death of fortran for 30 years. Fortran has continued to
>> > grow and
>> > thrive. The predictions continue, but the latest fortran
>> > standard
>> > includes objects.
>> >
>> > So, what Dave is saying, tongue in cheek, is that C will
>> > die in the
>> > way fortran has -- i.e., not at all.
>>
>> I just hope standards committees don't "enhance" C into
>> Frankenstein's monster.
>
>A friend of mine, who is still serving on the C committee, once
>mentioned who lucky they were to have C++ around as a perfect
>dumping ground for all the "cool" enhancements that got proposed
>along the way.
>
>Thanks,
>Roman.
>
>P.S. Another friend of mine still feels sad that Fortress didn't
>become that same sort of dumping ground for Fortran ;-)

Well, this is probably not a good time to mentioned that lambdas
and closures have been well discussed by the C++ committe with
lots of draft wording for them in a forthcmoing C++ standard.
That then may or may not mean the "dump" will make its was back to C.
Coming full circle, if it does, it means, Apple's block stuff
will not be compatible, at least not syntactically (at least
not what I recall of if -- have not look at it for a while).
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Skip Tavakkolian]

> When push comes the shove, these are probably both said in the
> same spirit (I doubt Kirk feels C will die, nor Gates that
> OS/2 was such (nor that MS products have no bugs))....

what spirit is that?  the one that says "i'm a rational person but
will say irrational things if it helps me sell my wares"?

Re: [9fans] nice quote

[Skip Tavakkolian]

> Well, this is probably not a good time to mentioned that lambdas
> and closures have been well discussed by the C++ committe with
> lots of draft wording for them in a forthcmoing C++ standard.

i think by now most of us expect new ornamentation added to C++
periodically.  it is surprising that this is being considered seriously
for C.

Re: [9fans] nice quote

[tlaronde]

On Thu, Sep 03, 2009 at 04:24:50AM -0700, Skip Tavakkolian wrote:
>
> i think by now most of us expect new ornamentation added to C++
> periodically.  it is surprising that this is being considered seriously
> for C.
>

I'd like to say that my distate for C++ is purely technical, but to be
honest, I'm not quite sure.

I have the principle that, since a programming language aims to express
clearly what you want to be done, if the author doesn't explane clearly
his language, there is a problem.

K&R is beautiful in this respect. In contrast, I never managed to
bite in Stroustrup's description.

But the whole story is that, during my childhood, there was the
Muppet's. And a character was a swedish cook, whose name was almost
impossible to pronounce, whose recipes were not understandable, and
whose results were not engaging.

And I fear that, behind the conscious, this has played a role...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] nice quote

[Brantley Coile]

If the language can't be explained in 50 pages, it's no good.

On Sep 3, 2009, at 5:01 AM, tlaronde@polynum.com wrote:

> On Thu, Sep 03, 2009 at 04:24:50AM -0700, Skip Tavakkolian wrote:
>>
>> i think by now most of us expect new ornamentation added to C++
>> periodically.  it is surprising that this is being considered
>> seriously
>> for C.
>>
>
> I'd like to say that my distate for C++ is purely technical, but to be
> honest, I'm not quite sure.
>
> I have the principle that, since a programming language aims to
> express
> clearly what you want to be done, if the author doesn't explane
> clearly
> his language, there is a problem.
>
> K&R is beautiful in this respect. In contrast, I never managed to
> bite in Stroustrup's description.
>
> But the whole story is that, during my childhood, there was the
> Muppet's. And a character was a swedish cook, whose name was almost
> impossible to pronounce, whose recipes were not understandable, and
> whose results were not engaging.
>
> And I fear that, behind the conscious, this has played a role...
> --
> Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
>                 http://www.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
>

Re: [9fans] nice quote

[Greg Comeau]

In article <ab7093364284b1abf9201ff33cdfd97c@9netics.com>,
Skip Tavakkolian <9nut@9netics.com> wrote:
>> When push comes the shove, these are probably both said in the
>> same spirit (I doubt Kirk feels C will die, nor Gates that
>> OS/2 was such (nor that MS products have no bugs))....
>
>what spirit is that?  the one that says "i'm a rational person but
>will say irrational things if it helps me sell my wares"?

That seems to be one valid interpretation :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <20090903120157.GA1649@polynum.com>,  <tlaronde@polynum.com> wrote:
>On Thu, Sep 03, 2009 at 04:24:50AM -0700, Skip Tavakkolian wrote:
>> i think by now most of us expect new ornamentation added to C++
>> periodically.  it is surprising that this is being considered seriously
>> for C.
>
>I'd like to say that my distate for C++ is purely technical, but to be
>honest, I'm not quite sure.
>
>I have the principle that, since a programming language aims to express
>clearly what you want to be done, if the author doesn't explane clearly
>his language, there is a problem.
>
>K&R is beautiful in this respect. In contrast, I never managed to
>bite in Stroustrup's description.

Ok, now I'll get provocative:
Then why do so many people have a problem understanding C?
Please don't seriously say they don't.  In fact, these same
arguments are used against C by those who don't care for C.
Go figure?  I think not.

>But the whole story is that, during my childhood, there was the
>Muppet's. And a character was a swedish cook, whose name was almost
>impossible to pronounce, whose recipes were not understandable, and
>whose results were not engaging.
>
>And I fear that, behind the conscious, this has played a role...

That's good, because he's from Denmark :)  Let's drop this part of things...
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <A879919A-6E6F-4425-A971-62946A07E666@coraid.com>,
Brantley Coile <brantley@coraid.com> wrote:
>If the language can't be explained in 50 pages, it's no good.

Well, that rules out C too then! :)  (not even considering the library parts)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Robert Raschke]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Thu, Sep 3, 2009 at 3:02 PM, Greg Comeau <comeau@panix.com> wrote:

> Ok, now I'll get provocative:
> Then why do so many people have a problem understanding C?
> Please don't seriously say they don't.  In fact, these same
> arguments are used against C by those who don't care for C.
> Go figure?  I think not.
>
>
I guess you gotta actually say what particular group of the population you
are taking your "many people" out of. Programmers? People who work with
computers? Artists? Europeans?

I'll assume you mean active programmers. Many of those will have a problem
understanding assembly code. Funnily enough many more than those not
understanding C will have a problem understanding high level programming
languages like R, Haskell, or even Smalltalk.

What were we talking about again ...

Robby

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

On Thu, Sep 3, 2009 at 2:52 AM, Greg Comeau <comeau@panix.com> wrote:

> In article <3096bd910909020751o12086713m4291e2f1b77daf8f@mail.gmail.com>,
> Rodolfo kix <kix@kix.es> wrote:
> >On Wed, Sep 2, 2009 at 4:29 PM, ron minnich<rminnich@gmail.com> wrote:
> >> Q: "Will C continue to be important into the future?"
> >> (Dave Kirk, Nvidia)A: "No, I think C will die like Fortran has"
> >
> >I believe OS/2 is destined to be the most important operating system,
> >and possibly program, of all time.
> >(Bill Gates, OS/2 Programmers Guide, November 1987)
> >
> >... we are all human ...
> >
> >:-)
>
> When push comes the shove, these are probably both said in the
> same spirit (I doubt Kirk feels C will die, nor Gates that
> OS/2 was such (nor that MS products have no bugs))....
>

If I recall correctly, conspiracy theorists might even claim that Microsoft
was singing the praises of OS/2 while simultaneously putting more effort
into NT.  Note that Microsoft was working on OS/2 for IBM at the time, and
probably consciously chose to make NT win that battle.

I'm not saying that's what happened, I'm saying others *have* said so.


> --
> Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
> Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
>
>

[-- Attachment #2: Type: text/html, Size: 2232 bytes --]

Re: [9fans] nice quote

[Uriel]

On Wed, Sep 2, 2009 at 8:46 PM, David Leimbach<leimy2k@gmail.com> wrote:
> I mean HTTP has a small protocol, but if you count all the things you can do
> with REST, then it looks like a lot more.

HTTP might be many things, small is not one of them. That said, your
overall point is correct.

Peace

uriel

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Thu, Sep 3, 2009 at 8:02 AM, Uriel <uriel99@gmail.com> wrote:

> On Wed, Sep 2, 2009 at 8:46 PM, David Leimbach<leimy2k@gmail.com> wrote:
> > I mean HTTP has a small protocol, but if you count all the things you can
> do
> > with REST, then it looks like a lot more.
>
> HTTP might be many things, small is not one of them. That said, your
> overall point is correct.
>

Well I meant small compared to all the APIs you can call with REST through
it :-)


>
> Peace
>
> uriel
>
>

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

Re: [9fans] nice quote

[Jason Catena]

> If the language can't be explained in 50 pages, it's no good.

If it's not possible to clearly describe the core of a computer
programming language in fifty pages, then it has probably been
embellished with features, unnecessary to the language proper, to help
it compete in the lame one-size-fits-all strand of programming
language debate.  In this respect Perl is a cautionary example, having
no coherent core that I could tell, just a cobbled-together collection
of features intended to try to replace single purpose programs. (But
then again, "those days are dead and gone and the eulogy was delivered
by Perl.")

Jason Catena

Re: [9fans] nice quote

[Brian L. Stuart]

> >K&R is beautiful in this respect. In contrast, I
> never managed to
> >bite in Stroustrup's description.
>
> Ok, now I'll get provocative:
> Then why do so many people have a problem understanding C?

Are you saying that there is a significant number of
people who understand C++ but not C?  The reason I
ask is that it's exactly the other way around for me.
C is a simple enough language that I can understand
it in the sense of knowing what the compiler is doing
with my code.  With C++, I have a much harder time
keeping my head around what's being done with the
code, and that makes it much harder for me to understand
the code, much less the language.

BLS

Re: [9fans] nice quote

[tlaronde]

On Thu, Sep 03, 2009 at 02:02:53PM +0000, Greg Comeau wrote:
> In article <20090903120157.GA1649@polynum.com>,  <tlaronde@polynum.com> wrote:
> >I have the principle that, since a programming language aims to express
> >clearly what you want to be done, if the author doesn't explane clearly
> >his language, there is a problem.
> >
> >K&R is beautiful in this respect. In contrast, I never managed to
> >bite in Stroustrup's description.
>
> Ok, now I'll get provocative:
> Then why do so many people have a problem understanding C?

Whether because there are too many people doing programming when they should
not (including me). Or because they are trying to learn C from another
book than K&R's.

C shall be the test. If you don't even understand C, explained by K&R,
then do something else.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] nice quote

[Daniel Lyons]

On Sep 3, 2009, at 1:38 PM, tlaronde@polynum.com wrote:

> C shall be the test. If you don't even understand C, explained by K&R,
> then do something else.


I'm glad this attitude exists, particularly here in the Plan 9  
community, where it belongs. But I don't agree. There are many  
languages because there are many ways of thinking about programming.  
Most people don't get introduced to the right one on the first try.  
Obviously C programmers have unique talents, but I prefer to think the  
world has a shortage of good programmers, not a glut of bad ones. Few  
got to excellence by birth alone.

—
Daniel Lyons

Re: [9fans] nice quote

[Tharaneedharan Vilwanathan]

> C shall be the test. If you don't even understand C, explained by K&R,
> then do something else.
i agree to this completely. after taking a formal course in computers,
if someone cannot read/follow K&R C book and cannot write C code, i
would think that the candidate is not good enough.

thanks
dharani

Re: [9fans] nice quote

[Greg Comeau]

In article <561059.20730.qm@web83913.mail.sp1.yahoo.com>,
Brian L. Stuart <blstuart@bellsouth.net> wrote:
>> >K&R is beautiful in this respect. In contrast, I
>> never managed to
>> >bite in Stroustrup's description.
>>
>> Ok, now I'll get provocative:
>> Then why do so many people have a problem understanding C?
>
>Are you saying that there is a significant number of
>people who understand C++ but not C?  The reason I
>ask is that it's exactly the other way around for me.
>C is a simple enough language that I can understand
>it in the sense of knowing what the compiler is doing
>with my code.  With C++, I have a much harder time
>keeping my head around what's being done with the
>code, and that makes it much harder for me to understand
>the code, much less the language.

I wasn't saying anything, I was asking a question. :)
But if I were to say something, it would include all you
just said and more.  Focusing slightly, most people do have
a problem understanding/using/whatevering C including from
a high level and low level perspective.  Even more focusing,
most people don't know what the compiler is doing with their C
code, even though say C++ usually gets the short end of the
stick on this one (deservingly so, but C ain't 0&, far from
it IMO).
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <6a3ae47e0909030757n31a8d09aoa2b2d57628a5a2c9@mail.gmail.com>,
Robert Raschke <rtrlists@googlemail.com> wrote:
>On Thu, Sep 3, 2009 at 3:02 PM, Greg Comeau <comeau@panix.com> wrote:
>> Ok, now I'll get provocative:
>> Then why do so many people have a problem understanding C?
>> Please don't seriously say they don't.  In fact, these same
>> arguments are used against C by those who don't care for C.
>> Go figure?  I think not.
>I guess you gotta actually say what particular group of the population you
>are taking your "many people" out of. Programmers? People who work with
>computers? Artists? Europeans?
>
>I'll assume you mean active programmers.

Right, not the general population, but programmers, or, at lest
those claiming to be said.

>Many of those will have a problem
>understanding assembly code. Funnily enough many more than those not
>understanding C will have a problem understanding high level programming
>languages like R, Haskell, or even Smalltalk.

Probably so.

>What were we talking about again ...

Something about C being beautifully explained, or something like that.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <d50d7d460909030813u703c1292i6ae7cf10a767f58d@mail.gmail.com>,
Jason Catena <jason.catena@gmail.com> wrote:
>> If the language can't be explained in 50 pages, it's no good.
>
>If it's not possible to clearly describe the core of a computer
>programming language in fifty pages, then it has probably been
>embellished with features, unnecessary to the language proper, to help
>it compete in the lame one-size-fits-all strand of programming
>language debate.

As mentioned, then, that includes C too.  For that matter,
a whole pack of stuff.  So, I can't imagine that's really
the point being brought forth.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <20090903193814.GA1275@polynum.com>,  <tlaronde@polynum.com> wrote:
>On Thu, Sep 03, 2009 at 02:02:53PM +0000, Greg Comeau wrote:
>> In article <20090903120157.GA1649@polynum.com>,  <tlaronde@polynum.com> wrote:
>> >I have the principle that, since a programming language aims to express
>> >clearly what you want to be done, if the author doesn't explane clearly
>> >his language, there is a problem.
>> >
>> >K&R is beautiful in this respect. In contrast, I never managed to
>> >bite in Stroustrup's description.
>>
>> Ok, now I'll get provocative:
>> Then why do so many people have a problem understanding C?
>
>Whether because there are too many people doing programming when they should
>not (including me). Or because they are trying to learn C from another
>book than K&R's.
>
>C shall be the test. If you don't even understand C, explained by K&R,
>then do something else.

Personally, so IMO, from a few perspectives, I have found that to
categorically false.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Brian L. Stuart]

> >> >K&R is beautiful in this respect. In
> contrast, I
> >> never managed to
> >> >bite in Stroustrup's description.
> >> 
> >> Ok, now I'll get provocative:
> >> Then why do so many people have a problem
> understanding C?
> >
> >Are you saying that there is a significant number of
> >people who understand C++ but not C?  The reason
>
> I wasn't saying anything, I was asking a question. :)

Ah, I misunderstood.  The question about why people don't
understand C on the heels of a reference to Stroustrup
led me to think that was a suggestion C++ was easier to
understand than C.  Of course, I may be a little too
sensitive to such a claim, because of what I've been
hearing in the academic community for a while.  Some
keep saying that we should use more complex languages
in the introductory course because they're in some way
easier.  But I've yet to understand their definition
of easier.*

BLS

*Well, actually I do kind of realize they are suggesting
that a tinkertoy approach makes it easier for a beginner
to see something happen.  The problem I have is that's
not the point of teaching that material.  Just getting
something to happen might be training, but it sure isn't
education.

Re: [9fans] nice quote

[Jack Norton]

Brian L. Stuart wrote:
> Just getting something to happen might be training, but it sure isn't
> education.
>
Thats the best one-liner I have ever heard on the subject.

-Jack

Re: [9fans] nice quote

[Eris Discordia]

Caveat: please add IMH(UI)O in front of any assertion that comes below.

Since education was brought up: I remember I found it seriously twisted 
when I was told mathematics freshmen in a top-notch university not 
(geographically) far from me are taught not one but two courses in computer 
programming... in Java.

Being the hobbyist (as contrasted to the professional) here, and the one 
who's got the smaller cut out of the intelligence cake, I think I am sure C 
was a lot easier to learn and comprehend than either Pascal--all the kids 
were into "Pascal or C? That's the problem" back then--or C++ or even the 
mess of a language called GW-BASIC (which I learnt as a kid and before I 
knew C, too, could be learnt by kids). Even if Pascal got all the buzz 
about being a "teaching language."

What seems to distinguish--pedagogically, at least--C is, as I noted on 
that other thread, its closeness to how the small computer, not the actual 
small computer but the mental model of a small computer, works. Pointers? 
They're just references to "pigeonholes" in a row of such holes. Scope? 
It's just how long your variables are remembered. Invocation? Just a way to 
regurgitate your own cooking. If one has to solve a problem, implement an 
algorithm, on a small computer one needs to be able to explain it in terms 
of the primitives available on that computer. That's where C shines. 
There's a close connection between language primitives and the primitives 
of the underlying computer. I'm not saying this is something magically 
featuring in C--it's a property that _had_ to feature in some language some 
time, C became that. In a different time and place, on different machines, 
another language would/will be that (and it shall be called C ;-))

I whined about LISP on yet another thread. Above says precisely why I did. 
LISP is twofold hurtful for me as a naive, below average hobbyist. For one 
thing the language constructs do not reflect the small computer primitives 
I was taught somewhere around the beginning of my education. 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. Its claim to fame as the language 
for "wizards" remains. 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.

A favorite quote out of my favorite physics textbook:

> Further progress lies in the direction of making our equations invariant
> under wider and still wider transformations. This state of affairs is
> very satisfactory from a philosophical point of view, as implying an
> increasing recognition of the part played by the observer in himself
> introducing the regularities that appear in his observations, and a lack
> of arbitrariness in the ways of nature, but it makes things less easy for
> the learner of physics.

-- P. A. M. Dirac, The Principles of Quantum Mechanics

Unlike physical phenomena languages (natural or artificial) are subject to 
constraints that act (in comparison) very slowly and very leniently. 
There's a great deal of arbitrariness in how a computer language might 
look. It is epistemologically, aesthetically, and pragmatically 
advantageous to "remove arbitrariness" by fitting a language to either its 
target platform or its target problem, preferably both. C did and continues 
to do so, LISP doesn't (not anymore, to say the least).


P.S. UI stands for "uninformed."

--On Friday, September 04, 2009 10:47 -0700 "Brian L. Stuart" 
<blstuart@bellsouth.net> wrote:

>> >> > K&R is beautiful in this respect. In
>> contrast, I
>> >> never managed to
>> >> > bite in Stroustrup's description.
>> >>
>> >> Ok, now I'll get provocative:
>> >> Then why do so many people have a problem
>> understanding C?
>> >
>> > Are you saying that there is a significant number of
>> > people who understand C++ but not C?  The reason
>>
>> I wasn't saying anything, I was asking a question. :)
>
> Ah, I misunderstood.  The question about why people don't
> understand C on the heels of a reference to Stroustrup
> led me to think that was a suggestion C++ was easier to
> understand than C.  Of course, I may be a little too
> sensitive to such a claim, because of what I've been
> hearing in the academic community for a while.  Some
> keep saying that we should use more complex languages
> in the introductory course because they're in some way
> easier.  But I've yet to understand their definition
> of easier.*
>
> BLS
>
> *Well, actually I do kind of realize they are suggesting
> that a tinkertoy approach makes it easier for a beginner
> to see something happen.  The problem I have is that's
> not the point of teaching that material.  Just getting
> something to happen might be training, but it sure isn't
> education.
>
>

Re: [9fans] nice quote

[Daniel Lyons]

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

Re: [9fans] nice quote

[Jason Catena]

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

It's not LISP, but I've found Haskell good for writing terse code that
works.  Once you get your code past the type checker, it's likely to
just work for the forseeable future if it's pure.  Most tricky code
ends up pure, since the transforms are usually the more extensive,
interesting, and clever (ie difficult to debug) part of a (especially
pipeline-based) program.

I don't really care that a language is or is not close to the machine,
if the compiler (ie GHC) gets it in the same order of magnitude
runtime as C.  In fact, I'd rather manipulate lists with higher-order
functions, and just get the job done, than hack around with this
year's new idioms to make C all things to all people.  Best tool for
the job and all that: C has a great niche as an OS language, but
sometimes it's better just to write less, more stable code (eg xmonad
vs any C-based window manager).

Jason Catena

Re: [9fans] nice quote

[andrey mirtchovski]

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

I wish there was a way to record this for the next generation. Perhaps
in a list of worthy sayings and fortune cookies we could store
together with the rest of the system?

I must now find a way to somehow apply this simile in casual conversation.

Re: [9fans] nice quote

[Richard Miller]

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

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

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

[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) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

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

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:

<http://www.schnada.de/quotes/contempt.html#struetics>

... 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
<9fans@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]

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
<9fans@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]

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

Re: [9fans] nice quote

[John Floren]

On Sat, Sep 5, 2009 at 7:27 AM, Eris Discordia<eris.discordia@gmail.com> 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:
>
> <http://www.schnada.de/quotes/contempt.html#struetics>
>
> ... 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]

> 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
<slawmaster@gmail.com> wrote:

> On Sat, Sep 5, 2009 at 7:27 AM, Eris Discordia<eris.discordia@gmail.com>
> 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:
>>
>> <http://www.schnada.de/quotes/contempt.html#struetics>
>>
>> ... 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

[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

[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

[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 projects have. The overall air around it is one of 
dereliction even if it is in fact being actively worked on behind the 
scenes. Whether this is desired is again beyond me.

As a final note I think I should draw your attention to Linux's and *BSD's 
path of ascendancy. All of these OSs seem to have consecutively attracted 
distinct groups of users: serious programmers/contributors/researchers, 
startups, the pleb (that's my kind), and corporate users--in that specific 
order. Plan 9 seems to have stopped at stage 2 (startups), or maybe it's 
just progressing and I am unaware of the progress. Regardless, attracting 
the pleb seems to be the key to entering corporate user market and 
widespread popularity, i.e. the stage where corporations, hoping to win the 
pleb or higher pleb (industries and businesses), are willing to sponsor 
(read: bribe) universities, students, and their own R&D departments in 
teaching, learning, and furthering the new thing's cause.

**********

I must stress again these are all my impressions; hallucinations, if you 
will.




--On Saturday, September 05, 2009 13:30 -0600 Daniel Lyons 
<fusion@storytotell.org> wrote:

> 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

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

<http://books.google.com/books?id=nDWPW9uwZPAC&dq=%22the+first+computers%22&printsec=frontcover&source=bl&ots=Z_Kegt6Rwn&sig=zrlQEVkK8z7fAmBtXsW2lx754Zo&hl=en&ei=uPqiSsDVKY-GmwPkncjAAw&sa=X&oi=book_result&ct=result&resnum=7#v=onepage&q=branching&f=false>

(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
<quanstro@quanstro.net> 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

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

-- <http://en.wikipedia.org/wiki/Plankalkuel>

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 
<quanstro@quanstro.net> 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]

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

[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

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

On Sat, Sep 5, 2009 at 6:58 PM, Jason Catena <jason.catena@gmail.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3874 bytes --]

Re: [9fans] nice quote

[J.R. Mauro]

On Sat, Sep 5, 2009 at 2:26 PM, erik quanstrom <quanstro@quanstro.net> 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

[Eris Discordia]

> 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 don't think we are actually in disagreement here. I have no objections to
your assertion. However, the particular case at hand indicates a different
thing than historians (of computer technology) "backporting" today's
trivial matters. I believe that a concept existed in a language
(Plankalkuel) but not the machine it was supposed to control (Z3) by all
means indicates the designer of the machine and the language was aware of
the concept but faced technical limitations of his time. Stored-program
computers weren't only consequences of a person's (von Neumann's)
genius--they also were consequences of the culmination, and return point,
of delay line technology (EDSAC's memory components).

A parallel can be drawn with the emergence of quantum mechanics. Many
students of physics who aren't taught or don't teach themselves history of
physics tend to think quantum mechanics emerged at a particular time due to
that physical thinkers shortly before the time just weren't up to the
mental challenge and it would take visionaries/revolutionaries to institute
the new understanding. Historians of physics, however, can tell you with
quite some confidence that the improvements of experimental instrumentation
and becoming technically feasible of certain experiments that weren't
feasible before around the end of 19th century were very probably a more
influential agent.


--On Saturday, September 05, 2009 20:56 -0400 erik quanstrom
<quanstro@quanstro.net> wrote:

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

> In this respect rating the "expressive power of C versus LISP" depends
> very much on the problem domain under discussion.

Of course. I pointed out in my first post on the thread that "[...] 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." I cannot
exclude other machines and other problems but can talk from what little I
have personally experienced.

> I would like to see Haskell fill C's niche [...]

Is it as readily comprehensible to newcomers as C? Are there texts out
there that can welcome a real beginner in programming and help him become
productive, on a personal level at least, as rapidly as good C
textbooks--you know the classic example--do? Is there a coherent mental
model of small computers--not necessarily what you or I deem to be a small
computer--that Haskell fits well and can be taught to learners? I imagine
those will be indispensable for any language to replace existing languages,
much more so in case of C.


--On Saturday, September 05, 2009 20:58 -0500 Jason Catena
<jason.catena@gmail.com> 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).
>
> Jason Catena
>

Re: [9fans] nice quote

[Eris Discordia]

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

Are you implying Doug McIlroy hadn't been taught about (and inevitably 
occupied by) Church-Turing Thesis or even before that Ackermann function 
and had to wait to be inspired by a comment in passing about FORTRAN to 
realize the importance of recursion?! This was a rhetorical question, of 
course.



--On Sunday, September 06, 2009 00:23 -0400 "J.R. Mauro" 
<jrm8005@gmail.com> wrote:

> On Sat, Sep 5, 2009 at 2:26 PM, erik quanstrom <quanstro@quanstro.net>
> 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

[tlaronde]

On Sun, Sep 06, 2009 at 05:51:33PM +0100, Eris Discordia wrote:
> 
> I don't think we are actually in disagreement here. I have no objections to 
> your assertion. However, the particular case at hand indicates a different 
> thing than historians (of computer technology) "backporting" today's 
> trivial matters. I believe that a concept existed in a language 
> (Plankalkuel) but not the machine it was supposed to control (Z3) by all 
> [...]

There is a rather extensive review of 

"The Early Development of Programming Languages" 
	by Donald E. Knuth and Luis Trabb Pardo,
	reproduced and completed in "Selected Papers on Computer Languages",
	Donald E. Knuth, CSLI ISBN 1-57586-382-0

presenting the state and achievement, among many others, of Zuss
Plankalkül (followed by Goldstine/von Neumann, Curry, Mauchly etc.).
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] nice quote

[Rob Pike]

> Are you implying Doug McIlroy hadn't been taught about (and inevitably
> occupied by) Church-Turing Thesis or even before that Ackermann function and
> had to wait to be inspired by a comment in passing about FORTRAN to realize
> the importance of recursion?! This was a rhetorical question, of course.

Doug loves that story. In the version he told me, he was a (math) grad
student at MIT in 1956 (before FORTRAN) and the discussion in the lab
was about computer subroutines - in assembly or machine language of
course.  Someone mused about what might happen if a subroutine called
itself.  Everyone looked bemused.  The next day they all returned and
declared that they knew how to implement a subroutine that could call
itself although they had no idea what use it would be.  "Recursion"
was not a word in computing.  Hell, "computing" wasn't even much of a
word in math.

Don't be Whiggish in your understanding of history.  Its participants
did not know their way.

-rob

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

On Sun, Sep 6, 2009 at 10:08 AM, Eris Discordia <eris.discordia@gmail.com>wrote:

> In this respect rating the "expressive power of C versus LISP" depends
>> very much on the problem domain under discussion.
>>
>
> Of course. I pointed out in my first post on the thread that "[...] 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." I cannot exclude
> other machines and other problems but can talk from what little I have
> personally experienced.
>
>  I would like to see Haskell fill C's niche [...]
>>
>
> Is it as readily comprehensible to newcomers as C? Are there texts out
> there that can welcome a real beginner in programming and help him become
> productive, on a personal level at least, as rapidly as good C
> textbooks--you know the classic example--do? Is there a coherent mental
> model of small computers--not necessarily what you or I deem to be a small
> computer--that Haskell fits well and can be taught to learners? I imagine
> those will be indispensable for any language to replace existing languages,
> much more so in case of C.
>

According to the designer of F# (another functional programming language
that takes it's syntax from O'Caml as well as Haskell and even Python), one
of the best experiences he'd had was working with a high school student who
was able to modify a solar system simulation written in F# with no prior
programming experience.  (from
http://www.computerworld.com.au/article/271034/)

There's books on F# out there, and F# for Scientists.

http://www.ffconsultancy.com/products/fsharp_for_scientists/index.html

There's books on multimedia programming in Haskell out there that also
attempt to show programming to newcomers, but I'm not sure any of them
really assume no prior programming experience.

I think people learning C get one view of the computer that folks learning
assembly really learn to appreciate :-).  Folks learning Haskell learn
another mental model of programming as well.

My personal belief is that learning new languages makes one think about the
languages they are used to in a new light, and can make them better
programmers overall.

[-- Attachment #2: Type: text/html, Size: 3043 bytes --]

Re: [9fans] nice quote

[Tim Newsham]

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

Do you know of any garbage collectors written in Haskell?  Do
you know of any thread/process schedulers written in Haskell
that can schedule arbitrary code (ie. not just code that is
written in a continuation monad)?

I would like to see a language that lets you write low level code
(like memcpy) efficiently, in a style that makes reasoning about
the code easy, and which doesnt require (but can coexist and support)
garbage collection.

"while(n--) *p++ = *q++;"
is still quite elegant compared to many other expressive langauges.
setjmp and longjmp are still quite powerful.

> Jason Catena

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] nice quote

[Tim Newsham]

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

Keep in mind that House and hOp both used the ghc runtime (written in C)
as a base.  I would argue that this is most of the "OS". The seL4 spec is
more like an operating system simulation than an operating system (or more
accurately it is a spec that can be executed).

I'm not familiar with the other projects you mention.  Thank you,
I'll check em out...

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

I'm a big fan.  Just want to make sure the hype isn't overblown.

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] nice quote

[James Chapman]

[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]


On Sep 6, 2009, at 9:05 PM, David Leimbach wrote:
> On Sun, Sep 6, 2009 at 10:08 AM, Eris Discordia <eris.discordia@gmail.com
> > wrote:
> In this respect rating the "expressive power of C versus LISP" depends
> very much on the problem domain under discussion.
>
> Of course. I pointed out in my first post on the thread that "[...]
> 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." I cannot exclude other machines and other problems but can
> talk from what little I have personally experienced.
>
> I would like to see Haskell fill C's niche [...]
>
> Is it as readily comprehensible to newcomers as C? Are there texts
> out there that can welcome a real beginner in programming and help
> him become productive, on a personal level at least, as rapidly as
> good C textbooks--you know the classic example--do? Is there a
> coherent mental model of small computers--not necessarily what you
> or I deem to be a small computer--that Haskell fits well and can be
> taught to learners? I imagine those will be indispensable for any
> language to replace existing languages, much more so in case of C.
>
> According to the designer of F# (another functional programming
> language that takes it's syntax from O'Caml as well as Haskell and
> even Python), one of the best experiences he'd had was working with
> a high school student who was able to modify a solar system
> simulation written in F# with no prior programming experience.
> (from http://www.computerworld.com.au/article/271034/)
>
> There's books on F# out there, and F# for Scientists.
>
> http://www.ffconsultancy.com/products/fsharp_for_scientists/index.html
>
> There's books on multimedia programming in Haskell out there that
> also attempt to show programming to newcomers, but I'm not sure any
> of them really assume no prior programming experience.
>
> I think people learning C get one view of the computer that folks
> learning assembly really learn to appreciate :-).  Folks learning
> Haskell learn another mental model of programming as well.
>
> My personal belief is that learning new languages makes one think
> about the languages they are used to in a new light, and can make
> them better programmers overall.
>

As you mentioned beginners books for Haskell I couldn't resist
plugging Graham Huttons excellent beginners book "Programming in
Haskell":

http://www.cs.nott.ac.uk/~gmh/book.html

It is based on 10 years of teaching a first year undergraduate course
and is certainly accessible I believe. I've taught an undergraduate
course myself using it.

There is also the this book which complements Graham's quite well:

http://www.realworldhaskell.org/blog/

I agree with David in that it is asking the wrong question as to
whether there is a model of a computer that fits with Haskell. Haskell
is based on a different model of computation. Conceptually, Haskell
programs are executed by rewriting expressions not by manipulating
memory in a machine.

A trivial example:

Here's a function to append a list onto a list:

append :: [a] -> [a] -> [a]
append [] ys = ys
append (x:xs) ys = x:append xs ys

and here we run it (on paper, no machine required :) ) on a some lists
by applying the above rules where the match:

Note: [1,2] is syntactic sugar for (1:(2:[]))

append [1,2] [3,4]
= { apply first pattern match equation }
1 : append [2] [3,4]
= { apply first pattern match equation }
1 : 2 : append [] [3,4]
= { apply second pattern match equation }
1 : 2 : [3,4]
= { just syntactic sugar }
[1,2,3,4]

I wouldn't be as bold as to suggest that Haskell should replace C but
certainly it is a nice language to use in my opinion. Does it explain
how a computer works? No. Does it explain 'computation'? Yes.






[-- Attachment #2: Type: text/html, Size: 5658 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Sun, Sep 6, 2009 at 11:26 AM, Tim Newsham <newsham@lava.net> wrote:

> 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).
>>
>
> Do you know of any garbage collectors written in Haskell?  Do
> you know of any thread/process schedulers written in Haskell
> that can schedule arbitrary code (ie. not just code that is
> written in a continuation monad)?
>
> I would like to see a language that lets you write low level code
> (like memcpy) efficiently, in a style that makes reasoning about
> the code easy, and which doesnt require (but can coexist and support)
> garbage collection.
>
>
Hmmm, pre-scheme perhaps?  http://en.wikipedia.org/wiki/PreScheme

It doesn't do garbage collection, and is meant for low level code, but
provides scheme's macros.  Scheme48 is written in it.


> "while(n--) *p++ = *q++;"
> is still quite elegant compared to many other expressive langauges.
> setjmp and longjmp are still quite powerful.
>
>  Jason Catena
>>
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>

[-- Attachment #2: Type: text/html, Size: 2415 bytes --]

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Sun, Sep 6, 2009 at 11:29 AM, Tim Newsham <newsham@lava.net> wrote:

> 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.
>>
>
> Keep in mind that House and hOp both used the ghc runtime (written in C) as
> a base.  I would argue that this is most of the "OS". The seL4 spec is more
> like an operating system simulation than an operating system (or more
> accurately it is a spec that can be executed).
>

I suppose this is true, though I thought GHC's runtime was still mostly
Haskell. (haven't looked, but one would think porting GHC would be a lot
simpler if it was in all C).


>
> I'm not familiar with the other projects you mention.  Thank you,
> I'll check em out...
>
>  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.
>>
>
> I'm a big fan.  Just want to make sure the hype isn't overblown.


Oh I agree with your point of view.  I even write some code in C, and make
Haskell bindings for it still today when Haskell seems like too much of a
pain to use (like a ring buffer implementation I did).

I'm a big fan of multi-paradigm programming.  I've got Erlang calling
Haskell and C++ in a system we actually deploy at work.  Pick the weapon
that's easiest to express the algorithms you need correctly in, and *then*
measure performance to make sure everything is still ok.

I do this for the same reasons people say C makes assembly mostly obsolete.
 Why work the low level stuff if the heavy lifting can be done for you in
advance.

Dave


>
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>

[-- Attachment #2: Type: text/html, Size: 2895 bytes --]

Re: [9fans] nice quote

[Eris Discordia]

Thanks for the first-hand account :-)

> Don't be Whiggish in your understanding of history.  Its participants
> did not know their way.

Given your original narrative I really can't argue. Maybe, as you note, I'm
wrongly assuming everyone knew a significant part of that which had come
before them without accounting for natural propagation delays and barriers
between thought pools. Nonetheless, it can't be denied a lot of ideas, and
words used to denote them, in computation were conceived at earlier times
than one might expect, sometimes even more comprehensively than today. For
instance, von Foerster was consistently using "computing" in an
astonishingly wide sense, e.g. bio-computing, by the 1950s. Even today most
people don't immediately generalize that notion the way he did while such
generalization is more than warranted.


--On Sunday, September 06, 2009 11:03 -0700 Rob Pike <robpike@gmail.com>
wrote:

>> Are you implying Doug McIlroy hadn't been taught about (and inevitably
>> occupied by) Church-Turing Thesis or even before that Ackermann function
>> and had to wait to be inspired by a comment in passing about FORTRAN to
>> realize the importance of recursion?! This was a rhetorical question, of
>> course.
>
> Doug loves that story. In the version he told me, he was a (math) grad
> student at MIT in 1956 (before FORTRAN) and the discussion in the lab
> was about computer subroutines - in assembly or machine language of
> course.  Someone mused about what might happen if a subroutine called
> itself.  Everyone looked bemused.  The next day they all returned and
> declared that they knew how to implement a subroutine that could call
> itself although they had no idea what use it would be.  "Recursion"
> was not a word in computing.  Hell, "computing" wasn't even much of a
> word in math.
>
> Don't be Whiggish in your understanding of history.  Its participants
> did not know their way.
>
> -rob
>

Re: [9fans] nice quote

[Rudolf Sykora]

>> 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 guess rc & C are meant.
True, I feel to be pushed to these. On the other hand I really like
rc. Compared to bash/sh/ksh/zsh... I like its simplicity as well as
that it is the only shell in plan9. I use it in linux too (although I
miss some abilities it really should have, like ability to break from
a loop).
With C, I confess I do not use it often. In my life I found C a good
tool to program microcontrollers. But otherwise I prefer python/ruby
way unless speed is important---which, either really is (computation;
physics) -> I use Fortran, see below, or is not at all.
Fortunately, there are some ports of python and ruby to plan9. But it
was always so difficult in my eyes, that I backed out from trying to
use them (do you also have a feeling that the simples installation is
often in windows, even for open-source projects?).
There is also limbo, but for that I guess inferno must be installed...
(am I right?)

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

Well, maybe. But it probably can be rather difficult to get some
software to work in plan9 even though it is written in C, but 'for
another system'... E.g. give me python+numpy+matplotlib...

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

Here, I must agree. Though I first hated Fortran for what it carries
with itself from the times of FORTRAN, for all it's inabilities to
work with strings, I must truly confess that I do not know of a better
language for doing calculations. There is no way to compare C to
Fortran, the latter being by no question superior. E.g. (not in any
order of importance)
Fortran can be (and usually is) quicker (better pointers).
Fortran can have optional parameters to functions.
Fortran can easily define/overload operators (not so nice yet, but
improving, e.g. the priority of new operators cannot be set) --- this
is nice to e.g. multiply matrices like this: C = A .x. B, do
inversions like this .I.A, or transpose .T.A, among others.
Fortran has elemental functions.
Fortran can slice arrays, like a(2:8), similarly to matlab or numpy.
Some people claim it is better suited for parallelism, but I can't say
much about this point
....
It's difficult to find anything where C would be better. Fortran still
has some very ugly places, but it has become really powerful.

But I guess there is nobody who would plan to put Fortran in plan9.

Re: [9fans] nice quote

[erik quanstrom]

> True, I feel to be pushed to these. On the other hand I really like
> rc. Compared to bash/sh/ksh/zsh... I like its simplicity as well as
> that it is the only shell in plan9. I use it in linux too (although I
> miss some abilities it really should have, like ability to break from
> a loop).

i've added it as an experiment:
/n/sources/contrib/quanstro/src/futharc

- erik

Re: [9fans] nice quote

[Vinu Rajashekhar]

Concrete Abstractions
An Introduction to Computer Science Using Scheme

http://gustavus.edu/+max/concrete-abstractions.html

Chapter 11: Computers with Memory
We first address the questions of what a computer is and how it comes
to compute by presenting a simplified RISC architecture and showing
how to program in its assembly language. We call attention to memory
as a numbered collection of storage locations, and use this as
motivation for introducing Scheme's vectors (one-dimensional arrays)
as a way to access storage from within the high-level language. In the
application section, we use vectors to program a simulator for our
RISC architecture in Scheme.

On Sun, Sep 6, 2009 at 4:45 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> True, I feel to be pushed to these. On the other hand I really like
>> rc. Compared to bash/sh/ksh/zsh... I like its simplicity as well as
>> that it is the only shell in plan9. I use it in linux too (although I
>> miss some abilities it really should have, like ability to break from
>> a loop).
>
> i've added it as an experiment:
> /n/sources/contrib/quanstro/src/futharc
>
> - erik
>
>



--
Vinu Rajashekhar,
5th Year Dual Degree Student,
Deptt of Computer Science & Engg,
IIT Kharagpur,
India.

Re: [9fans] nice quote

[Paul Donnelly]

eris.discordia@gmail.com (Eris Discordia) writes:

> I whined about LISP on yet another thread. Above says precisely why I
> did. LISP is twofold hurtful for me as a naive, below average
> hobbyist. For one thing the language constructs do not reflect the
> small computer primitives I was taught somewhere around the beginning
> of my education. 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. Its claim to fame as the language for
> "wizards" remains. 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").

Consider that your introduction to Lisp may have been very poor. You're
right that the mapping from Lisp primitives to machine primitives isn't
as direct as that in, but Lisp doesn't represent any AI paradigm at all,
nor a particular programming paradigm, and its name hasn't been written
in caps for perhaps 30 years. I'm not trying to nitpick; I'm only saying
that there are a lot of weird ideas about Lisp floating around which a
person can hardly be blamed for picking up on, and these are the reasons
it sounds to me like you have.

> One serious question today would be: what's LISP _really_ good for?
> That it represents a specific programming paradigm is not enough
> justification.

I think most Lispers would say it's _really_ good for anything but the
most demanding number crunching, or perhaps A-list games
programming. Probably you'd run into trouble in some parallel
programming situations, for reasons more related to implementation
support and libraries than reasons intrinsic to the language. And the
justification would be that Lisp is an embarrassingly multiparadigm
language, as general-purpose as they come.

Re: [9fans] nice quote

[Paul Donnelly]

eris.discordia@gmail.com (Eris Discordia) writes:

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

Just the orthography.

> Indeed, my only encounter with LISP has been Scheme and through a
> failed attempt to read SICP.

Next time you get a hankering to see what all the fuss is about, you
could try a book like Practical Common Lisp (which can be read online at
http://gigamonkeys.com/book/ ). SICP is a good book, but it's geared
toward introducing fundamental programming concepts like abstraction
with a minimum of language features, which is necessarily at odds with
getting stuff done in a straightforward way.

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

I must say that the Lisp version is much simpler and clearer to me,
while the C version is mildly baffling. Does that make me a wizard who
can hardly read simple C code, or is it just a matter of what you and I
are respectively more comfortable with?

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

Don't assume that just because Lisp is useful for list processing that
it's not useful for a wide variety of problem-solving approaches. I've
seen many people get hung up on lists (and recursion), thinking that
they are somehow the essence of Lisp programming.

Re: [9fans] nice quote

[Greg Comeau]

In article <dac0a5820909031501q676cda3dvab7ccafa331b3a05@mail.gmail.com>,
Tharaneedharan Vilwanathan <vdharani@gmail.com> wrote:
>> C shall be the test. If you don't even understand C, explained by K&R,
>> then do something else.
>i agree to this completely. after taking a formal course in computers,
>if someone cannot read/follow K&R C book and cannot write C code, i
>would think that the candidate is not good enough.

Comes full circle, as if that is the metric, then that rules out
most candidates.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Daniel Lyons]

On Sep 7, 2009, at 2:54 AM, Paul Donnelly wrote:

> or perhaps A-list games programming


The Jak and Daxter series was written in Common Lisp.

http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

—
Daniel Lyons

Re: [9fans] nice quote

[Greg Comeau]

In article <542783.92348.qm@web83904.mail.sp1.yahoo.com>,
Brian L. Stuart <blstuart@bellsouth.net> wrote:
>>>>>K&R is beautiful in this respect. In contrast, never managed
>>>>>bite in Stroustrup's description.
>>>> Ok, now I'll get provocative:
>>>> hen why do so many people have a problem understanding C?
>>>Are you saying that there is a significant number of people
>>>who understand C++ but not C?
>>I wasn't saying anything, I was asking a question. :)
>
>Ah, I misunderstood.  The question about why people don't understand
>C on the heels of a reference to Stroustrup led me to think that
>was a suggestion C++ was easier to understand than C.

That's wasn't the orginal movitivation, although, that can be true.

>Of course, I may be a little too sensitive to such a claim,
>because of what I've been hearing in the academic community for
>a while.

Understood.

>Some keep saying that we should use more complex languages in
>the introductory course because they're in some way easier.
>But I've yet to understand their definition of easier.

I've seen this before.  It's usually a combo of people
not knowing what they're talking about, making stuff up
as they go along, generalizing their personal programming
universe, being elite, and, miscommunication their point.

>Well, actually I do kind of realize they are suggesting that a
>tinkertoy approach makes it easier for a beginner to see something happen.
>The problem I have is that's not the point of teaching that material.

It's not.  But that doesn't have to mean throwing the other
parts out the window either.

>Just getting something to happen might be training, but it sure isn't
>education.

No, and theory and practical experience are two different things
too.  I would not necessarily say only one or only the other,
but probably often some balances combination.

As to easier/harder above, that can be slippery.
However, with the right approach, different steppingstones
can be provided depending upon the strategy chosen.
Of course, that can be a prescription for being doomed
to fail, but it's a juggle for sure even with success,
whatever that is, and with event he easier approach,
whatever that is :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Vinu Rajashekhar]

Write Haskell as fast as C: exploiting strictness, laziness and recursion
- http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16
>From the article

Lesson 1: To write predictably fast Haskell -- the kind that competes
with C day in and out
-- use tail recursion, and ensure all types are inferred as simple
machine types, like Int, Word,
Float or Double that simple machine representations. The performance
is there if you want it.

Lesson 2: Laziness has an overhead -- while it allows you to write new
kinds of programs
(where lists may be used as control structures), the memory traffic
that results can be a
penalty if it appears in tight inner loops. Don't rely laziness to
give you performance in your inner loops.

Lesson 3: For heavy optimisation, the C backend to GHC is still the
way to go. Later this
year a new bleeding edge native code generator will be added to GHC,
but until then,
the C backend is still an awesome weapon.

On Mon, Sep 7, 2009 at 2:24 PM, Paul
Donnelly<paul-donnelly@sbcglobal.net> wrote:
> eris.discordia@gmail.com (Eris Discordia) writes:
>
>> I whined about LISP on yet another thread. Above says precisely why I
>> did. LISP is twofold hurtful for me as a naive, below average
>> hobbyist. For one thing the language constructs do not reflect the
>> small computer primitives I was taught somewhere around the beginning
>> of my education. 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. Its claim to fame as the language for
>> "wizards" remains. 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").
>
> Consider that your introduction to Lisp may have been very poor. You're
> right that the mapping from Lisp primitives to machine primitives isn't
> as direct as that in, but Lisp doesn't represent any AI paradigm at all,
> nor a particular programming paradigm, and its name hasn't been written
> in caps for perhaps 30 years. I'm not trying to nitpick; I'm only saying
> that there are a lot of weird ideas about Lisp floating around which a
> person can hardly be blamed for picking up on, and these are the reasons
> it sounds to me like you have.
>
>> One serious question today would be: what's LISP _really_ good for?
>> That it represents a specific programming paradigm is not enough
>> justification.
>
> I think most Lispers would say it's _really_ good for anything but the
> most demanding number crunching, or perhaps A-list games
> programming. Probably you'd run into trouble in some parallel
> programming situations, for reasons more related to implementation
> support and libraries than reasons intrinsic to the language. And the
> justification would be that Lisp is an embarrassingly multiparadigm
> language, as general-purpose as they come.
>
>



--
Vinu Rajashekhar,
5th Year Dual Degree Student,
Deptt of Computer Science & Engg,
IIT Kharagpur,
India.

Re: [9fans] nice quote

[Greg Comeau]

In article <fe41879c0909050422s77247280y4fcd7d89a621b8b4@mail.gmail.com>,
Akshat Kumar <akumar@mail.nanosouffle.net> wrote:
>> 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?

It's certainly true that cultures and mindsets build up
around different things, some of it reasonable, some of it not,
and I observe Plan 9 is not much different in this regard.
That said, saying "push" and "inherent" are probably
inherently pushing things :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <BB8E3A2E5419E566D0361D29@[192.168.1.2]>,
Eris Discordia <eris.discordia@gmail.com> wrote:
>I think I am sure C
>was a lot easier to learn and comprehend than either Pascal

Might depend how you define easier.

>What seems to distinguish--pedagogically, at least--C is, as I noted on
>that other thread, its closeness to how the small computer, not the actual
>small computer but the mental model of a small computer, works. Pointers?
>They're just references to "pigeonholes" in a row of such holes. Scope?
>It's just how long your variables are remembered. Invocation? Just a way to
>regurgitate your own cooking. If one has to solve a problem, implement an
>algorithm, on a small computer one needs to be able to explain it in terms
>of the primitives available on that computer. That's where C shines.
>There's a close connection between language primitives and the primitives
>of the underlying computer. I'm not saying this is something magically
>featuring in C--it's a property that _had_ to feature in some language some
>time, C became that. In a different time and place, on different machines,
>another language would/will be that (and it shall be called C ;-))

It is indeed true that C can "hug the hardware" and the rest is
history as they say.  However, to implement an algorithm solely
based upon the primitive of a computer, if I understand you,
I can't agree to as a carte blanche statement.

>...There's a great deal of arbitrariness in how a computer language
>might look. It is epistemologically, aesthetically, and pragmatically
>advantageous to "remove arbitrariness" by fitting a language to either its
>target platform or its target problem, preferably both. C did and continues
>to do so, LISP doesn't (not anymore, to say the least).

These bits and piece do come into play, however, I think your
conclusion greatly exaggerates the situation, at least as I
understand what you said.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Akshat Kumar]

>>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?
>
> It's certainly true that cultures and mindsets build up
> around different things, some of it reasonable, some of it not,
> and I observe Plan 9 is not much different in this regard.
> That said, saying "push" and "inherent" are probably
> inherently pushing things :)

I suppose my wording showed emphasis in all the wrong places.
The question I meant to ask was (given the context of the
referenced article):
  In the Plan 9 environment, are languages considered to be "tools"?

The rest was just my reasoning to ask.


Best,
ak

Re: [9fans] nice quote

[Daniel Lyons]

On Sep 7, 2009, at 3:05 AM, Greg Comeau wrote:

>> Some keep saying that we should use more complex languages in
>> the introductory course because they're in some way easier.
>> But I've yet to understand their definition of easier.
>
> I've seen this before.  It's usually a combo of people
> not knowing what they're talking about, making stuff up
> as they go along, generalizing their personal programming
> universe, being elite, and, miscommunication their point.


I have a friend who insists that every other language has been harder  
on him than macro assembler. And I think that's true, if you cannot  
understand how to program a machine other than by thinking about  
what's happening at the instruction level of the processor.

Each language provides its own view of the land. If you have a strong  
understanding of the hardware and wish to think in those terms you  
will probably find assembler or C to be your best friend. If you have  
a strong mathematical inclination Haskell will probably suit you  
better. I find Scheme introduces a model of computation which is a  
compromise between the two; close to the machine in memory, simple in  
syntax, and rather far from the machine in terms of continuations, but  
most of the code being in the middle anyway.

Part of what makes computing so interesting to me is that we can  
remodel it to suit different needs, tastes or problems. If we had to  
write our schedulers in rc, we'd probably find it obnoxious; similarly  
if we had to write trivial pipelines in C. The nice thing about Lisp,  
Haskell and Java is that when you're in their little world everything  
works the way you'd expect it to in their little world; the nice thing  
about Plan 9 and Unix is that most everything is designed to interact  
sanely and simply with the rest of the world. I find writing puzzle  
solvers simpler in Prolog than in Haskell despite Haskell's list  
comprehensions being essentially the same in power and somewhat more  
straightforward to reason about.

For some reason, the fact that we program rational machines in logic- 
based languages deludes us into thinking our experience is the same as  
everyone else's or our situation must be the same as everyone else's.  
I don't know anyone who likes to debate a programmer and isn't also a  
programmer; we are undoubtedly the most self-assured and non- 
empathetic group of people on the planet. We have every opportunity to  
be free of dogma, but our reason and our aesthetic reactions seem  
somehow to be soldered directly onto our emotions.

A problem is that the world isn't as rational as we are. It often  
chooses based on expedience, popularity, rumor, or emotion. Often the  
good is devoured by good marketing. I never would have expected to  
find defenders of Lisp or Haskell here in the Plan 9 mailing list. I  
am happy about that. But the hindsight has not been 20/20. Lisp and  
Plan 9 are in the same situation for exactly the same reason: they're  
both conceptually rigorous and short on eye candy, and the market  
chose other alternatives long ago, and now those alternatives define  
the question in a way that precludes these answers.

—
Daniel Lyons

Re: [9fans] nice quote

[erik quanstrom]

i agree the computer industry as a whole tends
to be long on dogma and yet suffers from an accute
inability to recall previous mistakes.

> For some reason, the fact that we program rational machines in logic-
> based languages deludes us into thinking our experience is the same as
> everyone else's or our situation must be the same as everyone else's.
> I don't know anyone who likes to debate a programmer and isn't also a
> programmer; we are undoubtedly the most self-assured and non-
> empathetic group of people on the planet. We have every opportunity to
> be free of dogma, but our reason and our aesthetic reactions seem
> somehow to be soldered directly onto our emotions.

but having lived in washington, dc for a decade, i think
i met a few groups that can be more self-assured.

- erik

Re: [9fans] nice quote

[J.R. Mauro]

On Sun, Sep 6, 2009 at 2:03 PM, Rob Pike <robpike@gmail.com> wrote:
>> Are you implying Doug McIlroy hadn't been taught about (and inevitably
>> occupied by) Church-Turing Thesis or even before that Ackermann function and
>> had to wait to be inspired by a comment in passing about FORTRAN to realize
>> the importance of recursion?! This was a rhetorical question, of course.
>
> Doug loves that story. In the version he told me, he was a (math) grad
> student at MIT in 1956 (before FORTRAN) and the discussion in the lab
> was about computer subroutines - in assembly or machine language of
> course.  Someone mused about what might happen if a subroutine called
> itself.  Everyone looked bemused.  The next day they all returned and
> declared that they knew how to implement a subroutine that could call
> itself although they had no idea what use it would be.  "Recursion"
> was not a word in computing.  Hell, "computing" wasn't even much of a
> word in math.

It's nice to know that it's a bit of lore that changes with each telling.

>
> Don't be Whiggish in your understanding of history.  Its participants
> did not know their way.
>
> -rob
>
>

Re: [9fans] nice quote

[Greg Comeau]

In article <fe41879c0909070239q1846b4b4wcbd2e28724be3bed@mail.gmail.com>,
Akshat Kumar <akumar@mail.nanosouffle.net> wrote:
>>>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?
>>
>> It's certainly true that cultures and mindsets build up
>> around different things, some of it reasonable, some of it not,
>> and I observe Plan 9 is not much different in this regard.
>> That said, saying "push" and "inherent" are probably
>> inherently pushing things :)
>
>I suppose my wording showed emphasis in all the wrong places.
>The question I meant to ask was (given the context of the
>referenced article):
>  In the Plan 9 environment, are languages considered to be "tools"?
>
>The rest was just my reasoning to ask.

>From what I've seen that are (well, implementations of them).
Some thing they're fun too :)  Generally universal comments anyway.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[erik quanstrom]

>  From what I've seen that are (well, implementations of them).
> Some thing they're fun too :)  Generally universal comments anyway.

is this english++?  i just can't parse it.

- erik

Re: [9fans] nice quote

[Greg Comeau]

In article <936A4BAB-7D9A-4B65-AB6A-C5EEA8E4326C@storytotell.org>,
Daniel Lyons <fusion@storytotell.org> wrote:
>On Sep 7, 2009, at 3:05 AM, Greg Comeau wrote:
>>> Some keep saying that we should use more complex languages in
>>> the introductory course because they're in some way easier.
>>> But I've yet to understand their definition of easier.
>>
>> I've seen this before.  It's usually a combo of people
>> not knowing what they're talking about, making stuff up
>> as they go along, generalizing their personal programming
>> universe, being elite, and, miscommunication their point.
>
>I have a friend who insists that every other language has been harder
>on him than macro assembler.

We all suffer some level of this syndrome from time to time.
It's easy to get set in out ways, easy to think we know it all
and have done everything, easy to think there isn't much else,
easy to think that thing or idea we don't understand hence has
to be a piece of garbage.  Etc etc.  So yeah, the harder
factor comes into play here too.  Other planes of thinking
need to compete with already existing and ingrained ways
of thinking, whether the already ones are poor, incomplete,
wrong, limited, or ignorant.

>And I think that's true, if you cannot
>understand how to program a machine other than by thinking about
>what's happening at the instruction level of the processor.

Probably.

>Each language provides its own view of the land. If you have a strong
>understanding of the hardware and wish to think in those terms you
>will probably find assembler or C to be your best friend. If you have
>a strong mathematical inclination Haskell will probably suit you
>better. I find Scheme introduces a model of computation which is a
>compromise between the two; close to the machine in memory, simple in
>syntax, and rather far from the machine in terms of continuations, but
>most of the code being in the middle anyway.

Something like that.  And the different mentalities can
be a real good mental block often.

>For some reason, the fact that we program rational machines in logic-
>based languages deludes us into thinking our experience is the same as
>everyone else's or our situation must be the same as everyone else's.

The malleablility involved is both a band aid and a sword :)

>I don't know anyone who likes to debate a programmer and isn't also a
>programmer; we are undoubtedly the most self-assured and non-
>empathetic group of people on the planet. We have every opportunity to
>be free of dogma, but our reason and our aesthetic reactions seem
>somehow to be soldered directly onto our emotions.

Hehe.

>A problem is that the world isn't as rational as we are. It often
>chooses based on expedience, popularity, rumor, or emotion.

I find that the programmers do this just as much, if not as well
with their own twists.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Eris Discordia]

This thread has grown into a particularly educational one, for me at least,
thanks to everyone who posted.

Vinu Rajashekhar's two posts were strictly to the point. There _is_ a
mental model of the small computer to teach along with Scheme and there are
ways to get close to the machine from within Haskell. The suggestion for
using tail recursion seemed to serve to cue compiler into transforming the
recursion into iteration (in C the programmer would _probably_ have used
iteration in the first place).

Daniel Lyons' argument goes well with Paul Donnelly's:

> I'm only saying that there are a lot of weird ideas about Lisp floating
> around which a person can  hardly be blamed for picking up on, and these
> are the reasons it sounds to me like you have.

Regarding where I may have gone wrong about Lisp (besides orthography). At
the moment, I am very much intrigued to try learning a functional language
even if only to fail again. The hobbyist can experiment at leisure, after
all. And the links posted provide quite enough material.

As for this direct question:

> I must say that the Lisp version is much simpler and clearer to me, while
> the C version is mildly baffling. Does that make me a wizard who can
> hardly read simple C code, or is it just a matter of what you and I are
> respectively more comfortable with?

I'd like to concur with the implication that it's all a matter of what
mindset one carries but I'm also tempted to exclaim since I find the C
version straightforward--it closely follows how one would do a bubble sort
on paper. Or perhaps even this assertion is shaped by my personal
impressions.

Re: [9fans] nice quote

[Lyndon Nerenberg - VE6BBM/VE7TFX]

> is this english++?  i just can't parse it.

If we all ignore him he might go away ...

Re: [9fans] nice quote

[Federico G. Benavento]

relax

On Mon, Sep 7, 2009 at 5:56 PM, Lyndon Nerenberg -
VE6BBM/VE7TFX<lyndon@orthanc.ca> wrote:
>> is this english++?  i just can't parse it.
>
> If we all ignore him he might go away ...
>
>
>



-- 
Federico G. Benavento

Re: [9fans] nice quote

[Lyndon Nerenberg - VE6BBM/VE7TFX]

> relax

If I want platitudes I have the whole rest of the internet to gorge
on.  Here we try to do actual content.

Re: [9fans] nice quote

[Greg Comeau]

In article <9758acfae7a47701316dbcd67a7033aa@quanstro.net>,
erik quanstrom <quanstro@quanstro.net> wrote:
>>  From what I've seen that are (well, implementations of them).
>> Some thing they're fun too :)  Generally universal comments anyway.
>
>is this english++?  i just can't parse it.

Nope. Babel.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <A89E40C6E5A2AF85DBD0A448@[192.168.1.2]>,
Eris Discordia <eris.discordia@gmail.com> wrote:
>> I must say that the Lisp version is much simpler and clearer to me, while
>> the C version is mildly baffling. Does that make me a wizard who can
>> hardly read simple C code, or is it just a matter of what you and I are
>> respectively more comfortable with?
>
>I'd like to concur with the implication that it's all a matter of what
>mindset one carries but I'm also tempted to exclaim since I find the C
>version straightforward--it closely follows how one would do a bubble sort
>on paper. Or perhaps even this assertion is shaped by my personal
>impressions.

A kind of empirical comment:
What you first learned, or at least what you first learned
that worked, often seems to wire us to that way.  This seems
to bring forth biases establishing your programming universe
versus somebody else's.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <cf1be04bf7455ba985f600b36c9d4e07@yyc.orthanc.ca>,
Lyndon Nerenberg - VE6BBM/VE7TFX <lyndon@orthanc.ca> wrote:
>> is this english++?  i just can't parse it.
>
>If we all ignore him he might go away ...

Pardon?  *Never* had an article get erroneously submitted?
One always has the options to killfile, go to the next
thread/message, whatever.  Being rude is rarely helpful.
Chill out.  Let's move on.  Please.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Greg Comeau]

In article <0ef4163eff31942c1dfd704af0f438c6@yyc.orthanc.ca>,
Lyndon Nerenberg - VE6BBM/VE7TFX <lyndon@orthanc.ca> wrote:
>> relax
>
>If I want platitudes I have the whole rest of the internet to gorge
>on.  Here we try to do actual content.

But we're not.

And the solution is to listen to you instead?  Irony?

Let's move on.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] nice quote

[Paul Donnelly]

eris.discordia@gmail.com (Eris Discordia) writes:

> As for this direct question:
>
>> I must say that the Lisp version is much simpler and clearer to me, while
>> the C version is mildly baffling. Does that make me a wizard who can
>> hardly read simple C code, or is it just a matter of what you and I are
>> respectively more comfortable with?
>
> I'd like to concur with the implication that it's all a matter of what
> mindset one carries but I'm also tempted to exclaim since I find the C
> version straightforward--it closely follows how one would do a bubble
> sort on paper. Or perhaps even this assertion is shaped by my personal
> impressions.

I don't have the two versions in front of me, but if I did I might say
that the Lisp version is more similar to describing how to do a bubble
sort, while the C version is more similar to doing it.

Re: [9fans] nice quote

[erik quanstrom]

On Wed Sep  9 04:36:52 EDT 2009, comeau@panix.com wrote:
> In article <0ef4163eff31942c1dfd704af0f438c6@yyc.orthanc.ca>,
> Lyndon Nerenberg - VE6BBM/VE7TFX <lyndon@orthanc.ca> wrote:
> >> relax
> >
> >If I want platitudes I have the whole rest of the internet to gorge
> >on.  Here we try to do actual content.
>
> But we're not.
>
> And the solution is to listen to you instead?  Irony?

you're right.  we've been doing this no-content
thing for years.  why change now?

- erik

Re: [9fans] nice quote

[Charles Forsyth]

if people would leave off moaning about moaning,
we'd clear the space for more moaning about lisp
although the former did have the advantage that the
messages were shorter and didn't quote the bulk of
all previous messages.

anyone written any software recently?
at this point it probably doesn't matter whether it was for plan 9 or not.

Re: [9fans] nice quote

[Russ Cox]

> anyone written any software recently?

i did.  http://9fans.net/archive/

Re: [9fans] nice quote

[erik quanstrom]

> anyone written any software recently?
> at this point it probably doesn't matter whether it was for plan 9 or not.

the problem with writing code is that then
everybody will tell you ten ways it sucks.
it's best to keep your code under wraps.

russ, thanks for the archive.  it's very useful.

- erik

Re: [9fans] nice quote

[Akshat Kumar]

> anyone written any software recently?
> at this point it probably doesn't matter whether it was for plan 9 or not.

I'll plug, like the conniving commercialist I be:
/n/sources/contrib/akumar/α/gofs

Interfaces coming soon.


ak

Re: [9fans] nice quote

[Richard Miller]

> anyone written any software recently?

Now you mention it, I've recently written a 'resize' command which is
a bit like resample(1) for impatient people:

term% time resample -x 1600 -y 1200 glenda.pic >/dev/null
36.07u 0.01s 36.21r 	 resample -x 1600 -y 1200 ...
term% time resize -b -s 1600 1200 glenda.pic >/dev/null
0.91u 0.02s 1.06r 	 resize -b -s 1600 1200 ...

The -b option is for bilinear interpolation.  Without that, it goes
a bit faster but you get jaggies.

term% time resize -s 1600 1200 glenda.pic >/dev/null
0.56u 0.03s 0.71r 	 resize -s 1600 1200 glenda.pic ...

It's in /n/sources/contrib/miller/resample.c

Warning: only works on 24bpp images at present.

Re: [9fans] nice quote

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Wed, Sep 9, 2009 at 8:48 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> if people would leave off moaning about moaning,
> we'd clear the space for more moaning about lisp
> although the former did have the advantage that the
> messages were shorter and didn't quote the bulk of
> all previous messages.
>
> anyone written any software recently?
> at this point it probably doesn't matter whether it was for plan 9 or not.
>
>
I wrote a concurrent prime sieve using GCD from Snow Leopard :-)

It's just a demonstration but I wrote that all the same.

I started in on a Haskell 9p library as well, but haven't gotten very far,
due to mostly the time I have to invest in it.

I managed to get it to successfully "version message" Inferno's styxlisten
though.

The code is butt ugly too and I'm going to start over.

Dave

[-- Attachment #2: Type: text/html, Size: 1266 bytes --]

Re: [9fans] nice quote

[Richard Miller]

> It's in /n/sources/contrib/miller/resample.c

s/resample/resize/

sorry.

Re: [9fans] nice quote

[Jason Catena]

> anyone written any software recently?

I wrote ssam, a stream interface to sam, and its man page (ssam.1,
from sed.1) for (at least) plan9port.  It's still under review.

http://codereview.appspot.com/95076/show
latest ssam is patch set 8
latest ssam.1 is patch set 9

I also have a little script called vary (not published yet) which
takes a sam script and another file, applies the sam script to the
file, saves it with a new name, and optionally executes it.  So you
don't have to maintain many nearly-identical scripts.  I should upload
vary to the same patch set soon, for review.

Jason Catena

Re: [9fans] nice quote

[Abhishek Kulkarni]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Wed, Sep 9, 2009 at 12:00 PM, Russ Cox <rsc@swtch.com> wrote:

> > anyone written any software recently?
>
> i did.  http://9fans.net/archive/
>
>
Thanks. I like the new interface. It makes searching through the
archives a lot easier. I do still kinda sometimes prefer the threaded
view that Google Groups offers when reading archived threads.
(Google Groups archives seem broken off late and do not include
older threads in the archive)

It would be cool to have "next in thread" and "prev in thread"
pointers to jump around between topics in the same thread.

[-- Attachment #2: Type: text/html, Size: 1011 bytes --]

Re: [9fans] nice quote

[Jack Norton]

Abhishek Kulkarni wrote:
> On Wed, Sep 9, 2009 at 12:00 PM, Russ Cox <rsc@swtch.com
> <mailto:rsc@swtch.com>> wrote:
>
>     > anyone written any software recently?
>
>     i did.  http://9fans.net/archive/
>
>
> Thanks. I like the new interface. It makes searching through the
> archives a lot easier. I do still kinda sometimes prefer the threaded
> view that Google Groups offers when reading archived threads.
> (Google Groups archives seem broken off late and do not include
> older threads in the archive)
>
> It would be cool to have "next in thread" and "prev in thread"
> pointers to jump around between topics in the same thread.
>
What might be cool is to have an entire year, or an entire months worth
of messages downloadable in mbox or similar format.  Then you could use
your mail reader to view (which consequently may be able to give you
that threaded view).

-Jack

Re: [9fans] nice quote

[Skip Tavakkolian]

> anyone written any software recently?

i've been; though mostly in rc. in the process i (re)discovered this
idiom:

doing=`{ifs=/ echo `{echo /talking/about/it/is/more/fun}}
echo $doing

Re: [9fans] nice quote

[Iruata Souza]

On Wed, Sep 9, 2009 at 12:48 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> anyone written any software recently?

writing a new boot(8) that uses rc(1) to drive the boot process.

iru

Re: [9fans] nice quote

[Tim Newsham]

> anyone written any software recently?

some prototypes for audio servers over 9p for and shim audio device
drivers for various platforms to redirect local audio device requests to
audio servers...

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] nice quote

[Jason Catena]

Skip intoned:
>> anyone written any software recently?
>
> i've been; though mostly in rc. in the process i (re)discovered this
> idiom:
>
> doing=`{ifs=/ echo `{echo /talking/about/it/is/more/fun}}
> echo $doing

*=`{ifs=/ echo `{echo /talking/about/it/is/more/fun}}
echo $3 $4 doing that $6 $4 $2

Put that in bash's pipe and smoke it.

Jason Catena

Re: [9fans] nice quote

[Eris Discordia]

> anyone written any software recently?
> at this point it probably doesn't matter whether it was for plan 9 or not.

Me did moan. Me did code, too, the retarded way. Wrote a couple score lines
of Perl to extract bits of JavaScript out of pages at a certain site,
slightly modify them, run them, extract the links produced, and harvest the
results using wget. This to get automated access to a repository of OSTs
rather than clicking a jillion times for getting only one album. Also,
another couple score lines of Perl (for IRSSI) to auto-fetch packs from
XDCC bots.

And none of this applies to or concerns Plan 9, which may be a cause for
regret--or not.

--On Wednesday, September 09, 2009 16:48 +0100 Charles Forsyth
<forsyth@terzarima.net> wrote:

> if people would leave off moaning about moaning,
> we'd clear the space for more moaning about lisp
> although the former did have the advantage that the
> messages were shorter and didn't quote the bulk of
> all previous messages.
>
> anyone written any software recently?
> at this point it probably doesn't matter whether it was for plan 9 or not.
>

Re: [9fans] nice quote

[hiro]

> And none of this applies to or concerns Plan 9, which may be a cause for regret--or not.

There is a plan 9 OST?

Re: [9fans] nice quote

[Eris Discordia]

> There is a plan 9 OST?

The leech target contains mostly video game OSTs. For exactitude's sake I
did look for P9fOS. Not there, but if you're really into it (and heed
"piracy" not) that bit of auditory magic, and indeed the visual magic it
accompanied, is a couple clicks away from the Google home page.

And this place claims to be (legally?) selling it:
<http://www.indietective.com/indieshop/product.html;jsessionid=32633E445C8185FD62989DD87F18CD3F.ajp13-indie?do=addtocart&code=54957>

P.S. Above is nothing you didn't know.

--On Thursday, September 10, 2009 17:58 +0200 hiro <23hiro@googlemail.com>
wrote:

>> And none of this applies to or concerns Plan 9, which may be a cause for
>> regret--or not.
>
> There is a plan 9 OST?
>

Re: [9fans] nice quote

[erik quanstrom]

> term% time resample -x 1600 -y 1200 glenda.pic >/dev/null
> 36.07u 0.01s 36.21r 	 resample -x 1600 -y 1200 ...
> term% time resize -b -s 1600 1200 glenda.pic >/dev/null
> 0.91u 0.02s 1.06r 	 resize -b -s 1600 1200 ...
>
> The -b option is for bilinear interpolation.  Without that, it goes
> a bit faster but you get jaggies.
>
> term% time resize -s 1600 1200 glenda.pic >/dev/null
> 0.56u 0.03s 0.71r 	 resize -s 1600 1200 glenda.pic ...
>
> It's in /n/sources/contrib/miller/resize.c

very nice!

i modified resize to accept the same arguments as resample.
it is blistering on my machine.  unfortuntely, jpg still can't
keep up.

; time jpg -t9 2246.jpg | time resize -bx 500 | page
1.96u 0.08s 2.20r 	 jpg -t9 2246.jpg
reading through graphics...
0.06u 0.04s 2.36r 	 resize -bx 500

(a quick test shows that jpg has about the same performance
with p9p and 50% of the ticks are in colormap:1420/62424)

i have been using a script to use resample to convert
pictures as i load them from the camera.  to images the resample
on a core i7 machine can just keep up with the new usb.
(about 4mb/s.  i believe this is limited by the spi-based
media.)

the resampled images can be displaed at >50/s.  it's
amazing how fast plan 9 video is when you don't read
back from the frame buffer.  :-)

- erik

Re: [9fans] nice quote

[Richard Miller]

>> It's in /n/sources/contrib/miller/resize.c
> ...
> i modified resize to accept the same arguments as resample.
> it is blistering on my machine.

If you noticed the code is a bit fussy, it's because it was
written to use on an fpga-based soft cpu (nios2) with no
hardware divide instruction and no floating point.  It should
run pretty effortlessly on your core i7.

Re: [9fans] nice quote

[erik quanstrom]

> If you noticed the code is a bit fussy, it's because it was
> written to use on an fpga-based soft cpu (nios2) with no
> hardware divide instruction and no floating point.  It should
> run pretty effortlessly on your core i7.

it seems significantly less fussy than resample.
evidently, i didn't look too closely.

- erik