Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?

[zipher]

> > No, Common LISP does, but as the website says Common LISP is a
> > "multi-paradigm" langauge.   It's trying to be everything to everybody,
> > just like Python tried to do in the other direction, making "everything an
> > object".  Python was trying to be too pure, while LISP was trying to be
> > too universal:  be everything to everyone -- you might say "batteries
> > included".
> > 
> > True LISP [...]
> 
> Ah, the "No True Scotsman" fallacy. You know that Lisp compiler you're
> using? That's not *true* Lisp, because *true* Lisp doesn't have [insert
> feature here].

While schools use the term "variable" and there are letters like x, y, z.  These should not be considered variables in any sense that you know.  They (generally) are not assigned to.  They are placeholders holding state.  They don't change once the program starts running.
 
> > Again, you're speaking of "Common LISP".  Such a lisp also wants to do
> > OOP, but it's like lipstick on a pig.
> 
> You really love that metaphor, don't you? You keep using it, and variations
> like "a pig made of lipstick". I suggest you don't understand the metaphor.

My apologies.  I thought better after I posted the message.  It's more like putting lipstick on a *boy*.  LISP, indeed, is not a pig.

> > Yes, and LISP is neither.  Although LISP is a functional style, that is
> > only by appearance.  It's completely different from Haskell, which I would
> > describe as a true functional language.  The difference is how the program
> > is lexed in the mind or on the machine.  But that's too difficult to
> > explain on this thread.
> 
> Just because something is difficult to explain doesn't make it correct. It's
> difficult to explain how the Atlantic Ocean merely looks, tastes and feels
> like salt water while actually being filled with strawberry yoghurt. That
> doesn't make it true.
> 
> Something which is difficult to explain might be deeply profound, but is far
> more likely to be rubbish.

That's all fine and good, Steven. But the academically and politically correct thing to do in that case, is withhold judgement.  Perhaps you don't know what to do with yourself if I'm right, so your remaining recourse is to defences rather than inquiry.

> > The "opposite" of iterative programming is recursive programming.
> 
> No it isn't. Iteration and recursion are, in a very deep sense, actually the
> same thing, they're certainly not opposites. That is a fact which genuinely
> is profound.

My God, you and Lawrence have gone off the deep end.  What you're telling me is that you've never programmed something on digital hardware.  That, fucking C, you've never even counted on your FINGERS!!

> >> > And the idea of lambdas were already encoded by the use of special
> >> > expressions, set-off by parenthesis.  So they practically *defined* the
> >> > concept of lambdas.
> >> 
> >> LISP is also the reason why we're cursed with the terrible name
> >> "lambda" for anonymous functions rather than something more mnemonic
> >> (like "function").
> > 
> > No, you haven't understood, padawan.  Lambda *is* the function, not it's
> > definition.  Perhaps you will understand what I mean by that, perhaps you
> > won't.  It's subtle.
> 
> Subtle like a kick to the head.

Well, at least you got the kick.  It's only be understanding your error, can you then proceed to a greater truth.  

More concretely, programming in an iterative language is like programming f(x, y, z...), where f is the idea your wanting to implement and x,y,z are inputs.  Since the are input by user interaction, they are VARIABLE.  A type of interactive program (not a Turing tape, either I might add).

A program in LISP is simply f, or more to their nomemclature: lambda.  It's like the difference of saying f(x) = x + 1, or saying f = /x.x+1 (where "/" is the Greek lambda character). 

Do you see the subtle difference?  They both appear to have variables, but they are not the same.

To repeat myself from two years ago:  Here endeth the lesson. 

You may be seated.

> If you wish to change our minds, you're going to have to demonstrate
> objective, verifiable facts and not just allude to how your ideas are too
> subtle and clever for us.

Hopefully that helps.  But if I thought my ideas were too subtle or clever for you I wouldn't keep responding to you. 

Mark