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

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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote:
 On Tue, May 12, 2015 at 9:11 PM, zipher dreamingforw...@gmail.com wrote:
  I know.  That's because most people have fallen off the path 
  (http://c2.com/cgi/wiki?OneTruePath).
 
 You wrote that, didn't you? I recognize that combination of delusional
 narcissism and curious obsession with Turing machines.

Damn straight.  But to call the reference to Turing machines delusional, means 
you've already been captured by the first enemy on the Path.  (cf. Javascript!)

  You haven't done it because either others have done it for you (NumPy) or 
  you simply aren't perfecting anything that needs to scale; i.e. you don't 
  really need to minimize memory or CPU consumption because you're working 
  with toy problems relative to the power of most hardware these days.
 
 There is such a thing as over-optimization. Given unlimited programmer
 time, sure, everything might be made to run using the minimum possible
 time and space.

You don't need to teach me these basics.  If you had read the document, you 
would have seen that I already had assimilated the lessons of [Master] Jon 
Bentley.  I know about over-optimization, however, if you had followed my other 
posts, you would also know that I'm attempting something that will require some 
interest in the underlying hardware at some point.  Or, perhaps let's say, it's 
just my personal (unique?) preference not to create bloatware.

mark
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Ian Kelly

On Wed, May 13, 2015 at 12:07 PM, zipher dreamingforw...@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 dreamingforw...@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*
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Mark Lawrence


On 13/05/2015 22:38, Ian Kelly wrote:

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

--
https://mail.python.org/mailman/listinfo/python-list

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

On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote:
 On Wed, May 13, 2015 at 12:07 PM, zipher dreamingforw...@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 dreamingforw...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Ian Kelly

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

On Wed, May 13, 2015 at 8:44 AM, zipher dreamingforw...@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).
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Mark Lawrence


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

--
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread 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 dreamingforw...@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

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

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 dreamingforw...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Grant Edwards

On 2015-05-12, Marko Rauhamaa ma...@pacujo.net wrote:
 zipher dreamingforw...@gmail.com:

 That is why you have very high-level languages that allow you to
 rapidly prototype ideas, test them, and then, depending all the other
 constraints, move them to lower-level language implementations.

 Finally an argument to tackle. That rapid prototyping role is often
 mentioned as a strong point of high-level languages. However, I can't
 remember personally doing that.

I've done that on several occasions: develop and debug an algorithm or
protocol using Python, then re-write it in C once I'm happy with the
way it works.  Those instances are not for desktop use, though.  They
final app has to run on an embedded system that has zero chance of
ever supporting Python.

-- 
Grant Edwards   grant.b.edwardsYow! YOU PICKED KARL
  at   MALDEN'S NOSE!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Rustom Mody

On Wednesday, May 13, 2015 at 10:25:18 AM UTC+5:30, Chris Angelico wrote:
 On Wed, May 13, 2015 at 11:14 AM, Steven D'Aprano wrote:
  On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:
 
  So if you're writing a library function, it probably shouldn't use
  print()... but your application is most welcome to. You usually know
  which one you're writing at any given time.
 
  You might be, but beginners are not.
 
 I meant the generic you there. A beginner may well not know whether
 to use / or //, whether it's better to use a list or a dict, etc etc
 etc. That's what instructors are for. Make the distinction that
 library functions shouldn't use print but application code can, and
 then examples like this...
 
  I'm not sure I accept Rustom's fix for the problem (I think that his cure is
  worse than the disease), but it is *hard* to get some beginners to use
  return instead of print:
 
  def add_twice(x, y):
  Add twice y to x.
  print x + 2*y
 
 
  sort of thing.
 
 ... can be answered simply by explaining that add_twice ought to be
 written as a library function rather than an application. It's the
 exact same answer as this:

And later

 Yep. I'd also use clear function/procedure names to make it more
 visible, and probably tie this in with loops to show how you can print
 more than one thing but can only return one. (Generators are a more
 advanced topic.)

[Structure of] Library function: basic
Generator: advanced

?¿?¿

If you ask me that's sdrawkcab
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Chris Angelico

