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 1 of 4 [1] 2 3 4 Next page →

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

From	Chris Seberino <cseberino@gmail.com>
Date	2015-05-10 13:43 -0700
Subject	Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses BOTH? Good idea?
Message-ID	<02dba7aa-8466-4937-a8d8-82ffd03e5568@googlegroups.com>

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.

I'm thinking half way into the semester, instead of moving into intermediate Scheme, perhaps that is a good time to switch to Python?

Would a little strong intro to 2 nice languages in one semester be
same/good/worse/better than just 1?

cs

[toc] | [next] | [standalone]

#90305

From	Mel Wilson <mwilson@the-wire.com>
Date	2015-05-10 20:59 +0000
Message-ID	<miogs6$1ub$1@dont-email.me>
In reply to	#90304

On Sun, 10 May 2015 13:43:03 -0700, Chris Seberino wrote:

> 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.
> 
> I'm thinking half way into the semester, instead of moving into
> intermediate Scheme, perhaps that is a good time to switch to Python?
> 
> Would a little strong intro to 2 nice languages in one semester be
> same/good/worse/better than just 1?

The first course I took, we learned Algol-60, then when we couldn't get 
computer time for compiles, we were asked to pick up FORTRAN-IV on the 
side.  So we "published" our solutions to the class problems in Algol and 
re-wrote them to be run in FORTRAN.  It was a fine first-hand look at 
what the "general purpose" in General Purpose Computer really meant.  
There was no confusing the machine and the language after that.  Scheme/
Python would be even more radical, I think.  If you can put them across 
effectively, I say go for it.

	Mel.
> 
> cs

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

#90309

From	Marko Rauhamaa <marko@pacujo.net>
Date	2015-05-11 00:16 +0300
Message-ID	<87wq0gyvyr.fsf@elektro.pacujo.net>
In reply to	#90304

Chris Seberino <cseberino@gmail.com>:

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

Python, in contrast, is a great introductory programming language. Sure,
you *can* get quite advanced with it, too, but you can get quite a bit
of fun stuff done with just the basics.

Of course, you could introduce Scheme with similar simplifications.
However, such simplifications (say, iterative constructs) are
nonidiomatic in Scheme. The students should not get into bad habits
that they need to be weaned off of later.

> I'm thinking half way into the semester, instead of moving into
> intermediate Scheme, perhaps that is a good time to switch to Python?

What are you teaching? If you are teaching computer science, you should
use languages to illustrate abstract ideas. Thus, Python can be used to
introduce basic control and data structures, I/O, OOP etc. Scheme should
be used to teach functional programming and maybe combinatory logic and
computability. Prolog could be used to demonstrate logic programming and
automated theorem proving. C could be used to understand the
nitty-gritties under the hood and fear of SIGSEGV.


Marko

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

#90324

From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2015-05-10 19:37 -0600
Message-ID	<mailman.333.1431308306.12865.python-list@python.org>
In reply to	#90309

On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> 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.
>
> Python, in contrast, is a great introductory programming language. Sure,
> you *can* get quite advanced with it, too, but you can get quite a bit
> of fun stuff done with just the basics.

MIT famously used Scheme in their introductory course for more than
two decades. Although they switched to Python a few years ago, I don't
think they did so because there was anything wrong with Scheme.
Wikipedia informs me that Yale and Grinnell are still using Scheme for
their introductory courses.

> Of course, you could introduce Scheme with similar simplifications.
> However, such simplifications (say, iterative constructs) are
> nonidiomatic in Scheme. The students should not get into bad habits
> that they need to be weaned off of later.

You don't need iterative constructs to teach an introductory course.
The full text of SICP (the "wizard book") is available on the web for
anyone to read at https://mitpress.mit.edu/sicp/. I don't think it
ever even *mentions* "iterative constructs". Where it distinguishes
recursive algorithms from iterative ones, recursive syntax is used in
both cases.

>> I'm thinking half way into the semester, instead of moving into
>> intermediate Scheme, perhaps that is a good time to switch to Python?

