Groups > comp.lang.python > #90304 > unrolled thread

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

Started by	Chris Seberino <cseberino@gmail.com>
First post	2015-05-10 13:43 -0700
Last post	2015-05-11 09:29 -0700
Articles	20 on this page of 68 — 17 participants

Back to article view | Back to comp.lang.python

Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →

#90517

From	Paul Rubin <no.email@nospam.invalid>
Date	2015-05-12 19:38 -0700
Message-ID	<87lhgtyzfv.fsf@jester.gateway.sonic.net>
In reply to	#90515

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> As far as I know, only one language designed from theoretical first
> principles has had any measure of mainstream success, Lisp, 

APL was cool back in the day too.

[toc] | [prev] | [next] | [standalone]

#90521

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 20:27 -0700
Message-ID	<2474c9be-caae-4c66-8892-e31a0d8346ad@googlegroups.com>
In reply to	#90515

On Tuesday, May 12, 2015 at 9:30:50 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 13 May 2015 08:00 am, zipher wrote:
> 
> > Everyone gets it wrong and now we have a plethora of languages which all
> > do the same thing, without really knowing what they want as an overarching
> > design or purpose.
> 
> 
> Why must a language be designed with some "overarching design or purpose"?

Because it's considerable work.  Why re-invent the wheel?  After all, there are plenty of Turing-complete languages out there.  No, you make one because you have an implicit or explicit goal.

> Why can't a language be designed with a *practical and concrete* need in
> mind? As far as I know, only one language designed from theoretical first
> principles has had any measure of mainstream success, Lisp,

Yes, and that was a stellar achievement.  Many language makers still compare to such a gold standard.  Even Python.  Yet it has also misled us -- it is based on a fundamentally different model of computation.

An elegant model of computation, that many high-level languages seem to try to adopt, yet they fail because they can't re-produce the elegance without becoming LISP.  So why, then, are there other programming languages that specifically try NOT to be LISP?  

Because the model of computation for most hardware is iterative.  This is also why the design goal of "everything should be an object" needs to be revisited.  It doesn't align with any model of computation.  That's fine for small problems, but when you're trying to make a p2p data model that can scale to the Internet, it becomes an issue.

> "I want to do numerical calculations" lead to Fortran.
> 
> "I want to control telescopes" lead to Forth.
> 
> "I want to teach beginners programming" lead to BASIC.

You can stop there.  You are proving my point, that there are goals to a given programming language.  If those goals are strong or noble enough, it differentiates from existing languages.  "I want to do numerical calculations" led to Fortran, which led to C because people wanted to do such calculations on many platforms.  And C syntax had the more elegant syntax ultimately (I think the increment++ operator ultimately ran Fortran over, because it was directly implementable on CPU architectures in 1 clock cycle).

"I want to control telescopes" could morph into the more general goal of "I want to make a controller programming language" and Boom, you'd have an elegant programming language for all controllers.

"I want to teach beginners programming" started at BASIC, but then led to Pascal as the limitations of BASIC became clear, but then became Python.  These are all decent design goals for a language.  Python has superceded BASIC in almost every way.

Anyway, having a design goal guides the process and helps everyone who wants to contribute know how to do so.

Mark

[toc] | [prev] | [next] | [standalone]

#90522

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 20:35 -0700
Message-ID	<a5a1345d-04e3-478e-abbd-36138ef200fd@googlegroups.com>
In reply to	#90515

On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> Why can't a language be designed with a *practical and concrete* need in
> mind? As far as I know, only one language designed from theoretical first
> principles has had any measure of mainstream success, Lisp, and that was
> probably because there weren't that many decent alternatives at the time.

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

And what it got right was more by fluke than by design

- gc because the machine word was too small for a refcount but could squeeze in a mark-bit
- Syntax: It was intended that a 'proper' (aka Algol-like) syntax was round
the corner.  The '1.5' in the lisp 1.5 manual was evidence of that interimness

To me the most mind-boggling aspect this u-turning of history is this interview 
with McCarthy: http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy

Q: Who helped you with the early ideas Lisp?
McCarthy: Backus' Fortran taught me functional programming!!!!!

[toc] | [prev] | [next] | [standalone]

#90556

From	zipher <dreamingforward@gmail.com>
Date	2015-05-13 07:44 -0700
Message-ID	<5a982567-8d89-42b0-9f47-956e61a21274@googlegroups.com>
In reply to	#90522

On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> > Why can't a language be designed with a *practical and concrete* need in
> > mind? As far as I know, only one language designed from theoretical first
> > principles has had any measure of mainstream success, Lisp, and that was
> > probably because there weren't that many decent alternatives at the time.
> 
> 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.  It's a lambda calculus 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 accomidate those coming over from iterative programming.

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.  

Mark

[toc] | [prev] | [next] | [standalone]