On Wed, May 13, 2015 at 3:56 PM, Rustom Mody rustompm...@gmail.com wrote:
 Yep. I'd also use clear function/procedure names to make it more
 visible, and probably tie this in with loops to show how you can print
 more than one thing but can only return one. (Generators are a more
 advanced topic.)

 [Structure of] Library function: basic
 Generator: advanced

 ?¿?¿

 If you ask me that's sdrawkcab

You think that generators are less advanced than the notion of code reuse??

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Rustom Mody

On Wednesday, May 13, 2015 at 11:47:19 AM UTC+5:30, Chris Angelico wrote:
 On Wed, May 13, 2015 at 3:56 PM, Rustom Mody  wrote:
  Yep. I'd also use clear function/procedure names to make it more
  visible, and probably tie this in with loops to show how you can print
  more than one thing but can only return one. (Generators are a more
  advanced topic.)
 
  [Structure of] Library function: basic
  Generator: advanced
 
  ?¿?¿
 
  If you ask me that's sdrawkcab
 
 You think that generators are less advanced than the notion of code reuse??
 

Notion of code reuse -- easy
Writing reusable code -- hard
Certainly much harder than writing working useful generators.

Do remember that historical and pedagogical order dont necessarily match.
A C programmer would say integers (scalars) are easy, lists are hard.
Not a notion necessary or useful in python

Let's just close this (for now) Chris with this:

You are in all likelihood a better programmer than I.
It so happens I have directly or indirectly taught near to 2000 students in 
about 25 years.

Lets reopen this conversation when you reach ⅓ that number, ok?
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Gregory Ewing


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

--
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Rustom Mody

