subject:"Re\: \[9fans\] nice quote"

In article 542783.92348...@web83904.mail.sp1.yahoo.com,
Brian L. Stuart blstu...@bellsouth.net wrote:
KR 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

In article fe41879c0909050422s77247280y4fcd7d89a621b...@mail.gmail.com,
Akshat Kumar aku...@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

In article bb8e3a2e5419e566d0361...@[192.168.1.2],
Eris Discordia eris.discor...@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

2009-09-07 Thread 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

2009-09-07 Thread 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

2009-09-07 Thread 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

2009-09-07 Thread J.R. Mauro

On Sun, Sep 6, 2009 at 2:03 PM, Rob Pike robp...@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

In article 936a4bab-7d9a-4b65-ab6a-c5eea8e43...@storytotell.org,
Daniel Lyons fus...@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

2009-09-07 Thread 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

2009-09-07 Thread 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

2009-09-07 Thread Federico G. Benavento

relax

On Mon, Sep 7, 2009 at 5:56 PM, Lyndon Nerenberg -
VE6BBM/VE7TFXlyn...@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

2009-09-07 Thread 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

2009-09-06 Thread 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


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


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



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


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

2009-09-06 Thread 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

2009-09-06 Thread David Leimbach

On Sun, Sep 6, 2009 at 10:08 AM, Eris Discordia eris.discor...@gmail.comwrote:

 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.

Re: [9fans] nice quote

2009-09-06 Thread 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

2009-09-06 Thread 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

2009-09-06 Thread James Chapman



On Sep 6, 2009, at 9:05 PM, David Leimbach wrote:
On Sun, Sep 6, 2009 at 10:08 AM, Eris Discordia eris.discor...@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.

Re: [9fans] nice quote

2009-09-06 Thread David Leimbach

On Sun, Sep 6, 2009 at 11:26 AM, Tim Newsham news...@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/

Re: [9fans] nice quote


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

2009-09-06 Thread 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

2009-09-06 Thread 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

2009-09-05 Thread 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

2009-09-05 Thread Richard Miller

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

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

Re: [9fans] nice quote

2009-09-05 Thread 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

2009-09-05 Thread 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


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

Re: [9fans] nice quote


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 
9f...@hamnavoe.com wrote:



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


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

Re: [9fans] nice quote

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


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



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


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

Re: [9fans] nice quote


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

Re: [9fans] nice quote


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



On Sat, Sep 5, 2009 at 7:27 AM, Eris Discordiaeris.discor...@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

2009-09-05 Thread 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

2009-09-05 Thread 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

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=nDWPW9uwZPACdq=%22the+first+computers%22printsec=frontcoversource=blots=Z_Kegt6Rwnsig=zrlQEVkK8z7fAmBtXsW2lx754Zohl=enei=uPqiSsDVKY-GmwPkncjAAwsa=Xoi=book_resultct=resultresnum=7#v=onepageq=branchingf=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
quans...@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.

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.

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

2009-09-05 Thread 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


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

2009-09-05 Thread 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

2009-09-05 Thread 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

2009-09-05 Thread David Leimbach

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

Re: [9fans] nice quote

2009-09-05 Thread J.R. Mauro

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

2009-09-04 Thread Greg Comeau

In article 6a3ae47e0909030757n31a8d09aoa2b2d57628a5a...@mail.gmail.com,
Robert Raschke rtrli...@googlemail.com wrote:
On Thu, Sep 3, 2009 at 3:02 PM, Greg Comeau com...@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

2009-09-04 Thread Greg Comeau

In article d50d7d460909030813u703c1292i6ae7cf10a767f...@mail.gmail.com,
Jason Catena jason.cat...@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

2009-09-04 Thread Greg Comeau

In article 561059.20730...@web83913.mail.sp1.yahoo.com,
Brian L. Stuart blstu...@bellsouth.net wrote:
 KR 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

2009-09-04 Thread Brian L. Stuart

  KR 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

2009-09-04 Thread 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

2009-09-04 Thread 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 
blstu...@bellsouth.net wrote:



  KR 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

Re: [9fans] nice quote

2009-09-04 Thread 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

2009-09-04 Thread 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

2009-09-04 Thread 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

In article 1251932394.16936.3741.ca...@work.sfbay.sun.com,
Roman V Shaposhnik r...@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

In article 3096bd910909020751o12086713m4291e2f1b77da...@mail.gmail.com,
Rodolfo kix k...@kix.es wrote:
On Wed, Sep 2, 2009 at 4:29 PM, ron minnichrminn...@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

2009-09-03 Thread 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

2009-09-03 Thread 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

2009-09-03 Thread Brantley Coile


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

On Sep 3, 2009, at 5:01 AM, tlaro...@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.

KR 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

2009-09-03 Thread 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.

KR 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

In article a879919a-6e6f-4425-a971-62946a07e...@coraid.com,
Brantley Coile brant...@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

In article 20090903120157.ga1...@polynum.com,  tlaro...@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.

KR 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