#90563

From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2015-05-13 09:26 -0600
Message-ID	<mailman.449.1431530832.12865.python-list@python.org>
In reply to	#90556

I don't know why I'm replying to this...

On Wed, May 13, 2015 at 8:44 AM, zipher <dreamingforward@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.

> It's a lambda calculus

No, it isn't. Lambda calculus is a formal system of mathematics. LISP
is a programming language. It may draw inspiration and borrow notation
from lambda calculus, but these are different things with different
uses and purposes.

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

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.

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

[toc] | [prev] | [next] | [standalone]

#90574

From	zipher <dreamingforward@gmail.com>
Date	2015-05-13 11:07 -0700
Message-ID	<71ee2dbb-27a3-45ad-b903-bffca6d8923f@googlegroups.com>
In reply to	#90563

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

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.  

> > It's a lambda calculus
> 
> No, it isn't. Lambda calculus is a formal system of mathematics. LISP
> is a programming language. It may draw inspiration and borrow notation
> from lambda calculus, but these are different things with different
> uses and purposes.

Again, you're speaking of "Common LISP".  Such a lisp also wants to do OOP, but it's like lipstick on a pig.

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

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

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

Mark

[toc] | [prev] | [next] | [standalone]

#90584

From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2015-05-13 15:38 -0600
Message-ID	<mailman.461.1431553152.12865.python-list@python.org>
In reply to	#90574

On Wed, May 13, 2015 at 12:07 PM, zipher <dreamingforward@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@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*

[toc] | [prev] | [next] | [standalone]

#90588

From	zipher <dreamingforward@gmail.com>
Date	2015-05-13 16:16 -0700
Message-ID	<2aecbb14-86a4-42c7-b40c-bfa93ce83185@googlegroups.com>
In reply to	#90584

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

[toc] | [prev] | [next] | [standalone]

#90585

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2015-05-13 22:55 +0100
Message-ID	<mailman.462.1431554132.12865.python-list@python.org>
In reply to	#90574

On 13/05/2015 22:38, Ian Kelly wrote:
> On Wed, May 13, 2015 at 12:07 PM, zipher <dreamingforward@gmail.com> wrote:
>>
>> 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 RUE also has a marvellous proof that the PEP 393 FSR is complete 
nonsense, but as it's so obvious to himself he's decided its not worth 
sharing with anybody else.  What with that and this thread I therefore 
conclude that both the RUE and zipher suffer from a very severe case of 
Emperor's New Clothes Syndrome.

>>
>> No, you haven't understood, padawan.
>
> *plonk*
>

You took your time over that :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#90599

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2015-05-14 11:40 +1000
Message-ID	<5553fd0e$0$12995$c3e8da3$5496439d@news.astraweb.com>
In reply to	#90574

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

[toc] | [prev] | [next] | [standalone]

#90601

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2015-05-14 03:35 +0100
Message-ID	<mailman.474.1431570976.12865.python-list@python.org>
In reply to	#90599

On 14/05/2015 02:40, Steven D'Aprano wrote:
> On Thu, 14 May 2015 04:07 am, zipher wrote:
>
>>
>> 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.
>

 From the very first drivel that he posted on python ideas just over two 
years ago, he's shown that he's incapable of any logical thought 
relating to computing, in just the same way that the RUE has never 
posted anything logical about the FSR.  Please can we stop feeding him.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#90603

From	wxjmfauth@gmail.com
Date	2015-05-14 00:38 -0700
Message-ID	<389326fb-d968-4363-bad5-9e3ab00c0139@googlegroups.com>
In reply to	#90601

Le jeudi 14 mai 2015 04:36:27 UTC+2, Mark Lawrence a écrit :
> On 14/05/2015 02:40, Steven D'Aprano wrote:
> > On Thu, 14 May 2015 04:07 am, zipher wrote:
> >
> >>
> >> 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.
> >
> 
>  From the very first drivel that he posted on python ideas just over two 
> years ago, he's shown that he's incapable of any logical thought 
> relating to computing, in just the same way that the RUE has never 
> posted anything logical about the FSR.  Please can we stop feeding him.
> 

Luckily for the users, the "new" "unicode-letters.def"
is not splitted in chunks.
For you information, this is a TeX unicode-engines related stuff.

jmf

[toc] | [prev] | [next] | [standalone]

#90716

From	zipher <dreamingforward@gmail.com>
Date	2015-05-15 20:25 -0700
Message-ID	<4e580ae1-e62d-4619-bd06-07543e1067e0@googlegroups.com>
In reply to	#90601

On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> On 14/05/2015 02:40, Steven D'Aprano wrote:
> > On Thu, 14 May 2015 04:07 am, zipher wrote:
> >
> >>
> >> 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.
> 
>  From the very first drivel that he posted on python ideas just over two 
> years ago, he's shown that he's incapable of any logical thought 
> relating to computing, in just the same way that the RUE has never 
> posted anything logical about the FSR.  Please can we stop feeding him.

