Deitel and Deitel Book...
Ron Stephens
Deitel and Deitel book, "Python How to Program" (I also posted this at
my website at http://www.awaretek.com/plf.html ).
...
Well, let's see, I bought this 1292 page book from Amazon a week ago for
$72. This is the most I have ever paid for a computer book. Heck, it may
well be the most I have ever paid for *any* book ;-))).
I am leaving on a long business trip to Asia in two days, and I just
can't wait until I get back to tell you how much I am enjoying this
book. I have read the first 340 pages, which cover the core language; I
intend to carefully read the remaining chapters, which cover various
more advanced topics, as I fly around the world from
New York City to Amsterdam, to Singapore, to Taiwan, to Japan, to Korea,
on to Shanghai, China, and finally back home to New York. I am looking
forward to the book more than the trip ;-))))
This book is one of the most enjoyable I have ever read. The pedagogical
approach that the authors use is superb; they have obviously learned
their educational craft well; for me, it actually works. The quality of
the paper is the finest in any Python book yet; the text is large and
clear. The way actual code is highlighted and separated from the text is
extremely
helpful. Everything is first class.
I actually sort of expected the book to be a second rate effort in the
sense that the Deitels have written several best sellers about other
languages, and I sort of expected them to half-heartedly do a me-too
book by just applying the same old formula to a Python version.
But the book is fresh and clearly thought out. Since I have never read
any other Deitel book, it is possible that those who have done so may
have a different experience.
But I think even Deitel veterans will be pleased. More than anything
else, the book reminds me of a great college textbook, and reading such
a text is something I haven't done in way too many years. But this
educational quality of the text brings it to a whole new level of
sophistication, compared to most computer programming books.
The book includes, at the end of each chapter, extensive questions and
answers, review lists, and summaries. It actually feels like you are
studying for credit in a college course. The end result is that, after
carefully reading the chapters covering the core language, I feel like I
have consolidated my Python knowledge considerably and that I am both
ready to do some really serious coding (once I get back from Asia ;-)))
and also to successfully attack the advanced chapters while I am on the
planes.
In addition to excellent coverage of the core language, the book covers
CGI, XML, Databases, XHTML (quite extensive) , Data Structures,
Multimedia, OpenGL, Tkinter, CSS, Python Server, Networking, Threading,
Regular Expressions, and Unicode. There are even excellent and extensive
appendixes reviewing Octal, Hexadecimal, and Binary Number Systems;
HTML; and Python version 2.2 Additions. Most of these topics are not
just skimmed over but are covered in great detail. yet the book really
flows well. The exercises and questions and answers are equal to the
very best college text books I have encountered. Even the summaries
after each chapter are useful; I think I will be reviewing the chapter
summaries on the plane and later again after a few weeks, in order to
consolidate my learning even more. It seem like a good use of my time,
because the summaries are well thought out and very helpful.
I am excited.
I will do a detailed and very thorough review of the whole book as soon
as I return home from my trip. But even based on my reading of only the
first 340 pages, this book is a winner and I think any
Pythonista who is willing to part with the (admittedly huge) sum of $72,
will be richly rewarded. One could easily get engrossed in this fine
book and wind up absorbing all 1292 pages in 10 days of blissful mind
mongering. (Well, what the hell, its only a preview review and I can
coin an asinine phrase like "mind mongering " if I want to ;-))))
...
By the way, I have studied the code of Hans Nowak's mygale.py well
enough to be confident in making modifications and additions, and I am
really looking forward to doing that as soon as I return home. I intend
to add more starting point sources for the article searches, to add the
capability to search for any given topic, and also trying to fine tune
the searching mechanisms. I even have some other ideas for the code, but
I'll keep them quiet for now. Quite basic coding of course, the real
work has already been done by Hans and I really appreciate his
open-sourcing of this fine program.
I'm still searching for more tutorials and I'm up to 24 links now. I
have a lot of other stuff I want to add when I get back in mid March.
Ron Stephens
< a href = "http://www.awaretek.com/plf.html">Python City</a>
Alex Russell
I was required to purchase their Java book for a class, and not only was
it poorly laid out, poorly executed, badly typeset, and cheaply made, it's
index was utterly useless. Their C++ book wasn't much better. A friend had
it laying about his place day and I spent some time looking through it,
and after comparing it to Lippman/Lajoie, it's clear that it makes better
tinder than a programming reference.
Stear clear of those two if you're thinking about picking them up on the
strength of their Python book.
--
Alex Russell
http://netWindows.org
http://alex.netWindows.org
Alan Gauld
> Well, let's see, I bought this 1292 page book from Amazon a week ago for
> $72. This is the most I have ever paid for a computer book.
I've paid more but I'm glad that I got my complimentary copy
as a reviewer! Its a lot of money for paper!
> This book is one of the most enjoyable I have ever read.
I'm glad you like it, books are very much a personal
preference kind of thing.
> the paper is the finest in any Python book yet;
I assume you mean finest in the sense of thinest?
My copy feels like tissue paper...
> languages, and I sort of expected them to half-heartedly do a me-too
> book by just applying the same old formula to a Python version.
I think thats what they have done, looking at their C++ and
Java books they are very similar. But if those books work
then why not?
> Regular Expressions, and Unicode. There are even excellent and extensive
> appendixes
One of my criticisms of the book is that the HTML and XHTML
appendices really could have been rolled together - they are
obviously cut n paste copies with minor differences where
appropriate - there are whole pages with only a couple of
words different! But thats how you get 1300 pages in a book
I guess!
> very best college text books I have encountered. Even the summaries
> after each chapter are useful;
Here I agree, I did think te summaries were useful - for the
first half of the book I just read the summary sections
without reading the main text, then when I got to the
chapters I really wanted to read I read both.
That worked OK.
> I am excited.
In that case the book has succeeded, excited readers
are every authors dream! :-)
Alan Gauld
Author of the "Learn to program" website
http://www.freenetpages.co.uk/hp/alan.gauld
Cameron Laird
Ron Stephens <rds...@earthlink.net> wrote:
>Sorry but I can't wait to give a brief "preview review" of the new
>Deitel and Deitel book, "Python How to Program" (I also posted this at
>my website at http://www.awaretek.com/plf.html ).
>...
My own reaction to *Python How to Program* is more reserved
(and I was one of the tech reviewers of the book). While it
does, indeed, have several strengths, it's not flawless. In
particular, the last draft I saw gave Win* programmers an
inadequate sense of both Python's capabilities and good style.
I'll withhold more specific comment until I see the book as
it appears on store shelves. I can add, though, that the
Deitels have always been thoroughly courteous and professional
with me, even through technical disagreements.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
DeepBleu
a book written by Lutz, Holden or Hammond any time. But not from the
establishment of Deitel. I bet you they do not even know how to program in
Python. All their books are churned out by what resembles an
industry-complex with standard issue.
Long ago I discovered a mistake in their old C++ How to Program. I sent
them an e-mail. The answer still brings vivd memories of when you feel like
throwing up. Arrogant bunch of oppurtunists who are not worth the price of
the paper their books are printed on.
You want books on Python: Buy Beazley, Lundh, Holden, Hammond, Greyson
etc....
Leave Deitel alone!
DeepBleu
"Ron Stephens" <rds...@earthlink.net> wrote in message
news:3C7D8DCA...@earthlink.net...
Dennis Roark
news:20020227163411...@netWindows.org:
> I'm glad they (apparently) got one right.
>
> I was required to purchase their Java book for a class, and not only
> was it poorly laid out, poorly executed, badly typeset, and cheaply
> made, it's index was utterly useless. Their C++ book wasn't much
> better. A friend had it laying about his place day and I spent some
> time looking through it, and after comparing it to Lippman/Lajoie,
> it's clear that it makes better tinder than a programming reference.
>
> Stear clear of those two if you're thinking about picking them up on
> the strength of their Python book.
>
I am afraid I have to agree more with Alex's cautionary comments than
with Ron's strong praise. I know these authors have the most popular
college C++ text out there, but it always seemed like a C book with
Objects added on as an after thought. I stay with other texts when I
teach C++. The Python book appears substantially based on the templates
of their previous books. IMHO, not the quality nor the enjoyment of
Mark Lutz, Programming Python, 2nd ed., or even of the relatively short
tutorial in Steve Holden's Python Web Programming. That the D & D book
came out in Python was more of an indication of Python going mainstream,
and for that I celebrate it.
--
Dennis Roark
de...@earthlink.net
Starting Points:
www.home.earthlink.net/~denro
Ron Stephens
and Deitel style partly because I have little formal academic background
in computer science. Maybe the Deitel books appeal more to those readers
who are relatively lacking in background.
I do think the Deitels use a lot of words to make their points, and
there is a lot of repetition, in that the book is full of highlighted
Common Programming Errors, Tips, and Observations, all of which repeat
points just made in the text. Some might find those Tips needlessly
redundant and time wasters. Likewise, some might find the relatively
verbose text to be overkill, while I find it helps me to understand. And
I tend to learn best by repetition.
Anyway, its interesting to me. I don't think I can draw any conclusions,
but I tender the hypothesis that the Deitel Python book might be better
for relative neophytes rather than accomplished Python programmers.
I'll no doubt be thinking about this as I read the more advanced
chapters of the book.
Michael Hudson
> The Python book appears substantially based on the templates of
> their previous books.
Certainly the first draft of chapter 2 that I reviewed[0] looked
suspiciously like the corresponding chapter from Java:HTP. That went
back with a lot of red ink on it...
Cheers,
M.
[0] My, there were a lot of reviewers weren't there?
--
same software, different verbosity settings (this one goes to
eleven) -- the effbot on the martellibot
DeepBleu
"Dennis Roark" <de...@NSPAMearthlink.net> wrote in message
news:Xns91C39C93F933E...@207.217.77.23...
> Alex Russell <al...@netWindows.org> wrote in
> news:20020227163411...@netWindows.org:
>
>That the D & D book
> came out in Python was more of an indication of Python going mainstream,
> and for that I celebrate it.
>
end up making tons of money (to my knowledge, two of their books are
textbooks: C++ and Java) with their money making publishing machines while
someone like Mark Hammond can not find a job.
Of course not to mention that they may be probably going ahead for plans for
a book on Python (Complete Python Lab maybe) with a CD and start their won
consulting business on Python. Rediculous!
Then of course we'll see some professors assigning the D & D Python book as
a textbook on a scripting language. How disgusting!
DeepBleu
Aahz Maruch
>Dennis Roark <de...@NSPAMearthlink.net> writes:
>>
>> The Python book appears substantially based on the templates of
>> their previous books.
>
>Certainly the first draft of chapter 2 that I reviewed[0] looked
>suspiciously like the corresponding chapter from Java:HTP. That went
>back with a lot of red ink on it...
All right, let me ask: are there any reviewers who think that PyHTP looks
like a book written by Python programmers rather than a book written by
Java programmers?
>[0] My, there were a lot of reviewers weren't there?
Yup. A lot of *opinionated* reviewers, at that. In all fairness, it's
pretty clear that Deitel paid a fair amount of attention to our
comments, but thought it was more important to stick with the style of
their existing books. And, heck, they *did* pay well for my time.
--
--- Aahz <*> (Copyright 2002 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
"How come we choose from just two people for President but more than 50
for Miss America?" --AEN
Michael Hudson
> In article <uvgcgw...@python.net>, Michael Hudson <m...@python.net> wrote:
> >Dennis Roark <de...@NSPAMearthlink.net> writes:
> >>
> >> The Python book appears substantially based on the templates of
> >> their previous books.
> >
> >Certainly the first draft of chapter 2 that I reviewed[0] looked
> >suspiciously like the corresponding chapter from Java:HTP. That went
> >back with a lot of red ink on it...
>
> All right, let me ask: are there any reviewers who think that PyHTP looks
> like a book written by Python programmers rather than a book written by
> Java programmers?
Well, the published version looks less like this than the initial
version, at least. What worried me more was the fact that it seems to
cover 101 topics -- I have a feeling it might give a reader enough
knowledge to be really dangerous in some areas, but no more.
> >[0] My, there were a lot of reviewers weren't there?
>
> Yup. A lot of *opinionated* reviewers, at that. In all fairness, it's
> pretty clear that Deitel paid a fair amount of attention to our
> comments, but thought it was more important to stick with the style of
> their existing books.
Well, some of the things that struck me as odd might have some thought
behind them -- the repitition being one of the more obvious.
> And, heck, they *did* pay well for my time.
Yeah, though I'll be happier when I actually get paid... (this is my
first encounter with the IRS).
And I now have the 2.2 source on my home box (which is currently
sundered from the internet). Must find a book to review as 2.3 is
being prepared <wink>.
Cheers,
M.
--
The meaning of "brunch" is as yet undefined.
-- Simon Booth, ucam.chat
Anthony_Barker
> a book written by Lutz, Holden or Hammond any time. But not from the
> establishment of Deitel. I bet you they do not even know how to program in
> Python. All their books are churned out by what resembles an
> industry-complex with standard issue.
> Long ago I discovered a mistake in their old C++ How to Program. I sent
> them an e-mail. The answer still brings vivd memories of when you feel like
> throwing up. Arrogant bunch of oppurtunists who are not worth the price of
> the paper their books are printed on.
> You want books on Python: Buy Beazley, Lundh, Holden, Hammond, Greyson
> etc....
> Leave Deitel alone!
> DeepBleu
I agree with you to a point. They don't seem passionate about
programming, and the books are definitely cookie cutter. That said,
more books on the python landscape is a good thing. And as the
previous poster said, programming books are a personal thing.
Personally I found a lot of the best material is online. Beazley's
presentations are excellent, as is his dead tree book. Eckel's, "The
thinking in Python", is very good. For beginners the "How to Think
Like a Computer Scientist" I found better that most dead tree books
(http://www.ibiblio.org/obp/thinkCSpy/).
I would love to see books on Algorithms with Python (makes a perfect
fit), and more advanced topics such as threads and extending python.
DeepBleu
"Anthony_Barker" <anthony...@hotmail.com> wrote in message
news:899f842.02030...@posting.google.com...
> "DeepBleu" <Deep...@DeepBleu.org> wrote in message
> > Deitel and Deitel book on Python? I personally would not touch it.
Give me
> > a book written by Lutz, Holden or Hammond any time. But not from the
> > establishment of Deitel. I bet you they do not even know how to program
in
> > Python. All their books are churned out by what resembles an
> > industry-complex with standard issue.
> > Long ago I discovered a mistake in their old C++ How to Program. I sent
> > them an e-mail. The answer still brings vivd memories of when you feel
like
> > throwing up. Arrogant bunch of oppurtunists who are not worth the price
of
> > the paper their books are printed on.
> > You want books on Python: Buy Beazley, Lundh, Holden, Hammond, Greyson
> > etc....
> > Leave Deitel alone!
> > DeepBleu
>
> more books on the python landscape is a good thing. And as the
> previous poster said, programming books are a personal thing.
>
them out of my old encounter with them over the error in C++ How to Program.
>
> I would love to see books on Algorithms with Python (makes a perfect
> fit), and more advanced topics such as threads and extending python.
I'd love to see something like that specially on threads and extending
Python. This is something I can use.
DeepBleu
Cameron Laird
DeepBleu <Deep...@DeepBleu.org> wrote:
.
.
.
>> I would love to see books on Algorithms with Python (makes a perfect
>> fit), and more advanced topics such as threads and extending python.
>
>I'd love to see something like that specially on threads and extending
>Python. This is something I can use.
>DeepBleu
>
>
How would you feel if such material appeared in magazines rather than books?
Jim Dennis
>"DeepBleu" <Deep...@DeepBleu.org> wrote in message
...
>> You want books on Python: Buy Beazley, Lundh, Holden, Hammond, Greyson
>> etc....
>> Leave Deitel alone!
>> DeepBleu
> I agree with you to a point. They don't seem passionate about
...
> presentations are excellent, as is his dead tree book. Eckel's, "The
> thinking in Python", is very good.
...
I thought Eckel's TiPy and his "Thinking in Patterns (with Python)"
had been merged. I didn't realize that either of them had been
released in dead tree editions. (I've read parts of them online
at his web site)
Bruce Eckel's MindView, Inc: Thinking in Patterns with Java
http://www.mindview.net/Books/TIPatterns/
Bruce Eckel's MindView, Inc: Thinking in Python
http://www.mindview.net/Books/TIPython
(Actually it seems, if I believe his web pages, that these are still
developmental versions, and have not yet been set to print).
> I would love to see books on Algorithms with Python (makes a perfect
> fit), and more advanced topics such as threads and extending python.
I would love to see a good book on "patterns" in Python. I'd like
it to be a simple booklet listing each of the GoF patterns, with a
couple of examples of each. It would be fine if it also covered some
additional patterns or some controversies or alternatives to the
classic GoF patterns (like the Alex Martelli's Borg vs. the GoF Singleton).
Don't even ask for my opinion on Thomas W. Christopher's
_Python_Programming_Patterns_ book (PTR/PH Prentice Hall, (c) 2002),
it has almost nothing to do with OODP (one chapter with superficial
coverage of 20 out of the GoF 23 patterns, and the example code is
convoluted, opaque and mostly irrelevant to Patterns). (As a saving
grace his chapters on threads and concurrency are somehwat better.
I think my best bet so far is to study online at:
Python Patterns
http://www.thinkware.se/cgi-bin/thinki.cgi/PythonPatterns
... and this seems to be the rule for Python. The best material
seems to be live and online. However, I still need something to
take to the coffee shop or into the can with me (no I don't have a
computer in *there* yet; and I haven't set up sitescooper to fetch
Python stuff to my Palm/Visor, yet).
I've been enjoying Steve Holden's book, though it is pretty basic
and a little slow in places. I thought his approach to introducing
OOP by starting with strawman procedural examples going through a
"objects as data structures" phase and iteratively refactoring that
into an OO design with constructors and other methods was interesting,
though a bit repetitive in the written form. (It would make alot of
sense in a lecture format, though). I also picked up Robert W. Bill's
new Jython book from New Riders. Based on that, Holden's work and
Beazeley's _Python_Essential_Reference_ I'd say that New Riders is
kicking @$$ in the Python arena.
Although I like most of the classic O'Reilly titles, I have to say that
I'm a little disappointed in Fredrik Lundh's _Python_Standard_Library_
--- it's just too short and doesn't offer comparisons among related
or similar modules. For example the coverage of the curses module
consists of one sentence of running prose and one 14-line code
example. That code example doesn't mention the curses.wrapper()
function, doesn't show his code in a try: finally: block (which could
leave the terminal in an unusable state if any exception is thrown)
and doesn't show or even mention ncurses color (which is a common
source of confusion in this NG). (Of course it might not be fair to
pick on the curses coverage, which seems to be relegated and accursed
in all Python documentation; but this is just one example).
Meanwhile I thought both the Lutz books were tedious (though I haven't
read the 2nd edition of Programming Python).
Meanwhile the O'Reilly book on _Python_&_XML_ by Christopher A. Jones
and Fred L. Drake, is very good.
Sheila King
wrote in comp.lang.python in article
<20020227163411...@netWindows.org>:
> I was required to purchase their Java book for a class, and not only was
> it poorly laid out, poorly executed, badly typeset, and cheaply made, it's
> index was utterly useless. Their C++ book wasn't much better. A friend had
> it laying about his place day and I spent some time looking through it,
> and after comparing it to Lippman/Lajoie, it's clear that it makes better
> tinder than a programming reference.
That's funny. I'm not familiar with the Lippman/Lajoie book, but I have a
LOT of C++ texts here at home. And I learned C++ from the Deitel and Deitel
book, and thought it was pretty good. Later, when I taught C++ I used it as
a reference, although I didn't select it as the text for my course. Most
people I know who are familiar with the Deitel and Deitel C++ text think it
is very good.
--
Sheila King
http://www.thinkspot.net/sheila/
"When introducing your puppy to an adult cat,
restrain the puppy, not the cat." -- Gwen Bailey,
_The Perfect Puppy: How to Raise a Well-behaved Dog_
Jason Orendorff
> That's funny. I'm not familiar with the Lippman/Lajoie book, but I
> have a LOT of C++ texts here at home. And I learned C++ from the Deitel
> and Deitel book, and thought it was pretty good. Later, when I taught
> C++ I used it as a reference, although I didn't select it as the text
> for my course. Most people I know who are familiar with the Deitel
> and Deitel C++ text think it is very good.
I dislike Deitel & Deitel because of their casual disregard for
correctness. I can't open any of their books without finding an error.
In C++HTP, they illustrate "Circle" as a subclass of "Point". In CHTP,
they say it's a common programming error to use \n outside of a printf
statement (it only works in printf statements, they say).
Maybe they do this because they think it simplifies the point they're
making, but I think it's a disservice to the student. Anyone serious
about programming in C++ will need to know what derived classes
signify.
## Jason Orendorff http://www.jorendorff.com/
Sheila King
wrote in comp.lang.python in article
> I dislike Deitel & Deitel because of their casual disregard for
> correctness. I can't open any of their books without finding an error.
> In C++HTP, they illustrate "Circle" as a subclass of "Point".
Well, it's true I didn't particularly care for that example.
> Maybe they do this because they think it simplifies the point they're
> making, but I think it's a disservice to the student. Anyone serious
> about programming in C++ will need to know what derived classes
> signify.
I guess I found the book a useful reference, it was easy (for me) to find
stuff in the index (someone here said their indices weren't good, and that
surprised me), plus there are plentiful code examples. But I've only seen
the one text (the C++HTP) and not the others. I don't care for a formulaic
approach to writing programming books, where the author has a book already
in one language and then adapts it to other languages, but this approach is
quite common in the programming textbook arena, and I wouldn't single out
Deitel and Deitel on that point alone. The paper is thin and the binding
does suck, but the binding just came off of my Programming Python 2nd
edition this past month, and often that type of stuff is the publisher's
perogative and not the author's.
Anyhow, now I start to sound like I'm defending D&D, which I'm certainly
not. I was only expressing surprise at the general dislike for their book
that so many have posted in this thread, as it is counter to the opinions
I've encountered on their book in the past. In fact, I know some teachers
who think that their book is practically the C++ gospel or something. I
never had that high an opinion of their book. As I related, I didn't choose
it for the text when I taught C++. I considered several other books, and
ended up with the one by Walter Savitch. And while the narrative was very
good in Savtich's book, there not enough good exercises and programming
assignments for my high school students, and I was always having to search
other books for that type of stuff and often ended up using exercises out
of the Deitel's book. The exercises in C++HTP are very good for instructors
to assign to students and not many books have that type of stuff.
I'm currently teaching math at the University level, and it seems that I
have LOTS more time to prepare for class than I did at the high school
level, and I don't assign near as much work (I see the students far less
and they are supposed to be more responsible to take some initiative for
the learning on their own). So whether a book with so many exercises is
really necessary for college...still, when I was a student using that text,
I appreciated the availability of those exercises. Even if the instructor
didn't assign them I could do them on my own to my benefit. But for a high
school instructor, a book with a LOT of fairly good exercises has a lot of
appeal over a book with few. The students often don't read the book anyway,
and you can correct the information in the book in class if need be.
I wonder that the many exercises and code examples are not a large part of
the appeal of this text over some others.
Mats Wichmann
Laird) wrote:
:In article <u7vhn9g...@corp.supernews.com>,
:DeepBleu <Deep...@DeepBleu.org> wrote:
: .
: .
: .
:>> I would love to see books on Algorithms with Python (makes a perfect
:>> fit), and more advanced topics such as threads and extending python.
:>
:>I'd love to see something like that specially on threads and extending
:>Python. This is something I can use.
:>DeepBleu
:>
:>
:
:How would you feel if such material appeared in magazines rather than books?
Replying generically since I didn't start this thread, print magazine
articles tend to end up chopped by space constraints, and they
"expire" - if you happened to pick up a copy of that magazine, and it
doesn't get lost in your pile of 23,269 "I ought to go through this
someday" tech magazines in boxes out in the shed, then you have it.
If you missed it first time, and it's not on the web...
On the plus side, if the topic of the article is the one thing I'm
interested in, it's a lot more palatable than picking up yet-another
$50+ book.
Mats Wichmann
N D Efford
> I dislike Deitel & Deitel because of their casual disregard for
> correctness. I can't open any of their books without finding an error.
> In C++HTP, they illustrate "Circle" as a subclass of "Point".
...and compound the error by making Cylinder a subclass of Circle!
This has been there for at least the past three editions. Criticisms
of it in book reviews and other forums have not persuaded them to
correct the misconception.
Nick
Dinu Gherman
ji...@vega.starshine.org (Jim Dennis) wrote:
> I would love to see a good book on "patterns" in Python. I'd like
> it to be a simple booklet listing each of the GoF patterns, with a
> couple of examples of each. It would be fine if it also covered some
> additional patterns or some controversies or alternatives to the
> classic GoF patterns (like the Alex Martelli's Borg vs. the GoF
> Singleton).
There used to be a Python Pattern-SIG in former times:
http://www.python.org/sigs/pattern-sig/mission
I wonder how much interest there would be in a revival?
Dinu
Dean Goodmanson
>
> Dinu
YES!
I've found Python to be an excellent learning environment for personal
development in software engineering and computer science.
Especially since the advent of
href="http://www.mindview.net/Books/TIPython"
Bruce Eckel's _Thinking in Python_
and
http://vig.pearsoned.com/store/product/0,,store-562_banner-0_isbn-0130409561,00.html"
Thomas Christopher's _Python Programming Patterns_
Best Regards,
Dean
phil hunt
>Sheila King wrote:
>> That's funny. I'm not familiar with the Lippman/Lajoie book, but I
>> have a LOT of C++ texts here at home. And I learned C++ from the Deitel
>> and Deitel book, and thought it was pretty good. Later, when I taught
>> C++ I used it as a reference, although I didn't select it as the text
>> for my course. Most people I know who are familiar with the Deitel
>> and Deitel C++ text think it is very good.
>
>I dislike Deitel & Deitel because of their casual disregard for
>correctness. I can't open any of their books without finding an error.
>In C++HTP, they illustrate "Circle" as a subclass of "Point".
This could well be the case in a particular class hierarchy.
> In CHTP,
>they say it's a common programming error to use \n outside of a printf
>statement (it only works in printf statements, they say).
That's an absurd thing to say.
--
<"><"><"> Philip Hunt <ph...@comuno.freeserve.co.uk> <"><"><">
"I would guess that he really believes whatever is politically
advantageous for him to believe."
-- Alison Brooks, referring to Michael
Portillo, on soc.history.what-if
Dennis Roark
news:u7v372p...@corp.supernews.com:
> Then of course we'll see some professors assigning the D & D Python
> book as a textbook on a scripting language. How disgusting!
> DeepBleu
>
I suspect so, but it certainly won't be me. I plan on using the Mark
Lutz book Programming Python for an elective course next academic year.
I won't use the D&D C/C++ books either. I would like to see some
organized, printed material for GUI development in Python, but my
impression is that that area is still settling out and books are
premature.
Dennis Roark
news:a5rfo4.3...@kserver.org:
>
> That's funny. I'm not familiar with the Lippman/Lajoie book, but I
> have a LOT of C++ texts here at home. And I learned C++ from the
> Deitel and Deitel book, and thought it was pretty good. Later, when I
> taught C++ I used it as a reference, although I didn't select it as
> the text for my course. Most people I know who are familiar with the
> Deitel and Deitel C++ text think it is very good.
>
We must not know the same people. The Lippman/Lajoie book, as the
Lippman book that preceded it, are superb and actually useful for
learning and reference, although probably not for a first course.
Dennis Roark
...
> In
> fact, I know some teachers who think that their book is practically
> the C++ gospel or something. I never had that high an opinion of their
> book. As I related, I didn't choose it for the text when I taught C++.
> I considered several other books, and ended up with the one by Walter
> Savitch. And while the narrative was very good in Savtich's book,
> there not enough good exercises and programming assignments for my
> high school students, and I was always having to search other books
>
First books in C++ are mostly a dissappointing lot, surprisingly so.
The Lippman and Lajoie and books by Bruce Eckel are good for students
who have some familiarity with programming. I've used the Savitch and
Main and Savitch books, and a host of others searching for the "perfect
book". I've considered D&D, but I could never stomach its approach (not
truly object oriented from the ground up) and conceptual errors or
weaknesses (some mentioned in this thread). There will probably be many
grumbles with this suggestion, but the best I have found for the first
introduction is Lafore, Object Oriented Programming in C++. But I am
really interested in weaving Python into the CS courses including the
first year courses. I am taking tentative steps in that direction this
year and next.
Peter Hansen
>
> First books in C++ are mostly a dissappointing lot, surprisingly so.
> The Lippman and Lajoie and books by Bruce Eckel are good for students
> who have some familiarity with programming. I've used the Savitch and
> Main and Savitch books, and a host of others searching for the "perfect
> book". I've considered D&D, but I could never stomach its approach (not
> truly object oriented from the ground up) and conceptual errors or
> weaknesses (some mentioned in this thread). There will probably be many
> grumbles with this suggestion, but the best I have found for the first
> introduction is Lafore, Object Oriented Programming in C++. But I am
> really interested in weaving Python into the CS courses including the
> first year courses. I am taking tentative steps in that direction this
> year and next.
It was mentioned here in the past that Prof. Stefan Kremer at University
of Guelph (uoguelph.ca) was actively teaching Python to first-year students
in CS. Perhaps if you contact him you could gain the benefit of his
experience. (I don't think he reads this group.)
-Peter
Michael Hudson
> First books in C++ are mostly a dissappointing lot,
There may be a reason for this.
Cheers,
M.
--
I also feel it essential to note, [...], that Description Logics,
non-Monotonic Logics, Default Logics and Circumscription Logics
can all collectively go suck a cow. Thank you.
-- http://advogato.org/person/Johnath/diary.html?start=4
John Schmitt
My favourite C++ book is probably the Anderson & Anderson book:
If I were teaching again, this book would be high on my list of textbooks. I'd love to get other people's opinion on it, since we're on the subject of C++ books. Caution: I might be biased because I met Paul Anderson and thoroughly enjoyed talking to him.
John
-----Original Message-----
From: Dennis Roark [mailto:de...@NSPAMearthlink.net]
Sent: Monday, March 04, 2002 2:43 PM
To: pytho...@python.org
Subject: Re: Deitel and Deitel Book...
First books in C++ are mostly a dissappointing lot, surprisingly so.
[...]
Curtis Jensen
The cover, definitly didn't seem targeted to the college crowd, but more
to highschoolers.
No chapters on extending Python with C.
The XML chapters seemed to be an attempt to jump on the band wagon and
sell books.
All in all, I think the book is well written. The examples are usefull
enough to figure out what is going on without reading the chapter (good
for lazy programmers). I lent it to a (non-programmer) friend and he
found it more useful than the O'Reilly Python book.
Also, if your main intent for reviewing the book was for the money, I'd
suggest playing the lotto instead. Don't be so arogant that you think
that your time is so precious as to complain about a temporary,
predeterimined, pay scale. They were upfront in their monatary
compensation. If you don't like it, don't review the book.
--
Curtis Jensen
cje...@bioeng.ucsd.edu
http://www-bioeng.ucsd.edu/~cjensen/
FAX (425) 740-1451
Ramkumar Kashyap
non-intuitive manner and lose out on a big chunk of their audience.
Only a few of us that persevere, end up learning the language and even
fewer go on to achieve "GURU" status. Why is this?
I have seen several posts on CLP and the newbie tutors list, where
people mention that their first encounter with programming was in BASIC,
COBOL, Pascal, Fortran. They did not really make any progress, gave up
on programming. Now they are attempting once again, hoping things have
become a little easier.
I would like to know how the pattern was set to teach programming
languages. You do an introductory program like "Hello World", learn how
to compile and run it. Then jump into decision structures, loops,
functions, etc.
This is extremely non-intuitive to most people. Most 5,6,7 year olds
can speak fluently in their native languages, but how many of them could
tell you about vowels, consonants, nouns, verbs, adjectives. In fact
quite a few of them speak multiple languages, can easily differentiate
sentence structures in those languages, but would be hard-pressed to
give defintions of the above.
So how come in programming, we ALWAYS jump into the constructs of a
language, rather than just doing, gaining proficiency and then
understanding how it is put together?
I think that unless the approach to teaching Programming languages, is
changed and follows the more universal style of teaching spoke language
or verbal communication, Computer Programming for Everybody will remain
a dream.
Just my .02 cents
Ramkumar
Brad Clements
news:3C850173...@bioeng.ucsd.edu...
> The only disappointing parts for me were:
> No chapters on extending Python with C.
You can find a respectable (IMHO) chapter on extending and embedding in
"Professional Linux Programming", Wrox Press.
Strange place to bury it, but if you're in a bookstore some time check it
out. I'd like to know your opinion.
(I wrote it)
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Geoff Gerrietts
> This is extremely non-intuitive to most people. Most 5,6,7 year olds
> can speak fluently in their native languages, but how many of them could
> tell you about vowels, consonants, nouns, verbs, adjectives. In fact
> quite a few of them speak multiple languages, can easily differentiate
> sentence structures in those languages, but would be hard-pressed to
> give defintions of the above.
>
> So how come in programming, we ALWAYS jump into the constructs of a
> language, rather than just doing, gaining proficiency and then
> understanding how it is put together?
I think the analogy here is interesting and useful, and bears
consideration. I think that what you're asking for -- a reexamination
of the pedagogy surrounding computer programming -- is useful.
I would hesitate to suggest that your methodology is exactly
appropriate, though. Here's why:
- Go speak to a five or six year old child for a few hours. Engage
them in any conversation you like, but make them talk, make them use
the language for an expressive purpose. Their facility with the
language is reasonable at this age, but far from mastery. Only the
mentally disabled standardize at this level; even the stupid
standardize at grade 5 or older.
- Observe a two or three year old. Engage this child in conversation.
It won't last long, but try it.
For the space of around three years, a child is immersed almost
constantly, from waking to sleep, and even sometimes while asleep, in
language. For those first three years, the child is almost completely
incapable of making him or herself understood.
Some of this is the challenge of spoken language, the challenge of
making your voice modulate to form the right sounds. Much research
exists to show how young children can learn to sign long before they
can learn to speak; if you eliminate the difficulty of speaking, you
might get it down to age 2 or so. That's still 2 years in which the
child can barely be understood if at all, and another three before the
most basic constructs are reliably produced.
People don't get smarter as they get older, they just have a better
foundation for building on. It would be just as difficult for someone
to learn programming through reading or transcribing lots of text as
it would be for someone to learn French by riding the Metro all day
long.
People don't get "smarter" as they get older, though they do develop
strategies for learning that enable them to learn things more quickly.
Most of those strategies revolve around identifying patterns early,
and spending most of the learning time exploring the "borderline
behavior" that describes the limits of the pattern.
That's why we go into constructs early, because those are the
patterns. The next step for the educated learner is to explore the
limits of these patterns -- what they can and can't do. This is where
a great deal of practice can be immensely useful.
A heavily practice-based pedagogy could be a very good thing,
especially if the practical applications were designed to explore
recently-introduced concepts to show when the pattern applies, and
when it does not.
My belief is that most people find computer programming to be
difficult because logic is not the natural way people think; it is a
forced mode. People tend to think intuitively, using "gut feelings"
and good guesswork. That's the way we tend to summarize the knowledge
of our experiences: as gut feelings.
Expressing things in a purely logical fashion is consequently
difficult for people, and very few ever receive formal training in
logic. What's worse is that trying to teach logic at the fundamental
level doesn't immediately apply. Logic itself is a tool that a person
must learn to use, and could easily fill several courses by itself.
--
Geoff Gerrietts "Punctuality is the virtue of the bored."
<geoff at gerrietts net> --Evelyn Waugh
Christopher Encapera
few days ago, I would like to jump in here with my 1.5 cents. Perhaps
another limitation to this analogy is, it seems to me, that programming IS
syntax and it's manipulation, and meaning is to be found in the (meaningful)
manipulation of the data. A child, or adult, is inherently flexible when it
comes to syntax, but a computer is (inherently) not. Thus:
A child:
I want da purtee pituur
or
Give me give me give me give me
or
Will you show me the pretty picture please?
Whereas a computer accepts only (or some strict variant):
# Pseudo code for opening an imaging app, and sending output to print
device...
...
...
...
Thus, the need for jumping right into syntax immediately (if you want to
produce anything even remotely meaningful)
Also concerning logic, I think it would be (perhaps) more accurate to say
that people think (and solve most of their problems) at a higher level of
abstraction - more in the realm of "meanings" and "relationships" where many
different kinds of knowledge and inter-connectedness come into play. The
thought world of formal logic and mathematics is too rigid to be the sole
(or even a major factor) in most thinking. For example, my wife "thinks"
that my desk is "too messy" and that I need to "organize it", but what she
does not realize is that every pile is an organization (of sorts), and that
I...etc. etc (until the end of our hopefully "meaningful" lives :)
Christopher Encapera
Lantech.Com
chr...@lantech.com
502-267-4200
-----Original Message-----
From: Geoff Gerrietts [mailto:ge...@gerrietts.net]
Sent: Wednesday, March 06, 2002 1:32 PM
To: pytho...@python.org
Subject: Re: CP4E was Re: Deitel and Deitel Book...
Quoting Ramkumar Kashyap (rkas...@sympatico.ca):
> This is extremely non-intuitive to most people. Most 5,6,7 year olds
> can speak fluently in their native languages, but how many of them could
> tell you about vowels, consonants, nouns, verbs, adjectives. In fact
> quite a few of them speak multiple languages, can easily differentiate
> sentence structures in those languages, but would be hard-pressed to
> give defintions of the above.
>
> So how come in programming, we ALWAYS jump into the constructs of a
> language, rather than just doing, gaining proficiency and then
> understanding how it is put together?
I think the analogy here is interesting and useful, and bears
consideration. I think that what you're asking for -- a reexamination
of the pedagogy surrounding computer programming -- is useful.
I would hesitate to suggest that your methodology is exactly
appropriate, though. Here's why:
...
My belief is that most people find computer programming to be
difficult because logic is not the natural way people think; it is a
forced mode. People tend to think intuitively, using "gut feelings"
and good guesswork. That's the way we tend to summarize the knowledge
of our experiences: as gut feelings.
Expressing things in a purely logical fashion is consequently
difficult for people, and very few ever receive formal training in
logic. What's worse is that trying to teach logic at the fundamental
level doesn't immediately apply. Logic itself is a tool that a person
must learn to use, and could easily fill several courses by itself.
...
Geoff Gerrietts
> [...]
> A child, or adult, is inherently flexible when it comes to syntax,
> but a computer is (inherently) not.
> Thus, the need for jumping right into syntax immediately (if you
> want to produce anything even remotely meaningful)
A point well taken, but also note that when we set out to learn a new
language, the most effective teaching methodologies rely on pointing
out the patterns in that language very early on: you learn to
conjugate verbs, learn proper forms of address, etc. Later, you learn
more complicated variations on the patterns (past tense, past perfect
tense, possessives, prepositional phrases, etc).
Whereas the five-year-old will learn to speak by absorbing the
language "in the wild", the student will try to apprehend it by
absorbing the patterns, then learning the limits of those patterns
through application and introduction of new patterns.
These techniques are naturally more successful when the student is
immersed in an environment rich with opportunity to encounter those
limits.
> Also concerning logic, I think it would be (perhaps) more accurate
> to say that people think (and solve most of their problems) at a
> higher level of abstraction - more in the realm of "meanings" and
> "relationships" where many different kinds of knowledge and
> inter-connectedness come into play.
I think you're right. I'm trying to oversimplify intuition, or maybe
oversimplify what we're really talking about by calling it intuition.
Logic is both less subjective and less forgiving, and it operates at a
much more concrete level of thought.
--G.
--
Geoff Gerrietts <geoff at gerrietts net>
"I have read your book and much like it." --Moses Hadas
Aahz Maruch
Curtis Jensen <cje...@bioeng.ucsd.edu> wrote:
>
>Also, if your main intent for reviewing the book was for the money, I'd
>suggest playing the lotto instead. Don't be so arogant that you think
>that your time is so precious as to complain about a temporary,
>predeterimined, pay scale. They were upfront in their monatary
>compensation. If you don't like it, don't review the book.
Huh??? Can anybody explain where this paragraph comes from?
--
--- Aahz <*> (Copyright 2002 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
"Argue for your limitations, and sure enough they're yours." --Richard Bach
Grant Edwards
> People don't get smarter as they get older,
They certainly do (using just about any definition of "smarter"
I can imagine) for the first year or two while the nervous
system completes mylenization.
After that, you may be able come up with a definition of
"smarter" for which your statement is true.
> People don't get "smarter" as they get older, though they do develop
> strategies for learning that enable them to learn things more quickly.
I'd call that getting smarter. :)
--
Grant Edwards grante Yow! Imagine--a WORLD
at without POODLES...
visi.com
Stephen J. Turnbull
Brad> You can find a respectable (IMHO) chapter on extending and
Brad> embedding in "Professional Linux Programming", Wrox Press.
Brad> Strange place to bury it, but if you're in a bookstore some
Brad> time check it out. I'd like to know your opinion.
I thought it was clear, although I haven't tried to apply it yet.
(I'm a co-author)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
Jeff Hinrichs
"Geoff Gerrietts" <ge...@gerrietts.net> wrote in message
news:mailman.101543990...@python.org...
point well before 3 years. In fact, by 12-16 months they have the ability to
utter rudimentary words, associate action and reaction and are deeply
focused on interpersonal relationships, among other things. First words are
normally, familial (i.e mom/dad/et al), then "NO," then "More" with a slew
of words of interest to them come next.
> Some of this is the challenge of spoken language, the challenge of
> making your voice modulate to form the right sounds. Much research
> exists to show how young children can learn to sign long before they
> can learn to speak; if you eliminate the difficulty of speaking, you
> might get it down to age 2 or so. That's still 2 years in which the
> child can barely be understood if at all, and another three before the
> most basic constructs are reliably produced.
>
> People don't get smarter as they get older, they just have a better
> foundation for building on. It would be just as difficult for someone
> to learn programming through reading or transcribing lots of text as
> it would be for someone to learn French by riding the Metro all day
> long.
This depends on how you define "smart." I refer to smart as the mixture of
wisdom + experience + ability to intuit. <wink>
> People don't get "smarter" as they get older, though they do develop
> strategies for learning that enable them to learn things more quickly.
> Most of those strategies revolve around identifying patterns early,
> and spending most of the learning time exploring the "borderline
> behavior" that describes the limits of the pattern.
>
> That's why we go into constructs early, because those are the
> patterns. The next step for the educated learner is to explore the
> limits of these patterns -- what they can and can't do. This is where
> a great deal of practice can be immensely useful.
>
> A heavily practice-based pedagogy could be a very good thing,
> especially if the practical applications were designed to explore
> recently-introduced concepts to show when the pattern applies, and
> when it does not.
>
> My belief is that most people find computer programming to be
> difficult because logic is not the natural way people think; it is a
> forced mode. People tend to think intuitively, using "gut feelings"
> and good guesswork. That's the way we tend to summarize the knowledge
> of our experiences: as gut feelings.
I agree with you here.
> Expressing things in a purely logical fashion is consequently
> difficult for people, and very few ever receive formal training in
> logic. What's worse is that trying to teach logic at the fundamental
> level doesn't immediately apply. Logic itself is a tool that a person
> must learn to use, and could easily fill several courses by itself.
>
> --
> Geoff Gerrietts "Punctuality is the virtue of the bored."
> <geoff at gerrietts net> --Evelyn Waugh
I do believe that Ramkumar's point is valid. <my $0.02>Children, especially
the young, suffer from fewer of the social pressures that retard adult
learning. The most salient, is the disregard for being wrong. Adults, I
believe, hamper their own learning process by limiting their questions or
not asking them if they feel that by exposing their "knowledge holes" they
are negatively impacting the social surroundings. (i.e. Don't want to look
stupid in front of the class.) Unfortunately, the fastest way to learn
something new is to expose your limited knowledge to the
teacher/instructor/peers so that they can more effectively rid you of
misconceptions and fill-in those "knowledge holes." I have a strong
suspicion this is why adults have a relatively more difficult time learning
new spoken languages than children do. (vocabulary that is, pronunciation is
another issue) </my $0.02>
Grant Edwards
> *BUZZ* Sorry, but as a parent I can firmly say that children
> can make a point well before 3 years. In fact, by 12-16 months
> they have the ability to utter rudimentary words, associate
> action and reaction and are deeply focused on interpersonal
> relationships, among other things. First words are normally,
> familial (i.e mom/dad/et al), then "NO," then "More" with a
> slew of words of interest to them come next.
Even before they can enunciate words verbally, they can learn
words through sign language. My nephews both learned 5-10
words of ASL before they were a year old. Once their ability
to make speach sounds develops sufficiently they quickly forget
the signs. Screaming "more!" at the top of one's lungs is
evidently much more satisfying than making the sign with one's
hands.
--
Grant Edwards grante Yow! I wonder if I ought
at to tell them about my
visi.com PREVIOUS LIFE as a COMPLETE
STRANGER?
Geoff Gerrietts
> "Geoff Gerrietts" <ge...@gerrietts.net> wrote in message
> news:mailman.101543990...@python.org...
> > Quoting Ramkumar Kashyap (rkas...@sympatico.ca):
> > For the space of around three years, a child is immersed almost
> > constantly, from waking to sleep, and even sometimes while asleep, in
> > language. For those first three years, the child is almost completely
> > incapable of making him or herself understood.
>
> *BUZZ* Sorry, but as a parent I can firmly say that children can
> make a point well before 3 years. In fact, by 12-16 months they have
> the ability to utter rudimentary words, associate action and
> reaction and are deeply focused on interpersonal relationships,
> among other things. First words are normally, familial (i.e
> mom/dad/et al), then "NO," then "More" with a slew of words of
> interest to them come next.
I'm a parent, too, and there's a big difference between "daddy",
"mommy", and the pronouncements that come from a child anywhere on up
to 18 months and spoken language.
At three (in April), my son speaks more or less complete sentences
with occassional nods to the rules of grammar. About 3/4 of the time
my wife and I understand him. About 1/4 of the time, others can
understand him. And he's pretty advanced for his age; a lot of parents
guess him at older.
That's like saying that I speak French because I know how to say "oui"
and "merci". You might make that claim, but expecting a Parisian to
hold a conversation with me is somewhat unreasonable.
What is it about internet discussion forums that makes everyone
struggle to find grounds to argue rather than make an effort to
understand?
> > People don't get smarter as they get older, they just have a better
> > foundation for building on. It would be just as difficult for someone
> > to learn programming through reading or transcribing lots of text as
> > it would be for someone to learn French by riding the Metro all day
> > long.
> This depends on how you define "smart." I refer to smart as the mixture of
> wisdom + experience + ability to intuit. <wink>
Again, this is begging the question, and after two pointless arguments
niggling over the semantics of "smarter", I'm starting to get a little
annoyed. I can define smarter as "having a higher IQ", as "best
educated", or as "most able to solve a given problem" and all of them
work pretty well. Right now I'm talking about ability to ingest raw
information and retain it. It's clear I should have been a little more
explicit; I guess terms like "smarter" are just begging for people to
fight.
> > My belief is that most people find computer programming to be
> > difficult because logic is not the natural way people think; it is a
> > forced mode. People tend to think intuitively, using "gut feelings"
> > and good guesswork. That's the way we tend to summarize the knowledge
> > of our experiences: as gut feelings.
> I agree with you here.
I think a previous poster has pointed out that I oversimplify here by
reducing abstract thinking to intuition and gut feelings, but I think
we all kinda get the point, when we're thinking in that mode.
> I do believe that Ramkumar's point is valid. <my $0.02>Children, especially
> the young, suffer from fewer of the social pressures that retard adult
> learning. The most salient, is the disregard for being wrong. Adults, I
> believe, hamper their own learning process by limiting their questions or
> not asking them if they feel that by exposing their "knowledge holes" they
> are negatively impacting the social surroundings. (i.e. Don't want to look
> stupid in front of the class.) Unfortunately, the fastest way to learn
> something new is to expose your limited knowledge to the
> teacher/instructor/peers so that they can more effectively rid you of
> misconceptions and fill-in those "knowledge holes." I have a strong
> suspicion this is why adults have a relatively more difficult time learning
> new spoken languages than children do. (vocabulary that is, pronunciation is
> another issue) </my $0.02>
I'm not sure that adults do. I think that your average diplomat who
needs a speed-training in a foreign language, can master
conversational language within a few months, and can be highly fluent
inside a year. It requires careful coursework supplemented by a great
deal of practice. Immersion is helpful, which (when we get back to the
start of the thread) is the sentiment that started the whole thing.
By contrast, the child can't converse effectively with his peers for
three to four years, and can't hold his own in a conversation with an
adult for even longer than that.
Maybe a slight switch in topic: if the logical constructs are
disorienting, how would we approach instruction? Hello World seems to
go okay, right? (Do we have anything like a consensus from this?) But
then where do we go? More examples?
I'm not sure what my goal is here, but it seems like we started with
an idea on how we could make computer programming more accessible for
everyone, including those whose relationship with logical thought can
only be described as "dysfunctional", but starting with those who are
at least making occassional sallies at the task of learning.
So where do we go next? If not "if", then what? Or do we go ahead with
"if" and "else", but abuse it with lots of examples?
Looking back at the pieces of pedagogical literature I've been exposed
to, I'm led to believe that learning (at least in children) occurs in
response to encountered frustrations with the limits of the current
knowledge base. Can we assemble something that looks like a cooked
series of examples or sample problems that exploit this?
--G.
--
Geoff Gerrietts <geoff at gerrietts dot net>
I AM YOUR KING! BOW BEFORE ME, PEASANT! -- Dogbert
Jeff Hinrichs
[...snip..]
> Maybe a slight switch in topic: if the logical constructs are
> disorienting, how would we approach instruction? Hello World seems to
> go okay, right? (Do we have anything like a consensus from this?) But
> then where do we go? More examples?
After Hello World would be Echo.
Echo is simply a single iteration of raw_input then print. Now the student
interact with their code. Teaching has always gone from Hello to If/Then
the true amazement of computers for pristine newbies is interaction. So
Echo.py would be the next step and one that would be built on for a few
iterations as control structures and type conversion and formatting were
introduced. At every step an example that interacts with the user is
presented.
Next would be an example This.py. The concept of the If/then statement is
presented. Else is ignored for now. The program would echo input that
matched the If statement otherwise it would output nothing.
and so on...
> I'm not sure what my goal is here, but it seems like we started with
> an idea on how we could make computer programming more accessible for
> everyone, including those whose relationship with logical thought can
> only be described as "dysfunctional", but starting with those who are
> at least making occassional sallies at the task of learning.
> So where do we go next? If not "if", then what? Or do we go ahead with
> "if" and "else", but abuse it with lots of examples?
> Looking back at the pieces of pedagogical literature I've been exposed
> to, I'm led to believe that learning (at least in children) occurs in
> response to encountered frustrations with the limits of the current
> knowledge base. Can we assemble something that looks like a cooked
> series of examples or sample problems that exploit this?
I think that we can, if we start by jumping from Hello World to another
equally simple example such as Echo.
I've suggested a beginning. It should introduce only one or two new things
at a time. Always looking to "shy away" from exceptions. The concept of
over-generalization that can be refined as the examples progress.
Would you be interested in pursuing this further?
Geoff Gerrietts
> What is it about internet discussion forums that makes everyone
> struggle to find grounds to argue rather than make an effort to
> understand?
I was probably being unfair here. Read here frustration at feeling
like the point's been missed for the lint-picking.
> Again, this is begging the question, and after two pointless arguments
> niggling over the semantics of "smarter", I'm starting to get a little
> annoyed. I can define smarter as "having a higher IQ", as "best
> educated", or as "most able to solve a given problem" and all of them
> work pretty well. Right now I'm talking about ability to ingest raw
> information and retain it. It's clear I should have been a little more
> explicit; I guess terms like "smarter" are just begging for people to
> fight.
And here at least I admit it's my fault, if a little late in the
issue.
I've tried to recast this discussion away from the specifics of my
first article and toward the issues, lest they get lost. I just want
to apologize in advance for letting my frustrations show, lest I give
insult where none was intended or deserved.
I'd rather the thread be intellectually provacative than
provocational, if we can manage it; pedagogy is of interest to me.
Thanks,
--G.
--
Geoff Gerrietts <geoff at gerrietts dot net>
"Ordinarily he was insane, but he had lucid moments
when he was merely stupid." --Heinrich Heine
Simon Brunning
> I'm a parent, too, and there's a big difference between "daddy",
> "mommy", and the pronouncements that come from a child anywhere on up
> to 18 months and spoken language.
>
> At three (in April), my son speaks more or less complete sentences
> with occassional nods to the rules of grammar. About 3/4 of the time
> my wife and I understand him. About 1/4 of the time, others can
> understand him. And he's pretty advanced for his age; a lot of parents
> guess him at older.
But I'll bet that your son has been making himself understood for some time,
and he isn't three yet. I *can't* agree that "For those first three years,
the child is almost completely incapable of making him or herself
understood."
And his 'nods to the rules of grammar' are almost certainly a lot more
accurate than you think. Children his age get things right the vast
majority of the time. It's just that the errors stand out. Again, Pinker
talks about this in 'The Language Instinct'.
Cheers,
Simon Brunning
TriSystems Ltd.
sbru...@trisystems.co.uk
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
Simon Brunning
> constantly, from waking to sleep, and even sometimes while asleep, in
> incapable of making him or herself understood.
Children are able to make themselves understood to some extent by a year or
so, well in advance of their use of grammatical constriction.
Soon after that, they start to put words together into proto-sentences.
Again, they are understood. This is at least partly because patents make an
effort to understand malformed sentences. Computers don't do this!
(Interestingly, though children miss parts of sentences out at this age, and
for some time to come, they usually get those parts of the sentence that
they do use in the correct order. Stephen Pinker's 'The Language Instinct'
is a *facinating* read if you find this sort of thing even remotely
interesting - I cannot recommend it too highly.)
It seems to me that there are two differences between natural languages and
computer languages. Firstly, all children are natural geniuses with natural
language. Secondly, when using a natural language imperfectly, one can still
make oneself understood. (I certainly hope so, for my sake!) This isn't the
case with computer languages.
So I don't think that computer languages can be learned in the same way as
natural languages. Children learn language by a combination of instinct and
trial-and-error. We don't *have* a computer language instinct - only Guido
has one of those - and trial-and-error will just mean
trial-and-syntax-error.
Roman Suzi
> non-intuitive manner and lose out on a big chunk of their audience.
> Only a few of us that persevere, end up learning the language and even
> fewer go on to achieve "GURU" status. Why is this?
>
> I have seen several posts on CLP and the newbie tutors list, where
> people mention that their first encounter with programming was in BASIC,
> COBOL, Pascal, Fortran. They did not really make any progress, gave up
> on programming. Now they are attempting once again, hoping things have
> become a little easier.
I think, the initial language has nothing to do with later gaving up
programming. These same thoughts bother me for several years already and I
came to the decision that almost nothing does matter: only motivation to
continue learning programming. Then certain barrier falls and a person is
from that point capable of programming (in any language, as it is
universal skill). It's like mastering bicycle or learning to swim.
> I would like to know how the pattern was set to teach programming
> languages. You do an introductory program like "Hello World", learn how
> to compile and run it. Then jump into decision structures, loops,
> functions, etc.
>
> This is extremely non-intuitive to most people. Most 5,6,7 year olds
> can speak fluently in their native languages, but how many of them could
> tell you about vowels, consonants, nouns, verbs, adjectives. In fact
> quite a few of them speak multiple languages, can easily differentiate
> sentence structures in those languages, but would be hard-pressed to
> give defintions of the above.
>
> So how come in programming, we ALWAYS jump into the constructs of a
> language, rather than just doing, gaining proficiency and then
> understanding how it is put together?
>
> I think that unless the approach to teaching Programming languages, is
> changed and follows the more universal style of teaching spoke language
> or verbal communication, Computer Programming for Everybody will remain
> a dream.
>
> Just my .02 cents
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Roman Suzi
> > From: Geoff Gerrietts [SMTP:ge...@gerrietts.net]
> > For the space of around three years, a child is immersed almost
> > constantly, from waking to sleep, and even sometimes while asleep, in
> > language. For those first three years, the child is almost completely
> > incapable of making him or herself understood.
Are you sure? My daughter makes herself understood by all available
means. She built her own dictionary which we, parents, learned.
What is interesting, she uses (internally) a hash table to
convert from our language to her almost instantly...
Our observations tell us that children differ in their ways. E.g. some of
them unthinkingly repeat lots of words and even sentences, while our child
uses only what she understands. Some others do not talk at all and
then at once speak clearly in sentences.
I guess, adults can also be categorized by their approach in learning
languages. And trial-and-error is, IMHO, also needed to learn computer
languages. I can't imaging someone writing right from the start
after studying docs and specs.
I do not remember who told me this, but it seems that students
better learn from poorly constructed lectures than perfect ones.
Because, they need to be _active_ in constructing their own system
rather than _passively_ "eat" readymaid knowledge frames.
So, a bad book (with errors, inconsistencies, etc) is not necessary bad
for learning purposes (if it covers enough of a subject).
> So I don't think that computer languages can be learned in the same way as
> natural languages. Children learn language by a combination of instinct and
> trial-and-error. We don't *have* a computer language instinct - only Guido
> has one of those - and trial-and-error will just mean
> trial-and-syntax-error.
IMHO, children do not only learn language, they also build their
interpreter for themselves as nobody provide them with the
source, only flying in the air binaries ;-)
Gustavo Cordova
> By contrast, the child can't converse effectively with his peers for
> three to four years, and can't hold his own in a conversation with an
> adult for even longer than that.
>
This is a little something which has always piqued my
curiosity. It's true that children sometimes don't make
much sense to us ("TO US") until they have breached a
certain threshold in knowledge / social rules / vocabulary.
But, what about identical twins, who speak their own language
well before they start speaking their parents? Aren't they
communicating with their peer(s)?
I'm not criticising your comment, actually I'm probably
proving it by providing the exception :-)
Sometimes I wonder if I'd have twice the fun if I was two,
er, had a twin. :-) Or maybe I'd be twice as silly and make
half as much sense.
Have a nice thursday :-)
-gustavo
Andy Gimblett
> But, what about identical twins, who speak their own language
> well before they start speaking their parents? Aren't they
> communicating with their peer(s)?
It's not just twins - older children sometimes act as "interpreters"
for their younger siblings.
--
Andy Gimblett - Programmer - Frontier Internet Services Limited
Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
Statements made are at all times subject to Frontier's Terms and
Conditions of Business, which are available upon request.
David C. Ullrich
<rkas...@sympatico.ca> wrote:
>I find that most introductory books approach programming in a
>non-intuitive manner and lose out on a big chunk of their audience.
> Only a few of us that persevere, end up learning the language and even
>fewer go on to achieve "GURU" status. Why is this?
>
>I have seen several posts on CLP and the newbie tutors list, where
>people mention that their first encounter with programming was in BASIC,
>COBOL, Pascal, Fortran. They did not really make any progress, gave up
>on programming. Now they are attempting once again, hoping things have
>become a little easier.
>
>I would like to know how the pattern was set to teach programming
>languages. You do an introductory program like "Hello World", learn how
>to compile and run it. Then jump into decision structures, loops,
>functions, etc.
>
>This is extremely non-intuitive to most people. Most 5,6,7 year olds
>can speak fluently in their native languages, but how many of them could
>tell you about vowels, consonants, nouns, verbs, adjectives. In fact
>quite a few of them speak multiple languages, can easily differentiate
>sentence structures in those languages, but would be hard-pressed to
>give defintions of the above.
>
>So how come in programming, we ALWAYS jump into the constructs of a
>language, rather than just doing, gaining proficiency and then
>understanding how it is put together?
Because a child can make himself understood even though he's speaking
with atrocious grammar, while invalid code doesn't do anything but
generate an error message?
>I think that unless the approach to teaching Programming languages, is
>changed and follows the more universal style of teaching spoke language
>or verbal communication, Computer Programming for Everybody will remain
>a dream.
David C. Ullrich
Brad Clements
news:873czdn...@tleepslib.sk.tsukuba.ac.jp...
> >>>>> "Brad" == Brad Clements <b...@Murkworks.com> writes:
>
> I thought it was clear, although I haven't tried to apply it yet.
>
> (I'm a co-author)
Heh, greetings, funny meeting you here!
It's hard to tell which chapter you wrote.. or which picture is yours...
Geoff Gerrietts
> On Thu, 7 Mar 2002, Simon Brunning wrote:
>
> > > From: Geoff Gerrietts [SMTP:ge...@gerrietts.net]
> > > For the space of around three years, a child is immersed almost
> > > constantly, from waking to sleep, and even sometimes while asleep, in
> > > language. For those first three years, the child is almost completely
> > > incapable of making him or herself understood.
>
> Are you sure? My daughter makes herself understood by all available
> means. She built her own dictionary which we, parents, learned.
> What is interesting, she uses (internally) a hash table to
> convert from our language to her almost instantly...
I think I've answered this complaint with the original post several
times already, so I'm not going to do it again. As a nutshell, I'll
say that the range concepts a child is capable of expressing at this
age is much smaller than the range of concepts a child experiences --
barely one percent of the feelings you see flashing across the child's
face make it into language, spoken or gestured. That qualifies to me
as "almost completely incapable of making him or herself understood."
> I do not remember who told me this, but it seems that students
> better learn from poorly constructed lectures than perfect ones.
> Because, they need to be _active_ in constructing their own system
> rather than _passively_ "eat" readymaid knowledge frames.
This is an interesting point, and might be wrapped back into our
developing idea of a pedagogy. Building in defects might not be the
best idea, because that's likely to lead to criticism and even
dismissal by those who recognize the errors. But building in problems
that expect the student to engage the material and fill in the blanks,
that's something of an admirable goal.
Thanks,
--G.
--
Geoff Gerrietts "Democracy is a form of government that substitutes
geoff at gerrietts dot net election by the incompetant many for appointment
http://www.gerrietts.net/ by the corrupt few." --George Bernard Shaw
Ramkumar Kashyap
Somebody in this thread raised the point that the logic involved in programming in not intuitive. I agree with that. The point I want to make is that there are programs like Hooked-on-Phonics, and other remedial language programs that are quite effective in raising the literacy levels among adults.
Another point (this is purely from observation and others with children may want to corroborrate) is that children tend to learn faster and retain longer with repetition. I don't know if there are any people on CLP who are also conversant with the human brain and can shed light on the formation of new neural pathways etc.
I should also confess that I have an ulterior motive in this discussion, which is to teach my kid to program, (which is still a few years away).
regards,
Ramkumar
Geoff Gerrietts
I think we should. I like the idea of starting with an interaction.
Your observation that interactivity interests new users is dead on; I
can remember being in exactly that same boat.
We might set out from Hello, World with the idea of making Hello,
Name. Develop Echo as a "here's the source, let's talk about it" then
follow it up with "now see if you can make "hello, name" work, based
on the original Hello World. No real new challenges there, but
learning to output a constant string and a variable on the same line
might be interesting for the student, and if they don't get it, tell
them a few ways to solve that problem "on the next page".
Do we want to take them through a few steps on how to pretty up the
output? Probably not, huh?
Then we move to the traditional Number Guess game. Discuss if, suggest
the need for else.
I'm trying to get granular here, trying to build in both the need for
the student to engage and think about the topic at hand while
maintaining interest and a real sense of progress.
When do we start immersing them with "useful examples" they should
try? After we get through if / else?
Am I trying to get too low-level? Do we want to stay above the clouds,
keep this as a heuristic for teaching rather than a specific
curriculum?
--
Geoff Gerrietts <geoff at gerrietts dot net>
Mats Wichmann
wrote:
:On Thu, 7 Mar 2002, Simon Brunning wrote:
:
:> > From: Geoff Gerrietts [SMTP:ge...@gerrietts.net]
:> > For the space of around three years, a child is immersed almost
:> > constantly, from waking to sleep, and even sometimes while asleep, in
:> > language. For those first three years, the child is almost completely
:> > incapable of making him or herself understood.
:
:Are you sure? My daughter makes herself understood by all available
:means. She built her own dictionary which we, parents, learned.
:What is interesting, she uses (internally) a hash table to
:convert from our language to her almost instantly...
I have to say, my daughter made herself well understood to the
listeners that matters long before speaking an intelligible word.
:Our observations tell us that children differ in their ways. E.g. some of
:them unthinkingly repeat lots of words and even sentences, while our child
:uses only what she understands. Some others do not talk at all and
:then at once speak clearly in sentences.
:
:I guess, adults can also be categorized by their approach in learning
:languages. And trial-and-error is, IMHO, also needed to learn computer
:languages. I can't imaging someone writing right from the start
:after studying docs and specs.
There have been several distinct learning styles identified, and
unfortunately, one of the shortcomings of schools is that it's
impossible to cater to all styles at once. Even within these styles,
there are clear variations.
Some people only "learn" from reading detailed descriptions, but I
believe they're in a minority, and, proficiency still requires
application, and particularly trial-and-error learning.
:I do not remember who told me this, but it seems that students
:better learn from poorly constructed lectures than perfect ones.
:Because, they need to be _active_ in constructing their own system
:rather than _passively_ "eat" readymaid knowledge frames.
I don't know about learning more from poorly constructed lectures;
that doesn't jibe with my own experiences, although I see the point
being made. The active participation is certainly important, and there
are techniques that can be used in a classroom that promote such
participation - much harder with a book. I do recall that lectures
that had demonstrations that didn't work (I had a Physics professor
who always had the experiments fail) were more instructive than the
demos that did work, because they did seem to make you think, whereas
success was just, "okay, that's what you said, so what?"
:So, a bad book (with errors, inconsistencies, etc) is not necessary bad
:for learning purposes (if it covers enough of a subject).
I think that's a stretch. Bad books have stopped me almost dead on a
subject, unless I had a personal reason why I needed to push through.
I'm closer to conceding the point on lectures... a classroom situation
is by its' nature more interactive, a bad book can stop any
interaction.
Mats Wichmann
Geoff Gerrietts
> Somebody in this thread raised the point that the logic involved in
> programming in not intuitive. I agree with that. The point I want to
> make is that there are programs like Hooked-on-Phonics, and other
> remedial language programs that are quite effective in raising the
> literacy levels among adults.
Yes! And I'm interested in getting to the point of at least some
general pointers toward how to go about teaching languages. In my
professional capacity, I'm often called on to teach programming
concepts to my peers, or to provide training on various aspects of a
project's architecture. Some of that is because of my background, some
of it is because I don't mind doing it nearly as much as the average
engineer.
> Another point (this is purely from observation and others with children
> may want to corroborrate) is that children tend to learn faster and
> retain longer with repetition. I don't know if there are any people on
> CLP who are also conversant with the human brain and can shed light on
> the formation of new neural pathways etc.
I know just enough to spout off like I know a lot, but I think others
can talk more. I think I'll refrain from spouting too much....
I will say that I think the gender thing is a biological difference,
though. Women, especially when younger, have better cooperation
between their "left" and "right" brain. This makes them great at a lot
of things. Men have less cooperation, which makes them better at
focussing on a single task.
This is (of course) a gross overgeneralization. When you actually
trace into the neuroscience around it, all the "except" and "but you
hafta understand" conditions mitigate this down to a discernable trend
but nothing like an absolute.
I think that maybe there's a way to build in appeal for highly
coordinated thinkers, too -- I learned to program largely by thinking
of it as a more challenging form of poetry -- but I'm not sure how to
make that appeal broad.
(Maybe saying something about gender differences is too controversial,
so if you're feeling like I need a good flaming, consider how your
flame will contribute to the development of teaching strategies,
please!)
> I should also confess that I have an ulterior motive in this
> discussion, which is to teach my kid to program, (which is still a
> few years away).
Hee! Me too. I think the best advice I've gotten so far is to do it
and enjoy it and make it accessible. I'm personally thinking that
I'm going to use Lego Mindstorms as a starting point. He likes Legos,
likes robots, and in a few years, he might be able to put them
together....
--G.
Jeff Hinrichs
> Quoting Jeff Hinrichs (j...@cox.net):
> >
> > Would you be interested in pursuing this further?
>
> I think we should. I like the idea of starting with an interaction.
> Your observation that interactivity interests new users is dead on; I
> can remember being in exactly that same boat.
>
> We might set out from Hello, World with the idea of making Hello,
> Name. Develop Echo as a "here's the source, let's talk about it" then
> follow it up with "now see if you can make "hello, name" work, based
> on the original Hello World. No real new challenges there, but
> learning to output a constant string and a variable on the same line
> might be interesting for the student, and if they don't get it, tell
> them a few ways to solve that problem "on the next page".
>
> Do we want to take them through a few steps on how to pretty up the
> output? Probably not, huh?
list there is talk of left/right brain types. Perhaps we should give the
other hemisphere something to focus on. Not too much at this point but
enough to partially appease the asthetic insticnts in some.
> Then we move to the traditional Number Guess game. Discuss if, suggest
> the need for else.
>
> I'm trying to get granular here, trying to build in both the need for
> the student to engage and think about the topic at hand while
> maintaining interest and a real sense of progress.
This might be the proper time to come to a concensus on what the outcome of
this educational experience should be. If we are after CP4E then we should
probably not attack the problem with any idea that these students are going
to become CS majors in college. If we can create an environment that opens
up a section of their mind about how programs work they would benefit in any
academic or business related activity that involved computers. We should do
nothing to stunt the growth of potential CS majors but our focus should be
on programming for people who probably won't be professional programmers. I
apologize for the clumsiness of the above description but I haven't put all
of my thoughts together yet.
> When do we start immersing them with "useful examples" they should
> try? After we get through if / else?
The next natural construct after if/then/else are loops. But maybe we
should move to something a bit more right brained<wink> so as not to loose
our hypothetical students? And then move to loops?
> Am I trying to get too low-level? Do we want to stay above the clouds,
> keep this as a heuristic for teaching rather than a specific
> curriculum?
Perhaps a happy medium between a nose bleed view and having their nose in
the dirt. Python is great for keeping your nose out of the dirt for many
applications. You can put it their if it suits you but it's not a
requirement.
> --
> Geoff Gerrietts <geoff at gerrietts dot net>
> "Ordinarily he was insane, but he had lucid moments
> when he was merely stupid." --Heinrich Heine
-Jeff
Peter Hansen
>
> I do not remember who told me this, but it seems that students
> better learn from poorly constructed lectures than perfect ones.
> Because, they need to be _active_ in constructing their own system
> rather than _passively_ "eat" readymaid knowledge frames.
Wow. Deep... I like this (to me) completely new idea.
Anyone know where it came from? References to a study or something?
Someone I know worked for months (on and off) on a presentation that
could have been done (imperfectly) in a week. When it was presented,
the reception seemed to me rather luke-warm, in spite of apparently
strong interest in the audience ahead of it (and after). The
presentation struck me at the time as being _very_ "polished", but
perhaps with too little unsaid for someone to question, or think
about. I suspect this is the reason why it didn't seem to work.
-Peter
Stephen J. Turnbull
Ramkumar> My original intent for starting the thread was because I
Ramkumar> truly believe in CP4E.
I used to. Then I started doing I18N. Then I didn't. Computers and
humans communicate with other entities in very different ways.
CUse4E is a different matter. You _can_ program computers to do a
damn good job of translating a human's idea of "precise description"
into something that can be used to efficiently query a database.
But at that point the human is no longer engaged in programming. A
human dependent on that level of cooperation is not capable of fixing
what's broke. My 2-1/2 year old daughter was quite capable of drawing
on the screen with the mouse, and was good enough to learn to click
the "close" button once she figured out that made Daddy really proud.
(Now that she's 4-1/2 she's into Lego and makeup. Go figure.... But
she still turns off the TV when she leaves the room.)
Programmer? Uh-uh. Not even Grandma will claim that.
Ramkumar> The point I want to make is that there are programs like
Ramkumar> Hooked-on-Phonics, and other remedial language programs
Ramkumar> that are quite effective in raising the literacy levels
Ramkumar> among adults.
Which do this precisely by taking all the rigor out, and depending on
intuition and subconscious processes. "You know it when you see
it"---but you don't know _why_. Problem is, there is no way to
guarantee that a trained neural network will be a generalization of
the data it was trained on.
Japanese education is heavily oriented to imitate-the-teacher
learning-by-doing. It shows in their programs (my sample is of course
published free software programs and patches to other free software
programs; I don't know what the professionals are doing---I do know
that it's one field where foreigners are often preferred to natives),
and the way they apparently _can_ not convert their patches to forms
that would be acceptable in an internationalized application.
I don't think this is a biological thing the way the male/female
difference seems to be, and probably not even terribly deeply embedded
in culture. I don't think it would take much to teach programming to
Japanese high school students. But I think that it is evidence that
Hooked-on-Python is not going to be a path to CP4E.
Geoff Gerrietts
> Roman Suzi wrote:
> >
> > I do not remember who told me this, but it seems that students
> > better learn from poorly constructed lectures than perfect ones.
> > Because, they need to be _active_ in constructing their own system
> > rather than _passively_ "eat" readymaid knowledge frames.
>
> Wow. Deep... I like this (to me) completely new idea.
This idea was new to me, too, in form but not in concept. Pedagogical
coursework -- like the stuff they teach to new grad students who are
going to be teaching assistants, or the stuff they teach to people in
education programs -- frequently talks about how important it is to
engage the student, and how involving them and making them think about
the material is the teacher's primary task, with presenting the
material actually being secondary.
The actual practice of an "imperfect presentation", though, is
something I'd not considered before -- the idea of leaving blanks for
the student to fill in is both appealing and a little alarming.
> Anyone know where it came from? References to a study or something?
If you look for it, it will be there, but I can't provide you with
specific materials. Try checking into research in educational
techniques; that's where you're most likely to find something like
that. Failing that, developmental psych is likely where it came from,
but it's more likely to be a needle in a haystack, there.
> Someone I know worked for months (on and off) on a presentation that
> could have been done (imperfectly) in a week. When it was presented,
> the reception seemed to me rather luke-warm, in spite of apparently
> strong interest in the audience ahead of it (and after). The
> presentation struck me at the time as being _very_ "polished", but
> perhaps with too little unsaid for someone to question, or think
> about. I suspect this is the reason why it didn't seem to work.
Interesting anecdotal evidence. I can think of several cases where
I've felt somewhat the same way about presentations that I've given.
It's often taught me and my audience both more if my presentation is
struggling to hold together at the seams.
--
Geoff Gerrietts "I am always doing that which I can not do,
<geoff at gerrietts net> in order that I may learn how to do it."
http://www.gerrietts.net --Pablo Picasso
Roman Suzi
>
>> I should also confess that I have an ulterior motive in this
>> discussion, which is to teach my kid to program, (which is still a
>> few years away).
>
>Hee! Me too. I think the best advice I've gotten so far is to do it
>and enjoy it and make it accessible.
This is right point. I came to it after several years
of teaching people...
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Friday, March 08, 2002 _/ Powered by Linux RedHat 6.2 _/
_/ "People are always available for work in the past tense." _/
Roman Suzi
>:So, a bad book (with errors, inconsistencies, etc) is not necessary bad
>:for learning purposes (if it covers enough of a subject).
>
>I think that's a stretch. Bad books have stopped me almost dead on a
>subject, unless I had a personal reason why I needed to push through.
>I'm closer to conceding the point on lectures... a classroom situation
>is by its' nature more interactive, a bad book can stop any
>interaction.
Well, I agree. If the book jumps from 'too easy' to 'too hard'
too often, the resulting miscommunication will force one to
drop the book and find another one.
However, the original book may be revisited later and serve its reader
well. On the contrary, the "good" book will be soon forgotten.
It's like with OS debate. Linux is hard to learn but is it really hard to
use by someone who learned it well?
However, it is said right about interaction. It also contains
"action" in it.
Roman Suzi
>My original intent for starting the thread was because I truly believe
>in CP4E.
In USSR in mid-1980s schools had similar (mis?)conception. It was said:
'Programming is second literacy!". And Computer Science was added to all
curricula at secondary schools. And teachers were to learn it. (In fact,
it was easier, because specialists came to schools from industry).
Now we have very different situation in Russia. CS ("Informatics")
teaches children theoretical concepts + using computers (and Internet, if
possible). Programming is being taught only at some elite schools where
teachers themselves are able to program or pretend the are. Children are
distracted by colorful windows and interactive games from deeper joys of
creative programming work... Even 10-11 form schoolchildren clearly prefer
IDEs over "blockbox" of command prompt (unless they feel more dignity in
the later). No wonder!
CP is not 4E in Russia. Some high officials even dare to argue "Ohm's law"
is not needed in schools' curricula...
And those points of view are extreme.
CP is almost purely creative. That is why it has no logic (let alone
intuitive). And as everywhere creator need to know only building blocks
(bricks), almost everything else is up to his mind. Choice is
a foundation of creativity, IMHO.
So, CP4E goal will be fulfilled when building blocks will
be as clear, as bricks, and still as powerful as Python ;-)
It will not surprise me if hundred years from now auctions will sell
Emacs source at $1000000 and Van Rossum's works will be in the same
price as Van Gogh.
>In my freshman year, we were a total of 38 students in the EE
>major. When I graduated four years later, there were 12 of us, no women.
> I don't believe that programming concepts are more difficult/harder to
>understand and grasp than any engineering curriculum or for that matter
>physics/mathematics.
Hmmm... True mathematics/physics are harder than programming, of course.
>Somebody in this thread raised the point that the logic involved in
>programming in not intuitive. I agree with that. The point I want to
>make is that there are programs like Hooked-on-Phonics, and other
>remedial language programs that are quite effective in raising the
>literacy levels among adults.
Sincerely yours, Roman Suzi
Roman Suzi
>Quoting Peter Hansen (pe...@engcorp.com):
>> Roman Suzi wrote:
>> >
>> > I do not remember who told me this, but it seems that students
>> > better learn from poorly constructed lectures than perfect ones.
>> > Because, they need to be _active_ in constructing their own system
>> > rather than _passively_ "eat" readymaid knowledge frames.
>>
>> Wow. Deep... I like this (to me) completely new idea.
>
>This idea was new to me, too, in form but not in concept. Pedagogical
>coursework -- like the stuff they teach to new grad students who are
>going to be teaching assistants, or the stuff they teach to people in
>education programs -- frequently talks about how important it is to
>engage the student, and how involving them and making them think about
>the material is the teacher's primary task, with presenting the
>material actually being secondary.
I could continue on this and say that teachers who got only highest mark
at pedagogical college are often... bad teachers. And ones who had hard
time learning are (not as a rule, but noticebly) better.
Because they are nearer to the schoolchildren they teach.
We call it "3-mark effect" (I do not know how to translate it right) : in
Russia we have marks 2, 3, 4, 5, five being highest mark.
OK, world-class professors are better teachers than former 3-mark
student, but these are rare in usual schools.
That is why I am poor teacher: I know the subject, but am a pathological
5-marker ;-) And I left teaching some time ago.
>The actual practice of an "imperfect presentation", though, is
>something I'd not considered before -- the idea of leaving blanks for
>the student to fill in is both appealing and a little alarming.
I remember how I was shocked with printed lectures of some western
university: they were _perfect_. They were easy to grasp but I had a
feeling that they beautify the picture (dumb it down). In our universities
we usually write lectures (conspects) manually. So, their presentation is
less than perfect.
>> Anyone know where it came from? References to a study or something?
>
>> strong interest in the audience ahead of it (and after). The
>> presentation struck me at the time as being _very_ "polished", but
>> perhaps with too little unsaid for someone to question, or think
>> about. I suspect this is the reason why it didn't seem to work.
>
>Interesting anecdotal evidence. I can think of several cases where
>I've felt somewhat the same way about presentations that I've given.
>It's often taught me and my audience both more if my presentation is
>struggling to hold together at the seams.
Some lecturers even allow errors to check attention of the
audience. And it works too.
In the estimation theory there are models where it is impossible to make
estimation of some values if inputs aren't noisy! The same is true in
genetics where mutations and selection make species stronger.
This means trial-and-error way is not unfounded.
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Saturday, March 09, 2002 _/ Powered by Linux RedHat 6.2 _/
_/ "And now for something ruder..." _/
James T. Dennis
>> I wonder how much interest there would be in a revival?
>> Dinu
> YES!
> I've found Python to be an excellent learning environment for personal
> development in software engineering and computer science.
> Especially since the advent of
> href="http://www.mindview.net/Books/TIPython"
> Bruce Eckel's _Thinking in Python_
> and
> http://vig.pearsoned.com/store/product/0,,store-562_banner-0_isbn-0130409561,00.html"
> Thomas Christopher's _Python Programming Patterns_
> Best Regards,
> Dean
Christopher's book has almost nothing to do with "Patterns." While the
"patterns" community is somewhat vague about the definition of "design patterns"
Christopher employs a definition that's so nebulous as to be completely
meaningless? It's sort of like saying "Chair: anything that could be sat upon,
and the act of sitting, standing, or being, or anyone that sits, stands or
is" (as in the chair of the meeting sat on the lawn, which was her chair).
It's sort of like that, except that Mr. Christopher isn't nearly so clear
or definitive on the topic of patterns.
In a twenty chapter book he devotes one specifically to patterns. He lists
twenty patterns that roughly correspond to most of the GoF patterns; but he
doesn't ennumerate them so the reader who is familiar with the seminal GoF
volume is left to wonder which three GoF design patterns were silently omitted,
or to wonder if some were merged in some way. Mr. Christopher doesn't describe
alternatives or controversies in the patterns (such as Martelli's "Borg" vs. the
GoF "Singleton")
However, the worst failing of this book is that it doesn't include cogent code
examples. It seems to be floor clippings from scripts or small programs that
he's used in his projects. The points under discussion in the running text are
not isolated or highlighted in the code listings and the examples have little
pedegogical value.
One of his examples implements a priority queue by treating a list as a "heap"
(his term); his example takes over 50 lines of code and he doesn't clearly show
sample usage of this class. After awhile I abandonned my pondering of his code
and wrote my own from scratch (as a dictionary of queues with a list of the
keys to sort into priority order). I won't argue that mine code was better
than his (since I didn't understand his code and I didn't have a clear API to
emulate). However my code only took about 25 lines to implement, allowed me
to have arbitrary priority designations (integers, reals, letters, anything
sequence that was comparable and "sortable") and should have been pretty
fast and lightweight (though I didn't rigorously profile it). The API I
offered for mine was a superset of what I saw in his, adding items to a queue
automatically created new queues as necessary (or could optionally raise an
exception if one set an instance flag); empty queues are automatically removed
from the dictionary and keylists; call ".next()" (with no specific priority)
gets the first item in the "highest priority" queue); "highest priority" could
be set at instantiation --- increasing or reverse sort/lexical order; etc.
(The point is that his code example was confusing and long; and it would seem
to be unnecessarily so if a mere student such as myself can produce something
shorter, simpler and with roughly similar functionality. If his example
offered some functional advantage that I could not discern, it suggests that
it was not a good example or that it lacked supporting exposition in the
accompanying text).
In short I disliked this book. None of the code examples even approached the
claim of "enterprise ready" that was proudly touted on the cover. These were
examples of "programming in the small" rather than "in the large."
(It did have one saving grace: the chapter or so on threading was clear and
concise. I can't assure you that it was either comprehensive or entirely
correct --- but it was a very good introduction to concurrency problems and to
Python's elegant and simple threading support).
Brett g Porter
"James T. Dennis" <jade...@idiom.com> wrote in message
news:a6rk1v$oac$1...@news.idiom.com...
> Dean Goodmanson <pond...@lycos.com> wrote:
>
> One of his examples implements a priority queue by treating a list as a
"heap"
> (his term); his example takes over 50 lines of code and he doesn't
clearly show
> sample usage of this class. After awhile I abandonned my pondering of
his code
> and wrote my own from scratch (as a dictionary of queues with a list of
the
> keys to sort into priority order).
Actually, 'heap' is the correct word (assuming that he's using it in the
correct way -- don't have the book in question) and most algorithms texts
will implement priority queues in terms of heaps. When inserting single
elements into a priority queue, it's (IIRC) the most efficient
representation, requiring O(log n) comparisons and exchanges.