Textbooks on Perl/Python
Jalab
Any help in finding a university level textbook on the subject of
"Scripting languages" I am mainly looking for a book that covers Perl
and Python only as the 2 main scripting languages and that is written
for students, i.e. chapter summary, exercises, etc. I hate to force my
student to buy and study from two separate books.
Any ideas?
Thanks.
-- WHA
Erik Max Francis
> Any help in finding a university level textbook on the subject of
> "Scripting languages" I am mainly looking for a book that covers Perl
> and Python only as the 2 main scripting languages and that is written
> for students, i.e. chapter summary, exercises, etc. I hate to force my
> student to buy and study from two separate books.
I doubt you'll find one that will really cover both subjects adequately,
since they're totally different languages. The only thing I can think
of that comes close is the "little language" books, that give a brief
summary of a wide variety of "little," high-level languages. The one
I'm familiar with (though I don't own it) is _HPL: Little Languages and
Tools_ by Salus (editor).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Things are as they are because they were as they were.
\__/ Thomas Gold
Bosskey.net: Return to Wolfenstein / http://www.bosskey.net/rtcw/
A personal guide to Return to Castle Wolfenstein.
Cameron Laird
Erik Max Francis <m...@alcyone.com> wrote:
>Jalab wrote:
>
>> Any help in finding a university level textbook on the subject of
>> "Scripting languages" I am mainly looking for a book that covers Perl
>> and Python only as the 2 main scripting languages and that is written
>> for students, i.e. chapter summary, exercises, etc. I hate to force my
>> student to buy and study from two separate books.
>
>I doubt you'll find one that will really cover both subjects adequately,
>since they're totally different languages. The only thing I can think
>of that comes close is the "little language" books, that give a brief
>summary of a wide variety of "little," high-level languages. The one
>I'm familiar with (though I don't own it) is _HPL: Little Languages and
>Tools_ by Salus (editor).
.
.
I'm plenty opinionated on this subject.
There isn't such a book as Jalab wants. It'd be great
fun to write one, but there isn't a market ... well, I'll
just say such a book doesn't exist now.
What's your goal for the students? To be ready to go out
in industry and solve problems? To understand the theory
and practice of industrial-strength "scripting languages"?
To pad their résumés? To safety-proof them so they
don't hurt themselves the first time they're asked to
write a dynamic Web page? To supplement an academic course
on DSLs? I know what *I*'d do in each case--and they're
not all the same answer.
I'm all for people buying *Little Languages and Tools*,
incidentally.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Raymond Hettinger
> student to buy and study from two separate books.
>
> Any ideas?
Why not force your students to download and study
some of the high quality, free on-line tutorials that
are available for both languages?
Raymond Hettinger
Alessandro Bottoni
I do not know about Perl (I just keep myself away from it, if possible).
Regarding Python there are at least two very good
beginner's level books:
Learning Python
Mark Lutz + David Ascher
O'Reilly
Learn to program using Python
Alan Gauld
Addison Wesley
Neither one of them includes exercises or any other feature specifically
intended for university students, unfortunately.
There is also a project devoted to make Python _the_ language for educational
purposes. You will find the related documentation at www.python.org.
BTW, this would be an opportunity to write such a book, maybe as a collective
effort coordinated by the educational SIG (special interest group) of python,
maybe starting from the very good book of Alan Gauld. This approach could
cope with the small market available for the book.
(Here, I suppose you need a book devoted to programming with Perl or Python,
not a book on creating language interpreters).
---------------------
Alessandro Bottoni
Alex Martelli
> Alle 23:53, venerdì 1 novembre 2002, Jalab ha scritto:
>> Greetings all,
>> Any help in finding a university level textbook on the subject of
>> "Scripting languages" I am mainly looking for a book that covers Perl
>> and Python only as the 2 main scripting languages and that is written
>> for students, i.e. chapter summary, exercises, etc. I hate to force my
>> student to buy and study from two separate books.
>>
>
> I do not know about Perl (I just keep myself away from it, if possible).
> Regarding Python there are at least two very good
> beginner's level books:
>
> Learning Python
> Mark Lutz + David Ascher
> O'Reilly
>
> Learn to program using Python
> Alan Gauld
> Addison Wesley
>
> Neither one of them includes exercises or any other feature specifically
> intended for university students, unfortunately.
One that does include exercises and IS slanted towards university
students, particularly ones just learning to program with Python
as a first language, is Deitel and Deitel's "Python How to Program".
I'm ambivalent about it -- I was a tech reviewer so cannot be
unbiased, I guess. On the minus side (from my POV), it's HUGE
(I like smaller books better than larger ones) and some of the
advice and framing it gives is more appropriate to other
languages (more "static" than Python) than to Python itself. On
the plus side, it's quite thorough and, well, didactic. I'm
helping a friend, bright but not a programmer, learn programming
with Python, and she tells me that, while she liked Gauld's book,
when it was done she felt still far from secure with Python and
with programming -- good on the overall view, scarce, from her
point of view, on the nitty-gritty. She's now proceeding with
"How to think like a computer scientist" (Python edition) from
the net, and so far is pretty happy about how it complements
Gauld's text, with more details &c. But if one wants just one
book, this seems to count as a defect of Gauld's text; Deitel
and Deitel, I think, would not suffer from it -- if and when a
student manages to work all through it, I think the student WILL
feel pretty confident in their mastery of the subject.
Another book worth mentioning in this context is Magnus Lie
Hetland's "Practical Python". Again I can't be unbiased about
it (because I was a technical reviewer for it, too, AND because
I think of Magnus as a friend though we've never met face to
face). It does lack chapter exercises, and it IS a pretty big
book, but I like the informal, communication-rich style, and I
think it's didactically very valid. Half the book (the half I
didn't tech-review) is made up of completely worked-out
*significant* examples: if one appreciates this didactical
device, it's hard to find it better used than in Magnus' book
(personally, I'm of two minds about it; overall I think I prefer
many small toy examples rather than fewer larger significant
ones, but I surely know many people whose preferences are for
examples that are actually useful working programs).
But this still doesn't answer the OP's request for a book that
teaches BOTH Perl and Python, particularly one with all the
typical devices used in university textbooks, such as per-chapter
exercises. I don't think such a book exists, and for a good
reason: tiny demand. Not for the 'exercises' part, which would
be a good thing to consider for anybody writing textbooks, of
course. No, the problem is with having a single book teach two
disparate languages. I have a few such books and invariably they
gather dust somewhere in the back rows of my shelves... by
trying to do two things at once, they generally can't do either
as well as a book that focuses on just one of them.
> BTW, this would be an opportunity to write such a book, maybe as a
> collective effort coordinated by the educational SIG (special interest
> group) of python, maybe starting from the very good book of Alan Gauld.
> This approach could cope with the small market available for the book.
And where would you find the volunteers, experienced AND happy
with both Perl and Python, to do the writing? Quite a few
Pythonistas do have Perl experience, but few have any _liking_
for it (there are surely exceptions, such as our homonym who's
now working for our previous employer, but I have my doubts that
there are enough of them...).
> (Here, I suppose you need a book devoted to programming with Perl or
> Python, not a book on creating language interpreters).
A book with a definitely-tiny market BUT perhaps enough enthusiasm
level among prospective authors to make it a reality would indeed
be one explaining how to write interpreters in C and Java, using
Classic Python and Jython as the worked-out examples;-).
Alex
Alessandro Bottoni
> > BTW, this would be an opportunity to write such a book, maybe as a
> > collective effort coordinated by the educational SIG (special interest
> > group) of python, maybe starting from the very good book of Alan Gauld.
> > This approach could cope with the small market available for the book.
>
> And where would you find the volunteers, experienced AND happy
> with both Perl and Python, to do the writing? Quite a few
> Pythonistas do have Perl experience, but few have any _liking_
> for it (there are surely exceptions, such as our homonym who's
> now working for our previous employer, but I have my doubts that
> there are enough of them...).
Right! I was thinking to a book completely devoted to Python, actually.
>
> > (Here, I suppose you need a book devoted to programming with Perl or
> > Python, not a book on creating language interpreters).
>
> A book with a definitely-tiny market BUT perhaps enough enthusiasm
> level among prospective authors to make it a reality would indeed
> be one explaining how to write interpreters in C and Java, using
> Classic Python and Jython as the worked-out examples;-).
I agree. I bought a few different books regarding compiler and interpreters
building and I never found a really _usable_ one. It would be the kind of
work I greatly appreciate. I met (on the net) someone who was writing a book
on interpreter building based on Java (both as the implementation language
and the target one). I asked him about the expected publishing date two years
ago and he told me that it was late. Maybe now it is available...
---------------------
Alessandro Bottoni
Magnus Lyckå
Honestly, I don't know if there is such a thing. Most
books about Python are listed at:
http://www.python.org/cgi-bin/moinmoin/PythonBooks
Both Perl and Python book as usually practical guides
or reference books for practicioners, rather than
school books. Neither language has typically been on
the curriculum. (Although I think this will change.)
There is Perl to Python Migration by Martin C. Brown,
but that's hardly what you are looking for...
Otherwise I think your best bet might be some Linux
programming book. But that won't be school books exactly...
Python: Visual QuickStart Guide by Chris Fehily is a
fairly cheap Python book, if you are worried about
costs. It's not a typical school book though.
A book commonly used for teaching Python is "Learning
Python", by Lutz / Archer, but it's slightly dated.
How to Think Like a Computer Scientist: Learning with Python
by Allen Downey, Jeffrey Elkner, Chris Meyers teaches
basic programming skills using Python, but that's not
really what you are looking for I guess. It's probably
the only book about Python written with students as the
prime target. It's rather a high school book though. It's
also on the web http://www.greenteapress.com/thinkpython.html
You could also have a look at web sites like
http://diveintopython.org/
I hope you find something suitable...
Michael Hudson
> if and when a student manages to work all through it, I think the
> student WILL feel pretty confident in their mastery of the subject.
("it" is Deitel & Deitel's Python : How To Program)
My concern was that the student might feel confident in the subject
after reading the book, but that this might not be justified. It does
cover a huge amount of material, but not with enormous depth (at
least, not in the chapters *I* tech reviewed).
It's also expensive, if you were one of the three or four regular
posters to this list who didn't get a review copy :)
Cheers,
M.
--
[3] Modem speeds being what they are, large .avi files were
generally downloaded to the shell server instead[4].
[4] Where they were usually found by the technical staff, and
burned to CD. -- Carlfish, asr
Aahz
>Alex Martelli <al...@aleax.it> writes:
>>
>> if and when a student manages to work all through it, I think the
>> student WILL feel pretty confident in their mastery of the subject.
>
>("it" is Deitel & Deitel's Python : How To Program)
>
>My concern was that the student might feel confident in the subject
>after reading the book, but that this might not be justified. It does
>cover a huge amount of material, but not with enormous depth (at
>least, not in the chapters *I* tech reviewed).
My concerns were primarily teaching of poor coding techniques (e.g. use
of magic numbers instead of well-named constants) and an approach that I
can best describe as Python written by a Java programmer (rather than
teaching a Pythonic approach).
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Project Vote Smart: http://www.vote-smart.org/
Chris Gonnerman
From: "Aahz" <aa...@pythoncraft.com>
> In article <m27kfsm...@python.net>, Michael Hudson <m...@python.net>
wrote:
> >Alex Martelli <al...@aleax.it> writes:
> >>
> >> if and when a student manages to work all through it, I think the
> >> student WILL feel pretty confident in their mastery of the subject.
> >
> >("it" is Deitel & Deitel's Python : How To Program)
> >
> >My concern was that the student might feel confident in the subject
> >after reading the book, but that this might not be justified. It does
> >cover a huge amount of material, but not with enormous depth (at
> >least, not in the chapters *I* tech reviewed).
>
> My concerns were primarily teaching of poor coding techniques (e.g. use
> of magic numbers instead of well-named constants) and an approach that I
> can best describe as Python written by a Java programmer (rather than
> teaching a Pythonic approach).
I was one of the technical reviewers for this book, and
frankly I wasn't impressed. They only asked me for review
of factual information, not presentation or style; and I
feel it is the latter two that torpedo this book.
My favorite (so far) is Steve Holden's "Python Web Programming."
It covers a lot of territory and includes a lot of neat stuff.
Also enjoyable to read.
I realize that several other bright people on this list are
or have written books recently; I just haven't read them yet...
Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net
Aahz
Chris Gonnerman <chris.g...@newcenturycomputers.net> wrote:
>
>I was one of the technical reviewers for this book, and frankly
>I wasn't impressed. They only asked me for review of factual
>information, not presentation or style; and I feel it is the latter two
>that torpedo this book.
That's all they asked me for, too, but I gave 'em my opinions, anyway.
(Big surprise, right? ;-)
Alex Martelli
...
> My favorite (so far) is Steve Holden's "Python Web Programming."
> It covers a lot of territory and includes a lot of neat stuff.
>
> Also enjoyable to read.
As it happens, one thing I did just yesterday was get a birthday
present for a friend, bright but a newbie to programming in general,
who's studying Python -- and upon mature deliberation what I ordered
was indeed Steve's book. Said friend has done some HTML authoring,
and I think Steve's coverage of many technologies relevant to web
programming as well as Python will be quite helpful to her, and she'll
also appreciate (I think) Steve's knack for friendly explanations and
his readable style.
However, this thread started with a request for a *college-oriented*
textbook, including, in particular, exercises for each chapter, some
with the solution being also given in the book, some without; and
Steve's book does not qualify in that respect, while Deitel and
Deitel's does (though it seems from this thread that, out of the many
technical reviewers of the book, I'm more positive about the way it
finally came out than most others; I wonder how many other posters
to this thread have actually gone to the trouble of checking the
way the book did finally come out -- quite a bit better than the
last few drafts that were widely circulated among reviewers, IMHO,
although I'll be the first to admit that it's far from perfect).
Alex
Chris Gonnerman
From: "Alex Martelli" <al...@aleax.it>
> However, this thread started with a request for a *college-oriented*
> textbook, including, in particular, exercises for each chapter, some
> with the solution being also given in the book, some without; and
> Steve's book does not qualify in that respect, while Deitel and
> Deitel's does (though it seems from this thread that, out of the many
> technical reviewers of the book, I'm more positive about the way it
> finally came out than most others; I wonder how many other posters
> to this thread have actually gone to the trouble of checking the
> way the book did finally come out -- quite a bit better than the
> last few drafts that were widely circulated among reviewers, IMHO,
> although I'll be the first to admit that it's far from perfect).
Textbooks aren't designed to be entertaining, true; but frankly
I found it painful to read in the final form. The content isn't
the first thing one notices about a book; rather it's the
presentation (cover, art, paper, etc.)
The pages are nasty slick stuff, and the fonts are IMHO poorly
chosen for readability. I haven't gone back and looked at the
review copy to see if it's the same or not, but I don't remember
it being so hard to look at.
It's just a dang ugly book, in my opinion; and then on top of
that it's a hard read. Sure, it may be suitable for a Python
class at college, but my advice to the prospective victim (I
mean student) is to get Steve's book also and read it first.
Then you'll hardly have to look at the Dietel book most of the
course.
Alex Martelli
...
> It's just a dang ugly book, in my opinion; and then on top of
> that it's a hard read. Sure, it may be suitable for a Python
> class at college, but my advice to the prospective victim (I
> mean student) is to get Steve's book also and read it first.
> Then you'll hardly have to look at the Dietel book most of the
> course.
Nolo contendere -- except that some students may prefer
Magnus Hetland's "Practical Python" (aPress) instead of
Steve's book. (I'm equally biased towards both, since I
tech-reviewed both and both Magnus and Steve are my friends;-).
Steve introduces many other technologies that an accomplished
web programmer needs to understand something about, including
networks, HTTP, HTML, relational databases, etc; and develops
one large, powerful framework for programming asynchronous
webpages that rely on a relational DB. Magnus develops ten
not-quite-as-large rich, complete examples, in a wide variety
of different fields. If you like fully-worked-out significant
examples, either book should gladden your heart; if the web is
what you most care about, then particularly if you don't feel
quite secure about its various technologies Steve's book may
be preferable -- if you care about a wider range of things
(with some web programming, but not just that), Magnus' variety
may be preferable. Steve has the advantage of being of English
mother-tongue (he's British but has been living and working in
the US for years, so no "jarring" Britishisms should give any
problems even to native-US'ers), while Magnus, like me, has
English has a second language (I don't notice that as producing
any significant difference -- but then, I guess I wouldn't, not
being of English mother tongue myself).
Both books are BIG, in good part due to the fully worked
out significant examples. As a personal taste, I prefer
SMALL books, and I prefer toy examples rather than "fully
worked out significant ones" (e.g., the kind of examples
found in Eckel's or Lippmann's books are much more to my
didactical tastes than those found in Stroustrup's...).
For readers that share my tastes, it may be worth waiting
for the next edition of Lutz and Ascher's "Learning
Python", O'Reilly -- the current edition is very good but
alas limited to Python 1.5.2, the next one will no doubt
cover 2.2. You pays your money and you makes your choice...!
Alex
Martin Elster
At the University of Oslo there is currently a course which teaches
Python, Perl and some Bash. The professor, H. P. Langtangen, has written
a textbook called "Scripting Tools for Scientific Computations". The
book hasn't been published yet, but there exists a preliminary version
which the students are using. I like it. You might want to check out the
course homepage (in Norwegian):
or take a look at the course notes (in English), which cover alot and
will give you a good idea of what the book is like:
http://www.ifi.uio.no/in228/lecsplit/index.html
If this seems interesting I suggest you get in touch with the
professor/author. You'll find his email address at the course homepage.
Good luck.
Martin
Ben Wiedermann
> Textbooks aren't designed to be entertaining, true; but frankly
> I found it painful to read in the final form. The content isn't
> the first thing one notices about a book; rather it's the
> presentation (cover, art, paper, etc.)
I was one of the authors of the Deitel book; but just to be clear: I
am speaking as a Python evangelist. I am not speaking for any of my
coauthors or for my employer. That being said...
One of the major goals for the book was to try to push Python down
into CS1 courses, where I believe it deserves far more consideration
than it currently receives. Our hope was that the book would
demonstrate to professors how well suited Python is as a first
programming language *and* how easy it is for novice programmers to
create more complex applications (e.g., GUI, multimedia, etc.).
However, I've noticed that most of the post-publication criticism of
the book has focused on issues like presentation, art, etc. It's not
my job to dispute these claims. I personally believe that an author
should stay out of subjective discussions of his book, once that book
has been published. But I still very much believe in the promise of
Python in the university. And because the Deitel book is the only
college textbook of which I am aware, I wanted to get some feedback on
what would make a more successful Python textbook. How high does
presentation rank when considering a book? Are there examples of other
college textbooks that people think do an excellent job in the
presentation department? What kinds of materials can we (as a
community) produce to get schools to consider and adopt Python as a
first programming language? Any other thoughts on Python in the
university?
Dave Reed
> Date: 6 Nov 2002 14:27:28 -0800
At the February 2002 SIGCSE conference there was a panel discussion on
using Python in the traditional CS 1 course. There were a few people
there already using it and obviously most of the other people
attending the discussion were intrigued enough to come. Everyone using
Python alread spoke very positively about it.
I've been using Python for my own projects (from short scripts to
25,000 line apps) for almost three years now and can't imagine using
anything else right for anything that wasn't extremely computationally
expensive. After attending the panel, I talked my other colleagues
into using it for our CS 1 course this fall. The only thing that
bothers me about Python for teaching is the lack of enforced private
members for classes. As an experienced programmer, I can live with
that because I know better, but I don't know whether the students will
believe me when I tell them it's a bad idea to directly access them
outside of classes :-) I also suspect this issue may prevent other
universities from seriously considering Python for introductory
courses. Every publisher rep that stopped by my office this fall had
never heard of Python and didn't think they had any Python textbooks
but most of them ended up sending me some Python book that they
published in hopes I might use it even though none of them were really
textbooks.
We're using a prepublication copy of a Python textbook written by
someone else at the SIGCSE panel discussion. I won't mention his name
or school until I check with him, but I really like his textbook. It
is not a "teach every concept of Python book", but rather a
traditional problem solving/design CS 1 textbook that uses Python. I
did take a quick look at the Deitel & Deitel book, but have to admit I
never liked any of their books for a CS 1 course and the Python one
didn't change my mind. I haven't looked at it since last spring so I
can't be very specific but the presentation style didn't do anything
for me and I think it's way too big for a CS 1 textbook - there's no
way I'm going to cover all that in CS 1 and I think the students find
it intimidating.
We were previously using C++ for our CS 1 course and have a Java
course that students could take after CS 1 and CS 2 in C++. As a side
note, I'm also teaching the Java course this semester and the more I
use Python the more I dislike Java. While I have not done any formal
studies, I can certainly say that Python is working much better than
C++ did. Fewer students have dropped and a larger percentage of
students registered for CS 2 than in past years. We did start with
fewer CS 1 students this year - I suspect mainly because the tech
downturn has discouraged those used to see CS as a quick way to get
rich and weren't really interested/excited by it.
In the past I would be swamped during office hours with students
wanting help deciphering C++ compiler errors. This semester almost
nobody has stopped by for syntax issues. The only reason they stop by
now is for problem solving/algorithm help. The indentation certainly
does not bother students who don't know any other way. The students
appear to enjoy it more and we can solve more interesting/complex
problems in Python than C++ at the CS 1 level. Also, because of the
simpler syntax, we've been able to spend more time in class working on
problem solving and design issues.
I'm also going to use Python in CS 2. My current plans are to use a
C++ CS 2 textbook and rewrite many of the examples in Python and then
supplement other topics with my own notes and the Python version of
"How to Think Like a Computer Scientist". I will also teach them a
little C++ as we go along.
I'd love to hear from anyone else using Python in CS 1 and/or CS 2 and
I'd love to see a Python CS 2 textbook so I don't have to write one :-)
Generating a list of the colleges/universities using Python would be a
good start to possibly convincing others to give it a try.
Dave
ACalcium
>bothers me about Python for teaching is the lack of enforced private
>members for classes. As an
Why can u teach this in CS2 when they learn
their 2nd programming language?
I think Python as a first language is a good idea.
They can always build on this knowledge.
Anton Vredegoor
wrote:
>presentation department? What kinds of materials can we (as a
>community) produce to get schools to consider and adopt Python as a
>first programming language? Any other thoughts on Python in the
>university?
Just to repond to the "other thoughts" part: "Combinatorial
Algorithms" by Kreher and Stinson is a fascinating book, and I
regularly use it as a resource for programming algorithms. The
algorithms are notated in a kind of pseudo computer language that is
very easy to convert to python. There is a webpage for the book where
one can download some C sourcecode implementing the algorithms. Seeing
these beautiful algorithms converted to C sends shudders down my
spine.
Starting from these C-sources sometimes but mostly using the pseudo
algorithms in the book I am slowly converting each algorithm in the
book to python. Since this process is driven by the occasions that I
need a specific algorithm it's pace is determined by my progress on
the path of leaning combinatorial algorithms. Sometimes I imagine
however how incredibly good an argument for python the book could
become if the pseudo code would be replaced by python, or, failing
that, if the webpage would also provide python versions of the
algorithms.
AV.
Robin Munn
>
> Why can u teach this in CS2 when they learn
The word is "you", not "u".
You may not know this yet, but the rest of the Internet is *nothing*
like AOL. We prefer complete English words here, and "cute"
abbreviations like "2" for "to" (or "too"), "4" for "for", and "u" for
"you" just make the writer appear juvenile and immature. I'm not saying
that you *are* juvenile or immature, but that's how using those words
will make you appear.
The only shorthand that is commonly accepted and used on the broader
Internet is appreviations of entire words, like "FYI" for "for your
information" or "BTW" for "by the way".
HTH. ("Hope this helps"). HAND. ("Have a nice day").
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
Dave Brueck
> I've been using Python for my own projects (from short scripts to
> 25,000 line apps) for almost three years now and can't imagine using
> anything else right for anything that wasn't extremely computationally
> expensive. After attending the panel, I talked my other colleagues
> into using it for our CS 1 course this fall. The only thing that
> bothers me about Python for teaching is the lack of enforced private
> members for classes. As an experienced programmer, I can live with
> that because I know better, but I don't know whether the students will
> believe me when I tell them it's a bad idea to directly access them
> outside of classes :-)
Who cares if they believe you though, and why should they anyway? Part of
becoming a good programmer is getting bit by taking shortcuts (over doing
it the "right" way), learning from it, and moving on - and it's a great
thing to learn through experience that the prof might actually know what
he's talking about! :)
> I also suspect this issue may prevent other universities from seriously
> considering Python for introductory courses.
Yeah, but in reality it shouldn't. Up-and-coming programmers routinely
ignore what we consider to be even the most basic best practices. I mean,
what first year (or any year, for that matter!) languages force people to
use good variable names, limit their use of global variables, avoid magic
numbers, and stay away from creating 1000-line functions?
Anyway, it was exciting for me to read your observations so far from using
Python at the university level, especially the idea that more
problem-solving time is being spent in "algorithm space" than "syntax
space" (which shouldn't surprise me since that's the experience Python
users tend to have). I'd love to hear more of what you learn as time goes
on - please keep posting!
-Dave
Michael Hudson
> I mean, what first year (or any year, for that matter!) languages
> force people to [snip] stay away from creating 1000-line functions?
If any language does this, it would be Python...
Cheers,
M.
--
MGM will not get your whites whiter or your colors brighter.
It will, however, sit there and look spiffy while sucking down
a major honking wad of RAM. -- http://www.xiph.org/mgm/
CShannon
course -- designed for both majors and non-majors alike. There are a
number of good python reference books around. Most of them are not
appropriate as text books however because they have few examples and
often no exercises. I like a book that is moderate in size. Books
often have more material than can be covered in a single semester but
it shouldn't be so large (or expensive) as to intimidate all but the
bravest of souls. In my course, students are also expected to buy a
text dealing with social/ethical issues.
I realize the problem of course. In my class we do cover all the
introductory material, and object oriented programming, but we also
use VPython for graphics and write some cgi scripts to process html
forms. Selecting exactly the topics to satisfy very diverse topics
without writing an enormous text is not easy.
ben...@cs.bu.edu (Ben Wiedermann) wrote in message news:<d6dae77c.02110...@posting.google.com>...
Charles Krug
> I am a college professor and use Python as the language in our first
> course -- designed for both majors and non-majors alike. There are a
> number of good python reference books around. Most of them are not
> appropriate as text books however because they have few examples and
> often no exercises. I like a book that is moderate in size. Books
> often have more material than can be covered in a single semester but
> it shouldn't be so large (or expensive) as to intimidate all but the
> bravest of souls. In my course, students are also expected to buy a
> text dealing with social/ethical issues.
>
Interesting. I doubled in both Math and CS. Half of the CS courses had
an ethics component, while none of the maths did.
<irony>
Which only makes sense. I've never heard of a fudged mathmatical model
used to support the desired conclusion of a sponsor with deep pockets.
Have you?
</irony>
Simon Callan
Dave Brueck <da...@pythonapocrypha.com> wrote:
> On Wed, 6 Nov 2002, Dave Reed wrote:
>
> > I've been using Python for my own projects (from short scripts to
> > 25,000 line apps) for almost three years now and can't imagine
> > using anything else right for anything that wasn't extremely
> > computationally expensive. After attending the panel, I talked my
> > other colleagues into using it for our CS 1 course this fall. The
> > only thing that bothers me about Python for teaching is the lack
> > of enforced private members for classes. As an experienced
> > programmer, I can live with that because I know better, but I
> > don't know whether the students will believe me when I tell them
> > it's a bad idea to directly access them outside of classes :-)
>
> Who cares if they believe you though, and why should they anyway?
> Part of becoming a good programmer is getting bit by taking
> shortcuts (over doing it the "right" way), learning from it, and
> moving on - and it's a great thing to learn through experience that
> the prof might actually know what he's talking about! :)
If you are feeling cruel, you could give them a library that has both
exposed internals, and proper interface functions, and then halfway
through the course, change the library so that anyone who doesn't use
the correct interface finds that subtle bugs have been introduced into
their code.
Simon
ACalcium
>
>The word is "you", not "u".
>
>You may not know this yet, but the rest of the Internet is *nothing*
>like AOL. We prefer complete English words here, and "cute"
[much deleted]
Just concentrate and follow the thread, Rob.
Chris Gonnerman
I have to say, I'm with Rob. How much work would two letters
cost you?
Robin Munn
<chris.g...@newcenturycomputers.net> wrote:
> ----- Original Message -----
> From: "ACalcium" <acal...@aol.com>
>
>
>> >> Why can u teach this in CS2 when they learn
>> >
>> >The word is "you", not "u".
>> >
>> >You may not know this yet, but the rest of the Internet is *nothing*
>> >like AOL. We prefer complete English words here, and "cute"
>>
>> [much deleted]
>> Just concentrate and follow the thread, Rob.
>
> I have to say, I'm with Rob. How much work would two letters
> cost you?
Especially when the two letters we're talking about are the two letters
on the end of my *name*. My name is Robin, not Rob. Which brings me to a
second point of Internet etiquette: don't trim attributions unless you
are also trimming *all* quoted text written by that person. Trimming
attributions had two effects in this case: first, it makes this thread
look like ACalcium is responding to him/herself (and who's this Rob?).
Second, it resulted in Chris also using my name incorrectly, since there
was no more "Robin Munn wrote:" to point out what my name *really* is.
Finally, did you ever think about the fact that Rob is a man's name
exclusively, while Robin can be a man's name or a woman's name? No, you
didn't think about that. You lucked out this time -- I am a man, so you
didn't accidentally call me by a wrong-gender name. But be *careful*
about that next time! Calling someone by a name that isn't theirs and
isn't even the same gender as theirs is even more impolite than your
first offense.
O.K., end of netiquette flame. Nothing to see here folks, move along,
preferably to a thread that's actually ON-topic...
P.S. Chris, no need to apologize: you had no way of knowing that Rob
isn't actually my name.
Cameron Laird
Ben Wiedermann <ben...@cs.bu.edu> wrote:
.
[several sage observations]
.
.
>presentation rank when considering a book? Are there examples of other
>college textbooks that people think do an excellent job in the
>presentation department? What kinds of materials can we (as a
>community) produce to get schools to consider and adopt Python as a
>first programming language? Any other thoughts on Python in the
>university?
Me, too--that is, I have occasional opportunities
to advocate use of Python in school courses, and
I'd welcome more information about what has and can
work.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Cameron Laird
Charles Krug <cha...@pentek.com> wrote:
.
.
.
>Interesting. I doubled in both Math and CS. Half of the CS courses had
>an ethics component, while none of the maths did.
>
><irony>
>Which only makes sense. I've never heard of a fudged mathmatical model
>used to support the desired conclusion of a sponsor with deep pockets.
>
>Have you?
></irony>
>
I don't understand this description. It
certainly interests me, though. I take
it that "CS" here means the kind of soft-
ware engineering and technology that's
typicall taught in college. And you're
seriously saying that sections on ethics
appeared in half of your classes? Can
you give a few examples of such content?
I know of abundant ethical questions spe-
cific to mathematicians. I can supply
plenty of examples of "fudged mathematical
model[s]", if that'll help.
Cameron Laird
There's a real range in university courses. Indeed,
a depressing number of them are still stuck at syntax
level.
Dave Reed, are you serious that decision-makers dis-
qualify Python for the lack of enforced private
members? Should I take it that they equally proscribe
(conventionally pre-processed) C and C++?
That sounds more hostile than I mean to be. Alex,
maybe you can help me articulate this. Just as it's
taken a while for the discipline to catch on that
static type checking (as in C and Java) is an impo-
verished proxy for real validation, I have hopes
that we can eventually raise programmers' vision of
what constitutes good support for teamwork and re-use
from its present regard on misapplied encapsulation.
Alan Kennedy
> I don't understand this description. It
> certainly interests me, though. I take
> it that "CS" here means the kind of soft-
> ware engineering and technology that's
> typicall taught in college. And you're
> seriously saying that sections on ethics
> appeared in half of your classes? Can
> you give a few examples of such content?
When I was studying for Computer Science degree, in each of the 4 years
we had a term (semester) of ethics classes, 1 hour per week. These were
usually given by the same lecturers who gave courses in more technical
Comp Sci matters.
The one that really sticks out in my mind is the following question that
was posed to us in 2nd year (age ~20).
We were asked to imagine ourselves as being asked to perform a
particular task, and to state what would be our course of action in that
situation. We were to select a single answer from a choice of four:-
1. Carry out the task without complaint.
2. Carry out the task under protest.
3. Resign
4. Resign and form a protest group.
We were posed the following scenario: "You are asked to develop a
software simulation of the spread of a chemical warfare agent. The
purpose of the simulation is to maximise the death toll from the use of
that agent".
Not surprisingly, there were very few people who were willing to carry
out the task, and I think those that said they would were saying so more
to play Devil's Advocate than anything else.
But there was one surprising outcome: When asked about developing the
simulation in relation a Russian City (this was before the Berlin Wall
came down), the majority in the class chose option 3: Resign. When asked
about developing the situation in relation to a French City, the
majority of the class selected option 4: Resign and form a protest
group.
I am very glad that I had the opportunity to confront and consider such
important questions in a situation where there were no real ethical or
financial considerations. The debate much clarified my thoughts in
relation to not just the ethics of computer science, but also the
unthinking racism that is often present in otherwise well-balanced
individuals.
> I know of abundant ethical questions spe-
> cific to mathematicians. I can supply
> plenty of examples of "fudged mathematical
> model[s]", if that'll help.
I think the above question about chemical warfare simulations applies
equally to mathematics: obviously there would be a large mathematical
and statistical input into such simulations.
These days, is there such a thing as a mathematics course that doesn't
involve extensive exposure to Computer Science?
regards,
--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan
Michael Hudson
> These days, is there such a thing as a mathematics course that doesn't
> involve extensive exposure to Computer Science?
Yes, the one I did at Cambridge (UK) had very little CS content (there
were computer projects in the second and third years but you could
ignore them if you chose to -- I didn't, but I know people who did).
I think I could have attended three hours of lectures on how to
program in Pascal (I *did* ignore those -- my projects were a bizarre
melange of Python, Haskell and Common Lisp tied together by bash
scripts).
I graduated in 2000; I don't think much has changed since ('cept it
might be C and not Pascal now).
Cheers,
M.
--
You can lead an idiot to knowledge but you cannot make him
think. You can, however, rectally insert the information,
printed on stone tablets, using a sharpened poker. -- Nicolai
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
Charles Krug
> Cameron Laird wrote:
>
>> I don't understand this description. It
>> certainly interests me, though. I take
>> it that "CS" here means the kind of soft-
>> ware engineering and technology that's
>> typicall taught in college. And you're
>> seriously saying that sections on ethics
>> appeared in half of your classes? Can
>> you give a few examples of such content?
>
> When I was studying for Computer Science degree, in each of the 4 years
> we had a term (semester) of ethics classes, 1 hour per week. These were
> usually given by the same lecturers who gave courses in more technical
> Comp Sci matters.
>
> The one that really sticks out in my mind is the following question that
> was posed to us in 2nd year (age ~20).
>
(snip)
> We were posed the following scenario: "You are asked to develop a
> software simulation of the spread of a chemical warfare agent. The
> purpose of the simulation is to maximise the death toll from the use of
> that agent".
>
That's far more interesting than our ethics unit, which dealt
exclusively with the Usual Suspects of copy protection and file access.
Were you in the real world outside of the Chemwar industry, the same
question would be coached in terms of fertilizer dispersal. Your
employer would get the same information, but would avoid cluttering up
the question with folks emotions.
The same graph theory that solves networking problems also solves
indistrial logistics problems, and military transport problems.
Justin Sheehy
> If you are feeling cruel, you could give them a library that has both
> exposed internals, and proper interface functions, and then halfway
> through the course, change the library so that anyone who doesn't use
> the correct interface finds that subtle bugs have been introduced into
> their code.
I've seen courses that used this tactic to (with some success) teach
the value of obeying interfaces and abstractions.
-Justin
Ben Wiedermann
In my experience, the "encapsulation" problem is a significant hurdle.
And it seems to me that folks who came to object-oriented programming
from procedural programming seem to have a harder time overcoming the
hurdle than those who have known only object-oriented programming.
Strange.
So, let's help folks get over this problem. If we could come up with
some sound bites to offer potential converts, I think it would be of
good use. Alex was extrememly helpful in this regard, offering up
tomes of information, as I recall. I will try to dig them out, if I
have them, but I think we all would much rather hear it from the
source (hint, hint). I have heard Guido say one of the reasons for
default public access is that it was easier to implement. I think this
argument is valid (probably more so than its simplicity might suggest)
to a language designer, but it is not necessarily valid to a language
adopter.
Any other thoughts? For that matter, we could tackle any other issues
(e.g., typing) that decision-makers might have problems with. I am
soliciting evangelists, here, not debaters! There are enough of those
threads....
Michele Simionato
> Alan Kennedy <ala...@hotmail.com> writes:
>
> > These days, is there such a thing as a mathematics course that doesn't
> > involve extensive exposure to Computer Science?
>
> Yes, the one I did at Cambridge (UK) had very little CS content (there
> were computer projects in the second and third years but you could
> ignore them if you chose to -- I didn't, but I know people who did).
> I think I could have attended three hours of lectures on how to
> program in Pascal (I *did* ignore those -- my projects were a bizarre
> melange of Python, Haskell and Common Lisp tied together by bash
> scripts).
>
> I graduated in 2000; I don't think much has changed since ('cept it
> might be C and not Pascal now).
>
> Cheers,
> M.
When I was studying Physics at the University of Padua (in the nineties)
we had an official booklet of the faculty with advices about the choice of
non-mandatory courses. I still remember the sentence about computer science
courses. Translating quite literally from Italian it reads something like
"In no case plans of studies involving CS courses from other faculties
will be accepted by this Physics commission". I would not be surprised if
this politics was still enforced.
In more ten years of Physics (including the Ph.D.) I never had a single
course about programming (excluding maybe two or three seminars in one of
the laboratory course I had, but they were unofficial, not part of the course;
we also had computer hours in the afternoon, but unofficial and not mandatory).
It could seems strange to somebody, but personally I second that politics.
Programming is a nice thing you can do for fun by yourself, but the
University has to teach you the real thing, not to spend your time on
other topics. Whereas it is true that lots of physicist (and mathematicians)
spend a lot of time on computers for their research, it is also true that
there still many researchers which can completely avoid the computer (I
am one of them).
I think that, at least in Europe, most of Physics and Mathematics course
still do not involve extensive exposure to Computer Science.
And this is a good thing.
--
Michele Simionato - Dept. of Physics and Astronomy
210 Allen Hall Pittsburgh PA 15260 U.S.A.
Phone: 001-412-624-9041 Fax: 001-412-624-9163
Home-page: http://www.phyast.pitt.edu/~micheles/
sism...@hebmex.com
> ...
> In my experience, the "encapsulation" problem is a significant hurdle.
> And it seems to me that folks who came to object-oriented programming
> from procedural programming seem to have a harder time overcoming the
> hurdle than those who have known only object-oriented programming.
> Strange.
But very true; I was proficient in Pascal and C by the time
I started using any OO language (C++ was my first, then Java,
then [urgh] Perl, and finally, Python). While learning C++,
the toughest problem was changing my "world-view" of simply-
structured programming, into an effective "OO-world-view",
where objects interact among themselves without much
"procedural glue".
>
> So, let's help folks get over this problem. If we could come up with
> some sound bites to offer potential converts, I think it would be of
> good use.
>
"Give your data personality"
"Allow your information to think for itself"
"Let your data do the walking" (changed from the yellow pages bite)
> Alex was extrememly helpful in this regard, offering up
> tomes of information, as I recall. I will try to dig them out, if I
> have them, but I think we all would much rather hear it from the
> source (hint, hint). I have heard Guido say one of the reasons for
> default public access is that it was easier to implement. I think this
> argument is valid (probably more so than its simplicity might suggest)
> to a language designer, but it is not necessarily valid to a language
> adopter.
Maybe from a language design viewpoint it was easier to implemnt,
but also from a phylosophical and from a software-design viewpoint,
it's much saner than the "you and you, but not all yous" implementation
of Java and C++, and others.
>
> Any other thoughts? For that matter, we could tackle any other issues
> (e.g., typing) that decision-makers might have problems with. I am
> soliciting evangelists, here, not debaters! There are enough of those
> threads....
>
:-)
-gustavo
Alex Martelli
...
> In my experience, the "encapsulation" problem is a significant hurdle.
> So, let's help folks get over this problem. If we could come up with
> some sound bites to offer potential converts, I think it would be of
> good use. Alex was extrememly helpful in this regard, offering up
> tomes of information, as I recall. I will try to dig them out, if I
> have them, but I think we all would much rather hear it from the
> source (hint, hint). I have heard Guido say one of the reasons for
OK, let's see what I had to say about this subject in our correspondence
of about a year ago, then... the quoted questions in the following are
also by you, Ben.
[ start of edited quotes from our correspondence ]
> Once we show __private, why would we suggest using the single
> underscore convention, as this would be inconsistent w/ the "principle
> of least privilege" we espouse in our other books?
Hmmm, because that principle is incorrect?
Once upon a time, there was the dream of the Waterfall model of software
development. First, one would do all Analysis (advanced texts split that
into Domain and Requirements phases, a mini-waterfall of its own), thus
reaching perfect understanding of the domain being modeled and the needs
to be met by one's programs in that domain. Then, one would proceed with
Design, the outline of every solution aspect not depended upon details of
implementation. Then, Coding. And so on.
Maybe that could work for Martians; never having met one, it's hard for
me to say. 30+ years of experience have easily shown it's a disaster
for Earthlings, anyway (what a waste: anybody familiar with the works
of some key thinkers of our grandfathers' generation, such as Ludwig
von Wittgenstein, Alfred Korzibski, and George Santayana, would have
known that from the start -- apparently, however, culture is fragmented
enough today that few Methodologists had ever heard of these guys).
Human beings are evolved to work in chaotic environments, superimposing
MODEST, LOCALIZED amounts of control and supervision upon the sheer but
undirected energy of Chaos to yield an overall process flowing more or
less in the desired direction. Since a little supervision and control
makes things so much better when compared to total disorder and anarchy,
it's a natural fallacy to think that MUCH MORE control and supervision
will make everything just perfect. Wrong. When some sort of threshold
is exceeded, the attempts towards tighter control take on a dynamics of
their own and start absorbing unbounded amount of energy and effort in
a self-perpetuating system.
I don't want to get into politics, but this IS very much what happened
East of the Iron Curtain -- far too much control, indeed so much that
the first serious attempt to release it crumbled the whole system to
not much above feudal/anarchy. The excesses of control in the West
were fortunately moderate enough that they could to some extent be
(partially) unwound less explosively. I'm not arguing for anarchy,
mind you -- Somalia is a living example of what anarchy means; just that,
quite apart from ethical issues, from a strictly engineering, effectiveness
standpoint there is a reasonably flat optimal region, well short of
totalitarian states but much more controlled than 'everyone for himself'.
Back to software development, we've witnessed similar "secular trends".
Here, the "anarchy" side, in a small scale, is played back again and
again in every student's initial approach to programming, and most small
software houses' beginnings. But we also have plenty of huge projects
run under "the stricter, the better" principles to remind us constantly
of what an utter disaster those principles are.
To be specific. "Principle of least privilege" assumes you somehow know
what the 'right' privilege for a certain operation SHOULD be. This in
turn takes it for granted that you completed a detailed and workable
design before starting to assign privileges (presumably, before you
started coding). And things just don't work that way.
"Least privilege" is indispensable for SECURITY issues. It's anything but
unusual for security issues to have diametrically-opposed needs to any other
kind: if you have to assume an adversary who is actively trying to break
things to his advantage, your correct mindset is very different than it
would be otherwise. Assuming adversarial situations where none exist is,
clinically speaking, symptom number one of paranoia. I'm as keen on
security as anybody else I know (I run OpenBSD, I refuse to run any
protocol on the net except SSH and other demonstrably-secure ones, etc,
etc), but it's best to keep such mindsets WELL SEPARATED from ordinary
software development needs, to keep one's sanity and productivity.
Didactically speaking, you have to show a beginner that utter chaos will
not work optimally, of course. But proposing over-tight control as the
viable alternative is not feasible. The only really workable way to
develop large software projects, just as the only really workable way to
run a large business, is a state of controlled chaos. There is a broad
range of mixes between chaos and control that can work, depending on the
circumstances (as I said above, the optimal region is reasonably flat --
a good thing too, or we'd NEVER get it right), but the range does NOT
extend (by a LONG shot!) all the way to the "Waterfall Model" on one
side (just as it doesn't extend all the way to "Do what thou wilt" on
the other:-).
There's a didactical school that claims, to counteract the students'
natural disposition to anarchy, they should be taught programming
discipline as strict as possible. That's like saying that all schooling
should be in a Victorian College atmosphere, with starched collars and
canings from the Prefects, for similar reasons. The Victorians did
achieve marvels of engineering that way, albeit perhaps at excessive
social and psychological costs. But we don't do things that way any more
in most fields. We surely don't in the kind of software development that
makes a difference in a competitive field (if you develop non-competitively,
e.g. for the government or in a university setting, your incentives are
clearly different; personally, after a decade working for university,
IBM Research, etc, I chose the rough and tumble playing field of real
life software development -- more money, AND is more fun too:-).
> What is the benefit of "public by default"?
Minimizing boilerplate. 90% of exposed properties in languages and
object models which don't support that lead to a lot of boilerplate:
public WhateverType
getPliffo()
{
return m_Pliffo;
}
or (in COM/C++):
HRESULT get_Pliffo(WhateverType* pVal) {
if(!pVal) return E_POINTER;
*pVal = m_Pliffo;
}
or (in VB):
Public Property Get Pliffo() As WhateverType
Let Pliffo = mvarPliffo
End Property
and so on, and so forth. There is no benefit whatsoever in all that
boilerplate. Maybe, if one has been educated to such strict discipline,
there is a "feel-good factor" -- "See, Mum, I'm being a good boy and
only accessing Pliffo via an accessor method!". But quite apart from
program efficiency (that's not a major issue AT ALL), all that extra,
useless code is a dead-weight dragging your productivity down -- sure,
some silly "Wizard" can originally generate it, but _people_ are going
to have to maintain and test and read and document it forevermore.
Sheer dead weight.
Some languages don't give you alternatives: if you originally expose
a "public WhateverType Pliffo" you're sunk -- client code will come to
depend on access idioms such as
WhateverType myPliffoReference = theNiceObject.Pliffo;
and then you can't turn that publicly exposed data into a call to an
accessor forevermore (without breaking client code, NOT a viable
option in most large software projects).
But that's a language defect! You don't have to get all the way to
Python to find solutions: e.g., in Eiffel, you can have client code
use that sort of construct AND Pliffo will be just accessed if it's
a data attribute, called if it's a method. Client code will need
to _recompile_, of course, but then, in Eiffel, you need to 'rebuild
world' every time you sneeze, so that's not considered an issue.
Point is, with this approach you don't HAVE to do "Big Design Up
Front" (http://xp.c2.com/BigDesignUpFront.html for much more). You
have an attribute that looks like client code might perhaps be
interested in looking at, you just use it. If while refining the
design it turns out that a call to a getter-method is needed, fine,
you add the getter-method *WITHOUT* breaking any client-code. When
you do it IF AND WHEN NEEDED, you find out that (depending on various
factors) it's something like 10% of properties that need to be
"synthesized" or otherwise controlled by accessor-methods -- the
others are just fine without any boilerplate.
So, OF COURSE, the default in Python is oriented to supporting that
90% or so of cases where nothing special is needed, NOT the remaining
'special' 10%. This minimizes programmers' effort over the whole
lifecycle -- which is typically interactive, of course, NEVER a
"Waterfall" (you start with some analysis, then begin design and
need to go back to the analysis because design has given you a
better understanding, then back to design, start coding and you find
the design needs to be tweaked, etc, etc -- AND YET you'd better
*release early, release often* if your software artifact is to have
some relevance to your customers' problems in this frantically
changing world of business today...!!!).
See http://www.agilealliance.org/ for example. I find it particularly
interesting that, while many of the "conspirators" were early enthusiasts
of (what is now called) Agile development in various guises, others (such
as Fowler, Martin, Mellor) were upper-M Methodologists and gradually saw
the light over the last decade or so of experience. Of course, these
things take forever to percolate down to universities. But, the pace
is picking up, particularly as movement back and forth between universities
and "real life" software development is not as glacial as it used to be.
Saturday I was a scheduled speaker at Linuxday, presenting the changes in
Python over the last year-plus, and I noticed with interest that well over
half the attendees were involved with both university/research endeavors
AND commercial projects. I was also struck once again by how many were
using functional programming (Haskell foremost, but O'Caml seems to be
gaining) for the "academic respectability" in their publication-oriented
endeavors, AND pragmatical programming (Python foremost, but Ruby seems to
be gaining) for the "real word productivity" in those projects where they
actually have to deliver AND maintain working software. I don't necessarily
LIKE all of these trends (I'll take Haskell over any ML, and Python over
Ruby, any day:-) but I do observe them and think them significant. Some
of these people teach SW development to freshmen as part of their duties,
and in that case it appears that they almost invariably have to teach more
traditional languages (Pascal foremost, but Java seems to be gaining). I
don't know how much that depends on these being Italian institutions in
particular, of course (I gather Java has already overtaken Pascal as an
introductory language in the US universities, for example). But that's
nothing new -- back when _I_ taught in universities, I invariably had to
teach Fortran (since I was teaching at the Engineering school -- would
have been Pascal if I taught at CS!-) even though I was using C for real
world programming and Lisp (actually Scheme) for publications (needing
"academic respectability", you see:-).
[ I'm rephrasing, clarifying, and correcting some errors in the following
example of signature-based polymorphism as enabled by Python's approach to
encapsulation, compared to our original correspondence ]
def hypot(somepoint):
import math
return math.hypot(somepoint.x, somepoint.y)
this client-code only depends on the following subsignature of 'somepoint':
exposing .x and .y attributes transparently compliant to 'float'.
In practice this means interchangeability of:
class NaivePoint:
def __init__(self, x=0.0, y=0.0):
self.x = x
self.y = y
and
class UnchangeablePoint:
def __init__(self, x=0.0, y=0.0):
self.__dict__['x'] = x
self.__dict__['y'] = y
def __setattr__(self, *junk): raise TypeError
def __hash__(self): return hash(self.x)+hash(self.y)
def __eq__(self, other): return self.x==other.x and self.y==other.y
and many other kinds of 'point'. The somepoint.x access may be mapped
down to very different mechanisms (it's self.__dict__['x'] in both of
these, but not in many others) but stays *signature-polymorphic* to the
need of client-code 'hypot'.
So the proper procedure is to choose the kinds of 'point' implementations
that meet the design needs *you currently perceive at this stage in your
project*: you don't need to be Nostradamus and foresee how your project
will look in a year, nor to "wear braces AND a belt" and overdesign
everything *just in case* currently-unforeseen needs MIGHT emerge one day.
Rather, you can privilege SIMPLICITY -- that often-underrated, yet most
crucial of all design virtues. "A designer know that perfection is reached,
not when there is nothing left to add, but when there is nothing left to
take away" (St. Exupery). Meet simple design-needs with simple mechanics
(including NONE AT ALL, from the point of view of the Python coder --
rather, the simple needed mechanics are inside the Python interpreter, of
course), rarer and more complex needs with more advanced mechanics. No
"impedence mismatch" between the constraints that arise during a design's
development, and the remedies needed to meet them. Bliss!
The single-underline convention (actually enforced where it NEEDS to
be, such as, the Bastion class, "from somemodule import *" where the
module doesn't define an __all__ attribute, etc) is a good example of
"human beings knowing their limit". If we drop the pretense that a
designer is omniscient, we can see that any determination of a need
or constraint has COSTS -- actual design costs (design time), costs
in terms of missed oportunities, etc. The parallel is spookily close
to that of asymmetric-information economic exchanges, and I note that
the Nobel Prize in Economics [last] year were granted exactly for work
in the asymmetric-information and signal-exchanging fields, so it would
seem SOME academics are well aware of the issues.
Sometimes (pretty often) you can determine at reasonable 'cost' that
client code may well need to access attributes X, Y, and Z. Then, you
expose them (without any underlines) -- and later may choose to wrap
them up into accessors, etc, as above. Sometimes (not often) you can
determine at reasonable cost that client code has no conceivable need
to peek at attributes foo, bar and baz. Then, you name them __foo,
__bar, and __baz, and generally don't even provide accessors -- those
are the strictly-implementation-related attributes, not part of the
abstract client-visible state of your class at all.
There remains a considerable gray area of attributes that you do not
THINK client-code will need to access, but can't make SURE about without
unreasonable cost. If you expose an accessor method getEenie that does
some irreversible computation on an internal attribute 'eenie' and
returns the result, for example, it may require unreasonable delays and
cost to ascertain whether it's ever conceivably possible that some client
code may need to access the raw unprocessed value for 'eenie' rather than
always being content with getEenie()'s results. These are very appropriate
cases to handle with the single-underline convention, meaning: I don't THINK
client-code ever needs to see this, but I can't be SURE -- *at your own
risk* (very strong coupling -- the single-underline DOES mean "internal"!)
you may choose to access this if there's no other way to do your job.
If you've ever programmed to a framework designed by other criteria you
know what I mean... there's this class X in the framework that does ALL
you need BUT doesn't expose one key attribute or method 'meenie' -- it
has it, but as "private". This recurring horror leads to "copy and paste
programming", forking of framework code and the resulting nightmares in
maintenance (it's a recognized "Antipattern" in the book by that title
by Brown, Malveau, McCormick and Mowbray) -- or even weirder tricks such
as "#define private public" before some "#include" in C++...!!! The
problem was: the framework designer thought he was omniscient. The
language URGED him to believe in his omniscience, rather than strongly
discouraging such hubris. Well, he WASN'T omniscient -- surprise,
surprise, he was a human being (maybe we should subcontract such design
work to martians...?). So there's cognitive dissonance between the
language-induced mindset, and human biological reality. Reality wins
out each and every time, but not without much anguish in-between. (At
the risk of skirting politics again: similarly, the Soviet system urged
central planners to believe their own ominiscience, since everything had
to be planned right from the start -- no built-in flexibility in the
system; I recommend Perrow's "Normal Accidents", a masterpiece of
sociology in my view, about the ills of tight-coupling and assumed
omniscience in accident-prone systems, such as nuclear plants and ships).
Note that I'm only arguing one side of the issue because you're not
advocating the OTHER wrong extreme -- total lack of control, weak
typing, haphazard jumbled-together slapdash 'systems' that don't
deserve that name. You should see me argue FOR control and against
chaos versus the typical Javascripters of this world:-). (As all people long
used to occupying a reasonable middle position, I'm also quite used at
being shot at from extremists of both sides, of course:-).
[ end of edited quotes from our correspondence ]
Alex
Dave Reed
<snip>
> There's a real range in university courses. Indeed,
> a depressing number of them are still stuck at syntax
> level.
>
> Dave Reed, are you serious that decision-makers dis-
> qualify Python for the lack of enforced private
> members? Should I take it that they equally proscribe
> (conventionally pre-processed) C and C++?
That's just my impression/what I think is one of the biggest issues
that would discourage some academic types from switching to Python. I
don't have any hard evidence to support it. Obviously this didn't stop
me, but I'm relatively young for a college prof (early 30s), find
Python programming extremely fun, and definitely lean toward the
practical side of things. The other person in my dept. who teaches CS1
is about 20 years older than me and it didn't take much effort to
convince him to switch to Python even though I pointed out the lack of
private data to him. Of course, he has learned to hate C++ so that
made persuading him much easier :-)
Note: I am NOT advocating adding private members/methods to Python.
Dave
Hung Jung Lu
> > What is the benefit of "public by default"?
>
> Minimizing boilerplate. 90% of exposed properties in languages and
> object models which don't support that lead to a lot of boilerplate:
>
> HRESULT get_Pliffo(WhateverType* pVal) {
> if(!pVal) return E_POINTER;
> *pVal = m_Pliffo;
> }
>
> boilerplate. Maybe, if one has been educated to such strict discipline,
> there is a "feel-good factor" -- "See, Mum, I'm being a good boy and
> only accessing Pliffo via an accessor method!".
I agree with accessor methods being boilerplate in Python. But in C++,
under some circumstances, it's a real necessity.
The one place that I find it necessary to use accesor methods is for
base classes to access attributes of derived classes.
An object often need to access attributes from four places: (a)
attributes from its own-level class, (b) attributes from its base
class(es), (c) attributes from another object belonging to another
class, (d) attributes from a subclass, this last point because a
method is implemented at the base class level.
Python can do all of (a), (b), (c) and (d).
C++ cannot do (d), at least not in a simple manner. (And you don't
want to have circular "#include"s.)
In Python, I often would check the existence of an attribute before
proceeding:
if hasattr(self, 'x'):
.... do something with self.x
This is great for methods implemented at the base class level that
need to access attributes of subclasses. C++ can't do this, in a
straightforward manner. To fix idea, the base class could be "Person",
the derived class could be "USTaxablePerson", and "x" be U.S. tax-id
or social security number.
One way out is for C++ to implement the variable 'x' at the base class
level. But this means that objects that don't have the 'x' attributes
still need to carry that data field. (e.g: infants don't have tax-id).
This is not a problem when the number of data fields is small, or when
the number of person is small. It becomes a problem when you have many
data fields and many persons.
What I have found out is, for some problems in C++, you often want to
make powerful subclasses with minimum data attributes. That is, base
classes will have a lot of methods, but only a few data members. On
the other hand, subclasses add more data attributes, but not more
methods.
It is in these types of problems that accessor methods are necessary.
It is much more economical and natural for objects in the class
hierarchy to share methods than to share data attributes. The getX()
method at the base class would simply raise an error, because 'x' does
not exist at the base class level. The getX() in the subclass would
return the appropriate value of x. Not just because U.S. tax-id is
needed for one particular purpose, would we implement that data field
for all persons (or martians), and put value NULL there. If there are
10 billion persons/martians, you'd be wasting many billion bytes, for
nothing. Again, the problem is small if that's the only data field we
are talking about, but in a complex class hierarchy tree with many
subclasses and many instances, you'll have to start to pay attention
as to where to put the data members.
C++ has virtual methods, but no virtual data members.
And, that to me, is the main reason why C++ needs accessor methods.
Hung Jung
Alex Martelli
> Alex Martelli <al...@aleax.it> wrote in message
> news:<owWy9.11842$XO.4...@news2.tin.it>...
>> > What is the benefit of "public by default"?
>>
>> Minimizing boilerplate. 90% of exposed properties in languages and
>> object models which don't support that lead to a lot of boilerplate:
...
> I agree with accessor methods being boilerplate in Python. But in C++,
> under some circumstances, it's a real necessity.
That's exactly the same thing I'm saying: C++ is an example of
a language that doesn't support 'properties', which is one reason
(out of many) which causes C++ code to need a lot of boilerplate.
Note that the fact that the language makes it necessary doesn't
mean such repetitious, performs-no-real-function code ISN'T
boilerplate; "boilerplate" and "real necessity" aren't antonyms.
> C++ has virtual methods, but no virtual data members.
>
> And, that to me, is the main reason why C++ needs accessor methods.
It's ONE reason, yes -- subclasses cannot "override data" the way
they can in Python. However, there are other reasons: in C++, if
you expose an instance attribute X to clients, then client code
written to access blahblah.X needs X to be and remain a data
attribute forevermore -- the fact that X is data has become part
of your class's interface. Therefore, to keep the flexibility to
change your class in the future, so that X can perhaps be computed
on the fly rather than stored, you DARE NOT expose X as an
attribute on a public interface.
Python's ability to "override data" is amazingly powerful (and
plays incredibly well with the "Template Method" Design Pattern,
too). But you don't need to go that far to remove the need for
accessors: languages such as Delphi (Object Pascal), Eiffel, and
the C++ dialects/extensions peddled by Borland and Microsoft, all
manage to allow blahblah.X to compile to EITHER a data access OR
a call on some accessor method of blahblah as appropriate.
Alex
Aahz
Ben Wiedermann <ben...@cs.bu.edu> wrote:
>
>In my experience, the "encapsulation" problem is a significant hurdle.
>And it seems to me that folks who came to object-oriented programming
>from procedural programming seem to have a harder time overcoming the
>hurdle than those who have known only object-oriented programming.
>Strange.
Maybe. Speaking as someone who learned BASIC, Pascal, Ada, C, and
FORTRAN long before learning a real object-oriented language, my opinion
is that most OO languages try to *force* OOP in a way that makes it much
harder to grasp. Python makes it easy.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
A: No.
Q: Is top-posting okay?
Magnus Lyckå
> The only thing that
> bothers me about Python for teaching is the lack of enforced private
> members for classes.
Compared to C++? :)
What's the problem with "self.__name = 'Guido van Rossum'" ?
After all, people hardly write
coder._Person__name = 'Danny de Vito'
by accident. Code reviews hardly fail to see it either.
You can bypass protection and do very nasty things in C++ in
a way that makes Python feel like Fort Knox. C++ has arbitrary
memory pointers! How can that ever be safe? What Python does
here is to lock the door and put the key on a hook by the door.
C++ just puts it under the door mat. In both cases this means
that you can get in if there is an emergency, but gives a clear
hint that you can't just walk in as you like. It's just more
error prone in C++.