The truth is quite the opposite.  There is something very strange going on around the nets.  People are very confused.  Javascript has confused them.   Tell me where is the lexer in Javascript?  or the virtual machine?

The point I'm making about LISP is that in LISP you don't define a function, it IS the function.  Instead of f(x,y) = x+y, which is how you code a traditional program, you only show/program f itself.  In the lambda calculus, it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f OF x.  Do you see why the difference is subtle? 

Java has a virtual machine.  Python has a virtual machine.  Do you think Chrome and these browsers include virtual machines to run on 50 different architectures?  I'm actually curious if anyone has a non-magical answer to it.  We all assume that computers can only act logically and have always acted such.  But they way some people act and the way somethings are being done is making questions.  Perhaps I'm the only one.

Mark

[toc] | [prev] | [next] | [standalone]

#90717

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-15 20:36 -0700
Message-ID	<adcfd61e-9c84-4120-89cf-78dff449f6a3@googlegroups.com>
In reply to	#90716

On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote:
> On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> > On 14/05/2015 02:40, Steven D'Aprano wrote:
> > > On Thu, 14 May 2015 04:07 am, zipher wrote:
> > >
> > >>
> > >> 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.
> > 
> >  From the very first drivel that he posted on python ideas just over two 
> > years ago, he's shown that he's incapable of any logical thought 
> > relating to computing, in just the same way that the RUE has never 
> > posted anything logical about the FSR.  Please can we stop feeding him.
> 
> The truth is quite the opposite.  There is something very strange going on around the nets.  People are very confused.  Javascript has confused them.   Tell me where is the lexer in Javascript?  or the virtual machine?
> 
> The point I'm making about LISP is that in LISP you don't define a function, it IS the function.  Instead of f(x,y) = x+y, which is how you code a traditional program, you only show/program f itself.  In the lambda calculus, it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f OF x.  Do you see why the difference is subtle? 
> 
> Java has a virtual machine.  Python has a virtual machine.  Do you think Chrome and these browsers include virtual machines to run on 50 different architectures?  I'm actually curious if anyone has a non-magical answer to it.  We all assume that computers can only act logically and have always acted such.  But they way some people act and the way somethings are being done is making questions.  Perhaps I'm the only one.
> 

As for chrome and its specific VM
http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29

As for the rest...
We are as confused by your confusions as you are

[Your continual assertions about everyone everywhere being totally confused
reminds me of my first trip to N America where I was unnerved to find everyone
driving on the wrong side of the road]

[toc] | [prev] | [next] | [standalone]

#90720

From	zipher <dreamingforward@gmail.com>
Date	2015-05-15 21:24 -0700
Message-ID	<16619215-1a32-49ae-962d-d5846d31702d@googlegroups.com>
In reply to	#90717

On Friday, May 15, 2015 at 10:36:45 PM UTC-5, Rustom Mody wrote:
> On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote:
> > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> > > On 14/05/2015 02:40, Steven D'Aprano wrote:
> > > > On Thu, 14 May 2015 04:07 am, zipher wrote:
> > > >
> > > >>
> > > >> 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.
> > > 
> > >  From the very first drivel that he posted on python ideas just over two 
> > > years ago, he's shown that he's incapable of any logical thought 
> > > relating to computing, in just the same way that the RUE has never 
> > > posted anything logical about the FSR.  Please can we stop feeding him.
> > 
> > The truth is quite the opposite.  There is something very strange going on around the nets.  People are very confused.  Javascript has confused them.   Tell me where is the lexer in Javascript?  or the virtual machine?
> > 
> > The point I'm making about LISP is that in LISP you don't define a function, it IS the function.  Instead of f(x,y) = x+y, which is how you code a traditional program, you only show/program f itself.  In the lambda calculus, it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f OF x.  Do you see why the difference is subtle? 
> > 
> > Java has a virtual machine.  Python has a virtual machine.  Do you think Chrome and these browsers include virtual machines to run on 50 different architectures?  I'm actually curious if anyone has a non-magical answer to it.  We all assume that computers can only act logically and have always acted such.  But they way some people act and the way somethings are being done is making questions.  Perhaps I'm the only one.
> > 
> 
> As for chrome and its specific VM
> http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29
> 
> As for the rest...
> We are as confused by your confusions as you are
> 
> [Your continual assertions about everyone everywhere being totally confused
> reminds me of my first trip to N America where I was unnerved to find everyone
> driving on the wrong side of the road]

