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

[Ian Kelly]

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.

> It's only abstractions, like math.  It's purpose is to output a final result, that is all.  It's not at all to make commercial applications.  It's rather like Asimov's computer in the Last Question.  It's a whole different model of computation.  Instead of a Turing Tape or VonNeumann stream, you have hierarchies of expressions all evaluating...
>
> ...well I would say all at the same time, but since I have to constrain my description to a common set of reality that is shared with you, then I'd say "on the stack frame".  It's why they had specialized machines to run true LISP.

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!

>> > with an entirely different model computation than other programming languages which use variables all the time.  To the extent that it DOES have variables, it's to accommodate those coming over from iterative programming.
>>
>> What is "iterative programming"? If you mean "writing programs that
>> work iteratively", then this describes both functional and procedural
>> styles alike.
>
> 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.

>> The opposite of "iterative programming" would then be a style where
>> the program can't ever repeat anything. That would be a very limited
>> language and would *not* be equivalent to a Turing machine.
>
>
> The "opposite" of iterative programming is recursive programming.  It's not limited, except that it has an entirely different relationship to data, one orthogonal to iterative computation.

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

Often people use the word "iteration" to mean a syntactic construct
that repeats itself without explicit reference to a function and
"recursion" to mean a syntactic construct where a function explicitly
repeats itself, but from a theoretical standpoint this is all just
syntax. The two constructs are fundamentally the same.

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

*plonk*