On Wednesday, May 13, 2015 at 9:17:48 AM UTC+5:30, Ian wrote:
 On Tue, May 12, 2015 at 9:11 PM, zipher  wrote:
  I know.  That's because most people have fallen off the path 
  (http://c2.com/cgi/wiki?OneTruePath).
 
 You wrote that, didn't you? I recognize that combination of delusional
 narcissism and curious obsession with Turing machines.

Interestingly saw this (CACM) the other day:

http://www.tomandmaria.com/Tom/Writing/CACMActuallyTuringDidNotInventTheComputer.pdf

non-delusional and in the opposite direction:

Turing's is a paper on mathematical logic. It describes a
thought experiment, like Schrödinger's famous 1935 description of
a trapped cat shifting between life and death in response to the
behavior of a single atom. Schrödinger was not trying to advance
the state of the art of feline euthanasia. Neither was Turing
proposing the construction of a new kind of calculating machine.
As the title of his paper suggested, Turing designed his
ingenious imaginary machines to address a question about the
fundamental limits of mathematical proof. They were structured
for simplicity, and had little in common 
with the approaches taken by people 
designing actual machines. 

Von Neumann's report said nothing explicitly about mathematical
logic. It described the architecture of an actual planned
computer and the technologies by which it could be realized, and
was written to guide the team that had already won a contract to
develop the EDVAC. Von Neumann does abstract away from details of
the hardware, both to focus instead on what we would now call
architecture and because the computer projects under way at the
Moore School were still classified in 1945. His letters from that
period are full of discussion of engineering details, such as
sketches of particular vacuum tube models and their performance
characteristic
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-13 Thread Marko Rauhamaa

Ian Kelly ian.g.ke...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 11:09:01 AM UTC+5:30, Rustom Mody wrote:

 The difference between C/Lisp (I club them together) and python is that
 the former are more heroic.
 
 Like mountain climbing you can get a high, a thrill, even 'see God'¹ but
 you can also break your back or worse.
 
 Python is by contrast like a walk in the park.  If you find it interesting
 (for reasons outside of python) you can get the job done. No epiphanies here

Just to be clear the No epiphanies is entirely positive.
Around 2002 I started teaching python.
Around the same time I started using an open editor rather than blackboard
to teach.
And for the most part python has been a trusted friend -- even if I dont
know the code I will write beforehand and the bugs and the debugging and so on.
[I remember one time getting completely screwed by regular expressions
And more recently some confusion re dunder methods. but these are the exception
 to the rule that mostly python is quite reliable.
]

The reason I am saying this (to OP):
Which language you choose may not matter too much.
But choose one you are sufficiently friendly with to start hacking with an
open editor in front of the class

Scheme?? I used scheme in the 80s -- ie before the age of projectable editor
So while *in principle* it may seem as reliable as python
In practice when I read racket today I find it far more forbidding than the PC
scheme manuals I read in the 80s

The other suggestion I would make: Use an interactive interpreter.

Even if I were using C today, I'd find a C interpreter.
And never mind that it messes up 10% of 'official' C semantics.
You'll breeze through the remaining 90% at 3⨯ the rate

And related to that (and one reason a pure functional language is good for 
pedagogy): NO PRINT statement
It may seem trivial but beginning students have a real hard writing clean
structured code.  Tabooing prints helps get there faster
And working in the interpreter makes a print-taboo a viable option
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tue, May 12, 2015 at 4:42 PM, Rustom Mody rustompm...@gmail.com wrote:
 And related to that (and one reason a pure functional language is good for
 pedagogy): NO PRINT statement
 It may seem trivial but beginning students have a real hard writing clean
 structured code.  Tabooing prints helps get there faster
 And working in the interpreter makes a print-taboo a viable option

I firmly disagree. Interactive work is well and good, but print (or
equivalent - console.log, log.info, werror, etc etc) is extremely
useful for learning about a larger application. You can play with
things at the terminal, but how can you find out exactly what happens
when you click this button? Ensuring that your application can be
imported, executed, and manipulated interactively, all without
breaking its primary purpose, is a LOT of extra work, and not
something I'd recommend to beginners. So learn about print, learn
about how to get info out of a running program. You'll be the better
programmer for it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Wed, May 13, 2015 at 1:53 AM, Stefan Ram r...@zedat.fu-berlin.de wrote:
 zipher dreamingforw...@gmail.com writes:
so what kind of bullshit is saying that you should get rid of PRINT?

   What might be reasonable is to be able to dissect a program
   into functions, and have no effects in functions that are
   there to calculate some value.

   For example, when one calculates,

 y = sin( x )

   , using a library function »sin«, one does not want »sin« to
   print something.

   Such library functions might even be used in code for a GUI
   that has no console to print to at all.

   In order to learn how to write such functions, one might
   temporarily use the rule that PRINT is allowed only in the
   main block (not in functions) or temporarily for debugging.

More generally, there are certain things which belong to the
application, and not to any library - things like:

* The console - print() and input(), and GUI windows
* Command-line arguments
* Program termination
* Working directory and root directory
* Credentials (uid/gid, etc)
* Logging configuration (destinations etc)

There are exceptions; argument parsing libraries often are granted
control over the console and program termination in addition to
reading sys.argv, but you would be somewhat surprised if having
--no-check-ssl-certs in sys.argv silently downgraded your HTTP
library's security settings. Control over application-wide settings
generally has to be in the hands of the application, not any one
library.

So if you're writing a library function, it probably shouldn't use
print()... but your application is most welcome to. You usually know
which one you're writing at any given time.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Wed, May 13, 2015 at 3:03 AM, Rob Gaddi
rgaddi@technologyhighland.invalid wrote:
 A firm grasp of C will make you a better programmer in any language, even
 if you haven't written a line of it in 20 years.  It's the ability to
 read a map.  A lack of C is the person blindly following their GPS and
 hoping for the best.

That's as may be, but I would still not recommend it as a first
language. It's possible to explain algorithmic complexity with a high
level language; Python's data types generally have predictable costs
associated with them, although a lot of them aren't actually language
guarantees (I could imagine a Python implementation using an O(log n)
tree instead of an amortized O(1) hash table for its dict, if other
tradeoffs make it worthwhile); at any rate, you can always just
construct your own fundamental data structures if you want to teach
what a linked list is good for, or what a splay tree can do for you. C
knowledge is good, but first get to know the broader art of
programming, and then get to know C. Learning low-level languages too
soon will end up binding your mind to a particular CPU architecture.
That happened to me in a big way; I got to thinking about everything
in terms of how an 80x86 CPU would deal with it, without any
comprehension of some of the modern aspects of low-level programming
like pipeline management and cache locality. It was quite the
eye-opener when I started hand-optimizing my C compiler's output on a
more modern chip, and found that my improvements... uhh, added about
50% to the run time. That's when I stopped doing any assembly language
work, and just let the compiler do its magic :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Rob Gaddi

On Tue, 12 May 2015 08:11:25 -0700, zipher wrote:

 On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote:
 On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote:
 
  Yale has taken the unusual step of outsourcing its introductory CS
  class to Harvard, which uses C as the main language in its CS50
  class.
 
 And another generation of new programmers will be irreversibly damaged
 by exposure to C...
 
 Come on, C is perfect for computer engineering students.  For CS
 students, it's of mixed value.

And that's how you train CS students to write inefficient code that takes 
orders of magnitude longer to run than it should.

Is that a true array or a linked list?  It's a high level language, 
that's just an implementation detail. Yes, but it's an implementation 
detail that determines whether even the simple act of looking up element 
n is O(1) or O(n).

C teaches you the language of the computer.  Understanding it allows you 
to grasp what your high-level code is actually doing, and why and when a 
list (array) is more efficient than a dict (hashtable).  Because you've 
written a dynamically resizing list, and learned the perils of having to 
realloc() as the size grows.  And you've written a hashtable, and 
understand the expense of the hashing function, and the tradeoffs between 
wasted memory and having to wade at O(n) pace through a linked list of 
collision candidates.

A firm grasp of C will make you a better programmer in any language, even 
if you haven't written a line of it in 20 years.  It's the ability to 
read a map.  A lack of C is the person blindly following their GPS and 
hoping for the best.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Mark Lawrence


On 12/05/2015 07:42, Rustom Mody wrote:


And related to that (and one reason a pure functional language is good for
pedagogy): NO PRINT statement
It may seem trivial but beginning students have a real hard writing clean
structured code.  Tabooing prints helps get there faster
And working in the interpreter makes a print-taboo a viable option



If students can't be taught to distinguish print from other parts of the 
language they should get themselves onto a course teaching semi-skilled 
light bulb fitting.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
 On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote:
  On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote:
   On Tue, May 12, 2015 at 4:42 PM, Rustom Mody  wrote:
And related to that (and one reason a pure functional language is good 
for
pedagogy): NO PRINT statement
It may seem trivial but beginning students have a real hard writing 
clean
structured code.  Tabooing prints helps get there faster
And working in the interpreter makes a print-taboo a viable option
   
   I firmly disagree.
  
  Yes we know that!
  
  As it happens you also disagree with ACM's latest CS curriculum:
 
 I/O is an essential part of computing in the West.  (I'll leave Symbolics out 
 of of that category.)  It started with switches and lights, so what kind of 
 bullshit is saying that you should get rid of PRINT?  ACM must have gotten 
 confused or steamrolled by one of its members.

In the West? WEST??
Did I hear that right?

My profound genuflections to the Mark-modified Michaelson-Morley result.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote:
 Rob Gaddi writes:
 Is that a true array or a linked list?  It's a high level language, 
 that's just an implementation detail. Yes, but it's an implementation 
 detail that determines whether even the simple act of looking up element 
 n is O(1) or O(n).
 
   The complexity is given in the documentation of high-level languages.
 
   For example, from the documentation of the Java standard library:
 
   »This implementation provides constant-time performance
   for the basic operations (get and put),« (java.util.HashMap)
 
   C++:
 
   Section 23.2.1 specifies the complexity, such as »compile time«,
   »constant«, »linear« for container operations.
 
   But the abstraction mechanisms (templates, polymorphism)
   often allow one to change the implementation quite easily.

This is regarded in some circles as one of the big open problems in CS
https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/
[and the position paper therein]
viz how to integrate the elegance of high-level languages
with the precision of complexity analysis of machine language
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Wed, May 13, 2015 at 3:15 AM, Stefan Ram r...@zedat.fu-berlin.de wrote:
 Rob Gaddi rgaddi@technologyhighland.invalid writes:
Is that a true array or a linked list?  It's a high level language,
that's just an implementation detail. Yes, but it's an implementation
detail that determines whether even the simple act of looking up element
n is O(1) or O(n).

   The complexity is given in the documentation of high-level languages.

   For example, from the documentation of the Java standard library:

   »This implementation provides constant-time performance
   for the basic operations (get and put),« (java.util.HashMap)

   C++:

   Section 23.2.1 specifies the complexity, such as »compile time«,
   »constant«, »linear« for container operations.

   But the abstraction mechanisms (templates, polymorphism)
   often allow one to change the implementation quite easily.

It isn't always given in the docs. Sometimes it's not even a promise;
back when MicroPython was debating the implementation of Unicode
strings, there was a lengthy discussion on python-dev about whether
it's okay for string subscripting to be O(n) instead of O(1), and the
final decision was that yes, that's an implementation detail. (UTF-8
internal string representation, so iterating over a string would still
yield characters in overall O(n), but iterating up to the string's
length and subscripting for each character would become O(n*n) on
uPy.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Mark Lawrence


On 12/05/2015 18:35, Rustom Mody wrote:

On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:


I/O is an essential part of computing in the West.  (I'll leave Symbolics out 
of of that category.)  It started with switches and lights, so what kind of 
bullshit is saying that you should get rid of PRINT?  ACM must have gotten 
confused or steamrolled by one of its members.


In the West? WEST??
Did I hear that right?



I prefer this[1]

quote
Each object has to figure out how it will receive things from outside
of it.  Things it can't handle (a string sent to an int) just have to
be dropped to some other space, much like stderr does within the O.S.

There are probably many other very interesting examples, but the key
idea I'm working on (as noted in other messages), is a sort-of
universal language for the internet, a WebOS to be applied to a
universal data model.
/quote

I'd guess that the concept is in the same boat as Python 2.8 or 
RickedPython, but I suspect that these two have far more chance of 
making it into the real world than a sort-of universal language for the 
internet, a WebOS to be applied to a universal data model


[1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Marko Rauhamaa

Chris Angelico ros...@gmail.com:

 That's as may be, but I would still not recommend [C] as a first
 language.

I think the field can be approached from many angles successfully. And
any approach will fail many students.

The nice thing about C is that your feet are firmly on the ground.
There's little magic. You can then abstract your concrete knowledge of C
to higher-level concepts.

In fact, going the other way could be harder. I'm thinking the lofty
abstractions like objects will remain sort of mysteries without an
experience with a low-level language.

That's why first-graders are not given education in abstract algebra or
category theory. They are first taught elementary arithmetics. The lofty
concepts are abstracted from the low-level concepts and not the other
way around. (I had a feeling in high-school that math was easy. In the
university, I had the opposite experience: I hadn't understood a thing
in high-school. However, the elementary wrong knowledge was a stepping
stone to the correct understanding.)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Steven D'Aprano

On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:

 So if you're writing a library function, it probably shouldn't use
 print()... but your application is most welcome to. You usually know
 which one you're writing at any given time.

You might be, but beginners are not.

I'm not sure I accept Rustom's fix for the problem (I think that his cure is
worse than the disease), but it is *hard* to get some beginners to use
return instead of print:

def add_twice(x, y):
Add twice y to x.
print x + 2*y


sort of thing.

Personally, I think that banning print is only useful if you wish to
encourage cargo-cult programming:

Don't use print! 
Why not?
My CS lecture said not to use it! I dunno, maybe it has a virus or
something.


I'd rather give them exercises designed to show (rather than tell) the
differences between printing a result and returning a result, and how they
effect re-usability of software components and function chaining. Using a
procedural language is *perfect* for that, since you can highlight the
differences:

function foo(n:int): int;
  begin
foo := n+1;
  end;

procedure foo(n:int);
  begin
writeln(n+1);
  end;



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Wednesday, May 13, 2015 at 6:45:07 AM UTC+5:30, Steven D'Aprano wrote:
 On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:
 
  So if you're writing a library function, it probably shouldn't use
  print()... but your application is most welcome to. You usually know
  which one you're writing at any given time.
 
 You might be, but beginners are not.
 
 I'm not sure I accept Rustom's fix for the problem (I think that his cure is
 worse than the disease), but it is *hard* to get some beginners to use
 return instead of print:
 
 def add_twice(x, y):
 Add twice y to x.
 print x + 2*y
 
 
 sort of thing.
 
 Personally, I think that banning print is only useful if you wish to
 encourage cargo-cult programming:
 
 Don't use print! 
 Why not?
 My CS lecture said not to use it! I dunno, maybe it has a virus or
 something.

:-)

[And more real than you know --- every medicine has a side-effect]
Just to be be clear about the framing -- though it does not work too well
across Usenet --
I would suggest to TEACHERS to not use/show print TOO EARLY

Something like cigarettes: 
You dont ban children from smoking. You ban adults from setting up tobacco
shops near schools

 procedural language is *perfect* for that, since you can highlight the
 differences:
  
 function foo(n:int): int;
   begin
 foo := n+1;
   end;
  
 procedure foo(n:int);
   begin
 writeln(n+1);
   end; 

This cuts both ways
Python much more than Pascal can make the 1st possible because of data
structures in general being first class

Unfortunately python culture across the net is laissez faire about using the
2nd -- I am demoing SMTP protocol... Does print or no print really have anything
to do with it?

When you give the procedure foo vs function foo example, you are jumping across 
the levels of familiarity and usage to assessment/evaluation.

Shall I use an if or a while?
Shall I use a list or a dict?
Shall I use immutable + or mutable extend/append? 
:
:
And a dozen other more fundamental things to assess.

If I could count the number of times a beginner hangs an else onto a while...
Students dont 'Not get it' because they are asses but because they are at a
firehose.  The asses are the adults who stand by and keep turning on the 
pressure
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Steven D'Aprano

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?

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.


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.

I want to teach beginners good programming lead to Pascal.

I want to generate webpages on the fly lead to PHP.

I want to write interactive fiction and text-based games lead to Inform.

And so forth.




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Paul Rubin

Steven D'Aprano steve+comp.lang.pyt...@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.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 8:15:07 PM UTC-5, Steven D'Aprano wrote:
 On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:
 
  So if you're writing a library function, it probably shouldn't use
  print()... but your application is most welcome to. You usually know
  which one you're writing at any given time.
 
 You might be, but beginners are not.
 
 I'm not sure I accept Rustom's fix for the problem (I think that his cure is
 worse than the disease), but it is *hard* to get some beginners to use
 return instead of print:
 
 def add_twice(x, y):
 Add twice y to x.
 print x + 2*y
 
 
 sort of thing.
 
 Personally, I think that banning print is only useful if you wish to
 encourage cargo-cult programming:
 
 Don't use print! 
 Why not?
 My CS lecture said not to use it! I dunno, maybe it has a virus or
 something.

No, no, no.  There's a very simple reason that you don't put extraneous I/O 
into your functions:  you want your functions to be as general as possible for 
the given focus for re-usability.  Otherwise, why write as a separate function? 
 It's called separability of domains.

See Hacking with the Tao:  http://wiki.hackerspaces.org/Hacking_with_the_Tao.

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote:
 On Tue, May 12, 2015 at 4:42 PM, Rustom Mody  wrote:
  And related to that (and one reason a pure functional language is good for
  pedagogy): NO PRINT statement
  It may seem trivial but beginning students have a real hard writing clean
  structured code.  Tabooing prints helps get there faster
  And working in the interpreter makes a print-taboo a viable option
 
 I firmly disagree.

Yes we know that!

As it happens you also disagree with ACM's latest CS curriculum:
https://www.acm.org/education/CS2013-final-report.pdf [pg 158]
Absolute basics of CS include functional programming; among which first point 
is 'effect-free programming'
[Note there is no mention or commitment to fancy functional programming 
*languages*, just the principles]

 Interactive work is well and good, but print (or
 equivalent - console.log, log.info, werror, etc etc) is extremely
 useful for learning about a larger application.

You are talking phd level (or maybe graduate level)
I am talking kindergarten

 You can play with things at the terminal,

Very important to play before you grow up

 but how can you find out exactly what happens
 when you click this button? Ensuring that your application can be
 imported, executed, and manipulated interactively, all without
 breaking its primary purpose, is a LOT of extra work, and not
 something I'd recommend to beginners. So learn about print, learn
 about how to get info out of a running program. You'll be the better
 programmer for it.

Maybe you should read up on Bloom's taxonomy
[ACM curriculum follows this but simplified from 5 to 3 levels -- familiarity,
usage, assessment]

In particular wrt print: You are not distinguishing
- learning the 'what' of print (familiarity)
from
- learning the how (usage)
and most important the when not (assessment)

-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Marko Rauhamaa

zipher dreamingforw...@gmail.com:

 That is why you have very high-level languages that allow you to
 rapidly prototype ideas, test them, and then, depending all the other
 constraints, move them to lower-level language implementations.

Finally an argument to tackle. That rapid prototyping role is often
mentioned as a strong point of high-level languages. However, I can't
remember personally doing that. Rather, you want to use the right
programming language for any given role.

Bash has really concise idioms as long as you stay within its comfort
zone. When you need finer-grained control, a bash program quickly
becomes very tacky. I have had to rewrite bash components in Python for
that reason. What is gained is clarity of expression at the cost of 2 to
5 times more code. And where performance is an issue, C does the job
nicely.

The end result is a system with bash, Python and C components that
interact through the regular linux IPC mechanisms.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 12:57:48 PM UTC-5, Rustom Mody wrote:
On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote:
Rob Gaddi writes:
Is that a true array or a linked list? It's a high level language,
that's just an implementation detail. Yes, but it's an implementation
detail that determines whether even the simple act of looking up element
n is O(1) or O(n).

The complexity is given in the documentation of high-level languages.

For example, from the documentation of the Java standard library:

»This implementation provides constant-time performance
for the basic operations (get and put),« (java.util.HashMap)

C++:

Section 23.2.1 specifies the complexity, such as »compile time«,
»constant«, »linear« for container operations.

But the abstraction mechanisms (templates, polymorphism)
often allow one to change the implementation quite easily.

This is regarded in some circles as one of the big open problems in CS
https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/
[and the position paper therein]
viz how to integrate the elegance of high-level languages
with the precision of complexity analysis of machine language

The answer is you don't. You *don't* because you can't. And you *can't*
because you don't know what you want to do yet.

That is why you have very high-level languages that allow you to rapidly
prototype ideas, test them, and then, depending all the other constraints, move
them to lower-level language implementations.

So don't try it. 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.

Mark
--
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 1:22:55 PM UTC-5, Mark Lawrence wrote:
 On 12/05/2015 18:35, Rustom Mody wrote:
  On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
 
  I/O is an essential part of computing in the West.  (I'll leave Symbolics 
  out of of that category.)  It started with switches and lights, so what 
  kind of bullshit is saying that you should get rid of PRINT?  ACM must 
  have gotten confused or steamrolled by one of its members.
 
  In the West? WEST??
  Did I hear that right?
 
 
 I prefer this[1]
 [1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html
 Mark Lawrence

I was trying to differentiate models of computing.  Perhaps you don't know the 
concept.  I'll refer you to http://c2.com/cgi/wiki?ModelsOfComputation.  One 
might think that they ALL originated from Western Civ, but not quite.

Yes, I was sounding little too enthusiastic in that post.

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Tuesday, May 12, 2015 at 5:24:34 PM UTC-5, Marko Rauhamaa wrote:
 zipher dreamingforw...@gmail.com:
 
  That is why you have very high-level languages that allow you to
  rapidly prototype ideas, test them, and then, depending all the other
  constraints, move them to lower-level language implementations.
 
 Finally an argument to tackle. That rapid prototyping role is often
 mentioned as a strong point of high-level languages. However, I can't
 remember personally doing that. Rather, you want to use the right
 programming language for any given role.

I know.  That's because most people have fallen off the path 
(http://c2.com/cgi/wiki?OneTruePath).  You haven't done it because either 
others have done it for you (NumPy) or you simply aren't perfecting anything 
that needs to scale; i.e. you don't really need to minimize memory or CPU 
consumption because you're working with toy problems relative to the power of 
most hardware these days.

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

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

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!
-- 
https://mail.python.org/mailman/listinfo/python-list

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

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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2015-05-12 Thread Ian Kelly

On Tue, May 12, 2015 at 9:11 PM, zipher dreamingforw...@gmail.com wrote:
 I know.  That's because most people have fallen off the path 
 (http://c2.com/cgi/wiki?OneTruePath).

You wrote that, didn't you? I recognize that combination of delusional
narcissism and curious obsession with Turing machines.

 You haven't done it because either others have done it for you (NumPy) or you 
 simply aren't perfecting anything that needs to scale; i.e. you don't really 
 need to minimize memory or CPU consumption because you're working with toy 
 problems relative to the power of most hardware these days.

There is such a thing as over-optimization. Given unlimited programmer
time, sure, everything might be made to run using the minimum possible
time and space. Nobody has unlimited time, though. The job of the
programmer is to get the program to run fast enough for the needs of
the application. Getting it to run faster than it needs to is
generally a waste of the programmer's time that could be spent on more
valuable tasks.

Of course, I say this as somebody who works on a highly scaled
user-facing application that will never be fast enough. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Wed, May 13, 2015 at 11:14 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:

 So if you're writing a library function, it probably shouldn't use
 print()... but your application is most welcome to. You usually know
 which one you're writing at any given time.

 You might be, but beginners are not.

I meant the generic you there. A beginner may well not know whether
to use / or //, whether it's better to use a list or a dict, etc etc
etc. That's what instructors are for. Make the distinction that
library functions shouldn't use print but application code can, and
then examples like this...

 I'm not sure I accept Rustom's fix for the problem (I think that his cure is
 worse than the disease), but it is *hard* to get some beginners to use
 return instead of print:

 def add_twice(x, y):
 Add twice y to x.
 print x + 2*y


 sort of thing.

... can be answered simply by explaining that add_twice ought to be
written as a library function rather than an application. It's the
exact same answer as this:

def find_all_whatevers(base_dir):
whatevers = []
os.chdir(base_dir)
for fn in os.listdir():
if fn is a whatever: whatevers.append(fn)
if fn is a directory: whatevers.extend(find_all_whatevers(fn))
return whatevers

The working directory belongs to the application, not to a library
function, so this shouldn't use os.chdir(), even though it does spare
you the effort of string manipulation. (Of course, a real-world
version of this should use os.walk(), but that's a complete rewrite.)

The precise boundary between reusable functions and the actual
application isn't always easy to draw, and there'll be times when you
refactor something across that line. That's not a problem. There are
still plenty of cases that are clear enough to use for explanation.

 Personally, I think that banning print is only useful if you wish to
 encourage cargo-cult programming:

 Don't use print!
 Why not?
 My CS lecture said not to use it! I dunno, maybe it has a virus or
 something.

Agreed. There are VERY few features which should be utterly and
totally banned, and they're usually kept only for backward
compatibility with a time when people didn't know how dangerous they
were. In Python, the only one I can think of is Py2's input(), which
should be treated as XKCD 292 treats GOTO. (If you really *do* want to
take a string from the user and immediately eval it, just write it as
eval(raw_input()) so everyone knows.) C has gets(), which is
similarly dangerous and has a similarly straight-forward replacement.
PHP has register_globals (or did until recently - it took a long time
to go from default is on, we recommend you turn it off through
default is off, we recommend you don't turn it on to finally bad
feature is removed). Beyond those, there's not much that doesn't have
at least _some_ reason for existing.

 I'd rather give them exercises designed to show (rather than tell) the
 differences between printing a result and returning a result, and how they
 effect re-usability of software components and function chaining. Using a
 procedural language is *perfect* for that, since you can highlight the
 differences:

 function foo(n:int): int;
   begin
 foo := n+1;
   end;

 procedure foo(n:int);
   begin
 writeln(n+1);
   end;

Yep. I'd also use clear function/procedure names to make it more
visible, and probably tie this in with loops to show how you can print
more than one thing but can only return one. (Generators are a more
advanced topic.) A few examples go a long way.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote:
 On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote:
 
  Yale has taken the unusual step of outsourcing its introductory CS class
  to Harvard, which uses C as the main language in its CS50 class.
 
 And another generation of new programmers will be irreversibly damaged by
 exposure to C...

Come on, C is perfect for computer engineering students.  For CS students, it's 
of mixed value.
-- 
https://mail.python.org/mailman/listinfo/python-list

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