Thanks for that note, actually, it's quite apropos.  I'm a space cowboy who's trying to tell people what I've seen from "outside the fishbowl".  To those in the fishbowl, they don't think that they're in water, because they've never been outside of it--the concept doesn't exist.  But I left the orthodoxy (without throwing it away) and saw from the outside.  Zen is one of the nodal points of that outside.  And from that view, I can tell you that Python has abandoned much of it`s Zen to the point that is now only held by the programmers who still believe in it like some lost ancient tablet that they keep in their pocket.

It can come back easily, though.  One conversation in person with a whiteboard would do it.  I'm starting to see why I'm seen as such an iconoclast:  I've been outside of it for a long time and have taken it for granted -- I couldn't see my own "water".  Oh well.  Maybe the relationship will be mended with the community, or maybe not.  My psychological states go from one extreme to another, so that's my "thing" in case anyone was wondering what my issue is--it's happened ever since getting tazered.  It sucked.

Mark

[toc] | [prev] | [next] | [standalone]

#90626

From	zipher <dreamingforward@gmail.com>
Date	2015-05-14 11:48 -0700
Message-ID	<a81a81f9-a5aa-4760-aa8c-e910d05eae48@googlegroups.com>
In reply to	#90599

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

[toc] | [prev] | [next] | [standalone]

#90581

From	Marko Rauhamaa <marko@pacujo.net>
Date	2015-05-13 22:50 +0300
Message-ID	<87egmkw937.fsf@elektro.pacujo.net>
In reply to	#90563

Ian Kelly <ian.g.kelly@gmail.com>:

> LISP is also the reason why we're cursed with the terrible name
> "lambda" for anonymous functions rather than something more mnemonic
> (like "function").

The only terrible aspect of "lambda" is how difficult it is to type.

BTW, Common Lisp actually has an operator called "function": <URL:
http://www.lispworks.com/documentation/HyperSpec/Body/s_fn.htm>.


Marko

[toc] | [prev] | [next] | [standalone]

#90644

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-14 20:14 -0700
Message-ID	<12b5b082-c04f-405f-baa1-ff5a53122b53@googlegroups.com>
In reply to	#90556

On Wednesday, May 13, 2015 at 8:14:39 PM UTC+5:30, zipher wrote:
> On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> > On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> > > Why can't a language be designed with a *practical and concrete* need in
> > > mind? As far as I know, only one language designed from theoretical first
> > > principles has had any measure of mainstream success, Lisp, and that was
> > > probably because there weren't that many decent alternatives at the time.
> > 
> > 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.  It's a lambda calculus 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 accomidate those coming over from iterative programming.
> 
> 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.  

See
https://groups.google.com/forum/#!msg/haskell-cafe/gDwF__-HMXE/oCKCbco2bS8J

| I asked McCarthy was the use of the LAMBDA notation in Lisp because the 
| language was functional, or was it just a convenient notation for anonymous 
| functions?  His answer was short and very definitive: he said it was a
| convenient notation --- *he didn't consider Lisp to be a functional language.*

[toc] | [prev] | [next] | [standalone]

#90534

From	Gregory Ewing <greg.ewing@canterbury.ac.nz>
Date	2015-05-13 19:19 +1200
Message-ID	<crgc83F71evU1@mid.individual.net>
In reply to	#90515

Steven D'Aprano wrote:

> "I want to do numerical calculations" lead to Fortran.
> 
> "I want to control telescopes" lead to Forth.

I don't think those things led to their respective languages
in the same way. The notation that mathematicians use for
numerical calculations had a clear influence on the syntax
of Fortran. But there's nothing about controlling telescopes
that makes the structure of Forth particularly suited to it.

I think there *is* a design principle behind Forth: the
desire to keep everything as simple as possible. It's a
lot like Lisp in that respect.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#90336

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-10 19:33 -0700
Message-ID	<2a0d3025-94bd-4aa9-96e8-61ef9fc0dcc9@googlegroups.com>
In reply to	#90309

On Monday, May 11, 2015 at 2:46:38 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Seberino :
> 
> > Instead of learning only Scheme or only Python for a one semester
> > intro course, what about learning BOTH? Maybe that could somehow get
> > the benefits of both?
> >
> > I'm thinking that for the VERY beginning, Scheme is the fastest
> > language to get beginners up and running writing code due to the
> > extremely minimal simple syntax.
> 
> Scheme is my favorite language. I think, however, it is a pretty
> advanced language and requires a pretty solid basis in programming and
> computer science.

Have you seen this?
http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/

Yeah from a certain pov scheme is so advanced that even Abelson and Sussman dont
quite get it: http://blog.languager.org/2013/08/applying-si-on-sicp.html
So (from that pov) how reasonable is it to expect students to get it?

Also good to see:
http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →

csiph-web

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

Contents

#90517

#90521

#90522

#90556

#90563

#90574

#90584

#90588

#90585

#90599

#90601

#90603

#90716

#90717

#90720

#90626

#90581

#90644

#90534

#90336

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