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

[zipher]

On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote:
> On Wed, May 13, 2015 at 12:07 PM, zipher <dreamingforward at gmail.com> wrote:
> > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote:
> >> I don't know why I'm replying to this...
> >
> > Because you're trying to get an answer to a question that even Academia hasn't answered or understood.
> >
> >> On Wed, May 13, 2015 at 8:44 AM, zipher <dreamingforward at gmail.com> wrote:
> >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> >> >> How history U-turns!!
> >> >> Lisp actually got every major/fundamental thing wrong
> >> >> - variables scopes were dynamic by mistake
> >> >> - lambdas were non-first class because the locution 'first-class' was still 8
> >> >> years in the future
> >> >
> >> > I think you're confused.  LISP doesn't have variables.
> >>
> >> Yes, it does.
> >
> > 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, doesn't need a 'let' statement for example.  To understand true LISP you have to understand the modus operandi of the "lambda the ultimate" crowd.  Very few do from academic computer science.  MIT understands it.  You think you understand it, but you don't.
> 
> By "true LISP" are you referring to the original specification by John
> McCarthy? Here's an example lambda S-expression from McCarthy's
> original paper:
> 
> (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), (COND, (EQ, Y,
> Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, (SUBST, X, Y, (CAR Z)),
> (SUBST, X, Y, (CDR, Z)))))))
> 
> Ugh, what a mess. But ignoring that, tell us how many variables you
> see there. I'll give you a hint: I count more than two.

LoL, it's an interesting example you've thrown up there.  It's more than just a mess though.  The problem is the use of the quote.  I was hoping you wouldn't include it.  The problem is that its a compromise to interact with your mental-visual lexer.  It's like Javascript which runs on no virtual machine anyone's heard of.  It's too magical.
 
> Sure. Lisp machines never, ever ran computer graphics applications. Or
> medical image processing. Nope, never, because that would be
> commercial and dirty and a hideous perversion of the idol of computer
> science created by the prophet McCarthy. Text editors? Heavens to
> Betsy, now you're just trying to shock me, aren't you!

CLISP =/= LISP. 
 
> > 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.
> 
> And Fermat had a truly marvelous proof, which you would think
> wonderful, if only he had enough room in that infamous margin.

Ha, you know, I actually think I found the proof he alleges.  You have to visualize the problem geometrically.

> Iteration is a type of recursion. Specifically, it's the type of
> recursion that doesn't require keeping a stack of values from each
> higher-up repetition in the evaluation.  
> Also known as "linear
> recursion" or "tail recursion".

You are so confused, it boggles.  Can anyone else assert this?

Mark