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

[Steven D'Aprano]

On Thu, 14 May 2015 04:07 am, zipher 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 [...]

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

If you really want to justify your claim that Lisp has no variables, you can
start by answering two questions:

(1) What is the definition of "variable" you are using?

(2) What *objective* methods of distinguishing a "True" Lisp from an
false/fake/faux/counterfit Lisp are there?


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

Your suggestion that the people and companies that created Lisp machines
weren't interested in commercial applications for Lisp is very naive.


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

"Lipstick on a pig" is not a metaphor for combining two things which are
unrelated, or that shouldn't go together. It is a metaphor for the
impossibility of turning something of low value (a pig) into high value
just by applying a few cosmetic changes.

"Lipstick on a pig" would describe giving a wax and polish to a lemon of a
car. It might be all shiny and clean, but it still won't go. It might
describe putting a coarse, rough, uncultured thug in a suit and tie, or
putting a weak and under-powered text editor like Windows Notepad in a
fancy GUI -- it's still weak and underpowered, Aero interface or not.

So by your metaphor, Lisp is the pig (i.e. a useless, weak, unpleasant and
disagreeable programming language) and OOP is a mere cosmetic change that
doesn't change the fact that Lisp is useless and unpleasant. Is that the
message you want to give?


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

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. Saying that Lisp isn't actually functional but
merely is so "only by appearance" is as profound as saying that the
Atlantic isn't filled with water, it only appears to be filled with water.


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

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.


> It's 
> not limited, except that it has an entirely different relationship to
> data, one orthogonal to iterative computation.

That's *not even wrong*.


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

Mark, you seem to be labouring under the delusion that we don't agree with
you because we "boneheads" don't understand what you are talking about.
That's wrong. We understand what you are talking about. We don't agree with
you because half of your thesis is wrong and the other half is not even
wrong.

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.



-- 
Steven