No, stick with one language for at least the first course. Needing to
learn the syntax and semantics of *two* programming languages,
especially two such different ones, is just going to distract students
from the fundamental concepts that the introductory class is intended
to teach.

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

#90420

From	beliavsky@aol.com
Date	2015-05-11 12:01 -0700
Message-ID	<ed1b5d2c-7d29-4102-b310-ee544cf033a3@googlegroups.com>
In reply to	#90324

On Sunday, May 10, 2015 at 9:38:38 PM UTC-4, Ian wrote:
> On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> > 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.
> >
> > Python, in contrast, is a great introductory programming language. Sure,
> > you *can* get quite advanced with it, too, but you can get quite a bit
> > of fun stuff done with just the basics.
> 
> MIT famously used Scheme in their introductory course for more than
> two decades. Although they switched to Python a few years ago, I don't
> think they did so because there was anything wrong with Scheme.
> Wikipedia informs me that Yale and Grinnell are still using Scheme for
> their introductory courses.

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.

http://yaledailynews.com/blog/2014/11/07/faculty-approve-cs50-for-yale/
Faculty approve CS50 for Yale

"Just under a month after announcing that Yale's computer science department was considering importing Harvard's most popular course, faculty voted to bring CS50 to Yale.

Following what Yale College Dean Jonathan Holloway described as a "long, healthy discussion," faculty at Thursday's monthly meeting voted overwhelmingly to approve CS50 as a class to be taught at Yale. Computer science department chair Joan Feigenbaum said that the next step for CS50 will be for Harvard to approve the sharing of CS50 with Yale. If the course earns approval, she noted, Yale will formally introduce the class in Fall 2015."

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

#90429

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2015-05-12 12:04 +1000
Message-ID	<55515f9d$0$12987$c3e8da3$5496439d@news.astraweb.com>
In reply to	#90420

On Tue, 12 May 2015 05:01 am, beliavsky@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...


-- 
Steven

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

#90432

From	Michael Torrie <torriem@gmail.com>
Date	2015-05-11 23:04 -0600
Message-ID	<mailman.386.1431407062.12865.python-list@python.org>
In reply to	#90429

On 05/11/2015 08:04 PM, Steven D'Aprano wrote:
> On Tue, 12 May 2015 05:01 am, beliavsky@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...

How so?  Surely starting at first principles of a computer's operation
can't be all that bad.  In my program at uni, one of the very first
level courses was actually to build a simulated CPU from logic gates and
then program it in assembly.  C is just a step up from there.  I should
note they also had Java in the first year, and that certainly caused
irreversible damage.

The wonderfulness of LISP and Python can be appreciated just fine with a
solid background in how Von Neumann architecture actually functions. In
fact I appreciate the layers of abstraction even more after I understand
them.

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

#90434

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-11 22:38 -0700
Message-ID	<b68efd25-017a-4bd4-830b-54cc79ec853b@googlegroups.com>
In reply to	#90432

On Tuesday, May 12, 2015 at 10:34:32 AM UTC+5:30, Michael Torrie wrote:
> On 05/11/2015 08:04 PM, Steven D'Aprano wrote:
> > On Tue, 12 May 2015 05:01 am, beliavsky 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...
> 
> How so?  Surely starting at first principles of a computer's operation
> can't be all that bad.  In my program at uni, one of the very first
> level courses was actually to build a simulated CPU from logic gates and
> then program it in assembly.

Thats true.
The intro to programming course needs to convey something beyond syntax
and minor details -- something like the 'Zen'

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

> C is just a step up from there.

which may be a step too much.
And I think its much more than one step. [How many links in the gcc toolchain?]

> I should note they also had Java in the first year, and that certainly caused
> irreversible damage.

A different question altogether.
What Joel Spolsky describes² is simply the fact that Java slides its
practitioners down the DIKW pyramid³

[My own record of the hell let lose by teaching too early C.⁴⁵
The first written in 91 and rather widely cited at that time including
first edition of 'Code Complete'. Second is a toning down as I grow older!
]

To some extent good teaching can ameliorate.
Only to some extent since the whole purpose of such languages is to dumb down
programming.

[And lest pythonistas feel pleased with that, do consider whether what
Spolsky applies to Java in 2005 in 2015 applies to python]
> 
> The wonderfulness of LISP and Python can be appreciated just fine with a
> solid background in how Von Neumann architecture actually functions. In
> fact I appreciate the layers of abstraction even more after I understand
> them.

modulo the law of primacy

----------------------------------------
¹ Eric Raymond almost literally says this:
| Lisp is worth learning for the profound enlightenment experience you will 
| have when you finally get it; that experience will make you a better 
| programmer for the rest of your days, even if you never actually use Lisp 

² http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

³ http://en.wikipedia.org/wiki/DIKW_Pyramid

⁴ http://www.the-magus.in/Publications/chor.pdf
⁵ http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html

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

#90435

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-11 23:42 -0700
Message-ID	<60c01c07-aef9-4232-92cd-22e6c017fc9c@googlegroups.com>
In reply to	#90434

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

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

#90436

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-12 16:57 +1000
Message-ID	<mailman.387.1431413836.12865.python-list@python.org>
In reply to	#90435

On Tue, May 12, 2015 at 4:42 PM, Rustom Mody <rustompmody@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

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

#90439

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 02:16 -0700
Message-ID	<4628bce6-98d5-44b7-bb3b-bcb796c0df77@googlegroups.com>
In reply to	#90436

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)

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

#90454

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 08:18 -0700
Message-ID	<d4559cef-69fb-4a62-a300-cde3a9e127d6@googlegroups.com>
In reply to	#90439

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.

mark

Mark

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

#90462

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 02:05 +1000
Message-ID	<mailman.400.1431446739.12865.python-list@python.org>
In reply to	#90454

On Wed, May 13, 2015 at 1:53 AM, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> zipher <dreamingforward@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

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

#90510

From	Steven D'Aprano <steve+comp.lang.python@pearwood.info>
Date	2015-05-13 11:14 +1000
Message-ID	<5552a591$0$12979$c3e8da3$5496439d@news.astraweb.com>
In reply to	#90462

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

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

#90512

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 19:02 -0700
Message-ID	<c1058d53-0ac1-40ae-bf7c-2611c3dd6863@googlegroups.com>
In reply to	#90510

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

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

#90518

From	zipher <dreamingforward@gmail.com>
Date	2015-05-12 19:47 -0700
Message-ID	<f3cc4eee-8e0d-4bd9-acd5-f08b3186b0c8@googlegroups.com>
In reply to	#90510

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

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

#90526

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 14:54 +1000
Message-ID	<mailman.428.1431492908.12865.python-list@python.org>
In reply to	#90510

On Wed, May 13, 2015 at 11:14 AM, Steven D'Aprano
<steve+comp.lang.python@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

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

#90529

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 22:56 -0700
Message-ID	<b107c4b2-9da2-465a-b323-3e47bf26cb3e@googlegroups.com>
In reply to	#90526

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

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

#90530

From	Chris Angelico <rosuav@gmail.com>
Date	2015-05-13 16:17 +1000
Message-ID	<mailman.432.1431497829.12865.python-list@python.org>
In reply to	#90529

On Wed, May 13, 2015 at 3:56 PM, Rustom Mody <rustompmody@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

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

#90531

From	Rustom Mody <rustompmody@gmail.com>
Date	2015-05-12 23:31 -0700
Message-ID	<3725fd3d-d0d7-4d07-a18a-db838e316c9a@googlegroups.com>
In reply to	#90530

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?

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

Page 1 of 4 [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

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

#90305

#90309

#90324

#90420

#90429

#90432

#90434

#90435

#90436

#90439

#90454

#90462

#90510

#90512

#90518

#90526

#90529

#90530

#90531

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

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