best book: aint no such thing, and encouragement for old coots

[John Benson]

Hi, I see a lot of posts asking about "the best Python book." In my
experience, there is no such thing, but there are a lot of good books that
will help you along in different ways, and at different times.

First of all, I'd like to clarify my position on learning: I subscribe to
the adobe hacienda school of autodidactic technology, to wit:

"If you throw enough adobe at the side of the hacienda, some of it will
stick"

At one time or another, I've dipped into the various O'Reilly Python books,
Grayson's Python and Tkinter Programming, and Christopher's Python
Programming Patterns. They're all good, but I need to see the same difficult
or complex thing presented various times in various contexts to really get
comfortable with it. Hence the multiple viewpoints of multiple books, and I
will also read an individual book more than once, interspersed with other
volumes. Enough adobe ends up adhering to my mental hacienda so that I can
accomplish things in Python.

And now, some encouragement for old techies who have considered going into
management with writing cool software is enough:

My formal education in data processing stopped with Advanced Data Structures
back in the eighties, and I coasted along doing journeyman programming in
various COBOLs, Cs and proprietary languages. Of course, I stayed reasonably
current with stuff like Dijkstra's Structured Programming, DeMarco's
Structured Analysis, Date's Relational Database and other flavors of
business software technology which were my stock in trade, but otherwise I
avoided the paradigm of the week. Then I ran into Python about two years ago
and all of a sudden there was OOP, functional programming, aspect-oriented
programming and other stuff that I had maybe heard about but hadn't actually
worked with, all staring back at me from the pages of Python books and the
mailing list. It's been pretty much a process of creative destruction:
starting all over, but from a higher and clearer conceptual vantage point.
And, of course, I didn't really forget all the other stuff, I just pushed it
into the background long enough to get a new appreciation of it from this
new point of view. In summary, I'd like to recommend getting into Python as
a rather easy and fun way to talk the talk and walk the walk nowadays; it's
been a very rewarding and refreshing software engineering update.

 

[Eddie Corns]

Hi, I see a lot of posts asking about "the best Python book." In my
experience, there is no such thing, but there are a lot of good books that
will help you along in different ways, and at different times.

First of all, I'd like to clarify my position on learning: I subscribe to
the adobe hacienda school of autodidactic technology, to wit:

"If you throw enough adobe at the side of the hacienda, some of it will
stick"

At one time or another, I've dipped into the various O'Reilly Python books,
Grayson's Python and Tkinter Programming, and Christopher's Python
Programming Patterns. They're all good, but I need to see the same difficult
or complex thing presented various times in various contexts to really get
comfortable with it. Hence the multiple viewpoints of multiple books, and I
will also read an individual book more than once, interspersed with other
volumes. Enough adobe ends up adhering to my mental hacienda so that I can
accomplish things in Python.

And now, some encouragement for old techies who have considered going into
management with writing cool software is enough:

My formal education in data processing stopped with Advanced Data Structures
back in the eighties, and I coasted along doing journeyman programming in
various COBOLs, Cs and proprietary languages. Of course, I stayed reasonably
current with stuff like Dijkstra's Structured Programming, DeMarco's
Structured Analysis, Date's Relational Database and other flavors of
business software technology which were my stock in trade, but otherwise I
avoided the paradigm of the week. Then I ran into Python about two years ago
and all of a sudden there was OOP, functional programming, aspect-oriented
programming and other stuff that I had maybe heard about but hadn't actually
worked with, all staring back at me from the pages of Python books and the
mailing list. It's been pretty much a process of creative destruction:
starting all over, but from a higher and clearer conceptual vantage point.
And, of course, I didn't really forget all the other stuff, I just pushed it
into the background long enough to get a new appreciation of it from this
new point of view. In summary, I'd like to recommend getting into Python as
a rather easy and fun way to talk the talk and walk the walk nowadays; it's
been a very rewarding and refreshing software engineering update.

The next step is to read "Structure and Interpretation of Computer Programs"
aka SICP and start all over again, in terms of "clearer conceptual vantage
point" it just can't be beat. It's even availabe online somewhere.

Eddie

 

[Samuel Walters]

| Eddie Corns said |

The next step is to read "Structure and Interpretation of Computer Programs"
aka SICP and start all over again, in terms of "clearer conceptual vantage
point" it just can't be beat. It's even availabe online somewhere.

Here:
http://mitpress.mit.edu/sicp/full-text/book/book.html

It's the major reason I'm learning scheme.
I just don't stop hearing good things about this book.

Sam Walters.

 

[Alan Gauld]

http://mitpress.mit.edu/sicp/full-text/book/book.html

It's the major reason I'm learning scheme.
I just don't stop hearing good things about this book.

Yep, and a good companion volume, also online is

How To Design Programs

http://www.htdp.org/2001-11-21/Book/

Which is a more hands on, day to day type scheme tutor but
emphasises all the same principles. It's less math oriented
that SICP which might appeal to some.

But SICP is definitely the more "life changing" in impact.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Michael Hudson]

| Eddie Corns said |

Here:
http://mitpress.mit.edu/sicp/full-text/book/book.html

It's the major reason I'm learning scheme.
I just don't stop hearing good things about this book.

Well, when you think you want a loop and before you know it you've
written:

(define (my-func arg1 arg2)
(define (inner var)
...

it's probably time to come back to a less spartan programming
language. I mean, it's good to know that you *can* write loops that
way, but that doesn't mean it actually *is* a good idea.

Cheers,
mwh

 

[Mark Carter]

Well, when you think you want a loop and before you know it you've

written:

(define (my-func arg1 arg2)
(define (inner var)
...

it's probably time to come back to a less spartan programming
language. I mean, it's good to know that you *can* write loops that
way, but that doesn't mean it actually *is* a good idea.

I'm experimenting with learning a functional language; and I know
almost zero about Scheme. I find it very difficult to understand the
structure of what's going on. I downloaded Standard ML (the New Jersey
offering), and find myself more inclined to dig into ML deeper; rather
than Scheme. ML does, at first glance, seem more readable.

I suppose that Schemers and Lispers take the attitude that a lack of
syntax is an advantage, because you can ultimately program in any
paradigm you wish. It's "just" a case of writing code that implements
the paradigm. I have also heard claims that the existence of
parantheses in s-exprs is a red herring as far as readability is
concerned.

Non Schemers/Lispers, on the other hand, presumably think that a
spoonful of syntactic sugar helps the medicine go down.

I suspect that if there really was One Obviously Right Way To Do It,
then we'd all be using it. No silver bullet, and all that.

I am sure, though, that there will be many people who disagree with my
sentiments.

 

[Eddie Corns]

I'm experimenting with learning a functional language; and I know
almost zero about Scheme. I find it very difficult to understand the
structure of what's going on. I downloaded Standard ML (the New Jersey
offering), and find myself more inclined to dig into ML deeper; rather
than Scheme. ML does, at first glance, seem more readable.

It's probably a lot more important to stretch yourself out in that direction
than to worry about which flavour.

I suppose that Schemers and Lispers take the attitude that a lack of
syntax is an advantage, because you can ultimately program in any
paradigm you wish. It's "just" a case of writing code that implements
the paradigm. I have also heard claims that the existence of
parantheses in s-exprs is a red herring as far as readability is
concerned.

The supposed unreadability is a complete nonsense, you quickly don't notice
the parentheses and rely mostly on the indentation. I think I'll start
looking for another project I can do in Scheme, it's been ages.

Non Schemers/Lispers, on the other hand, presumably think that a
spoonful of syntactic sugar helps the medicine go down.

I suspect that if there really was One Obviously Right Way To Do It,
then we'd all be using it. No silver bullet, and all that.

I am sure, though, that there will be many people who disagree with my
sentiments.

Who cares eh? The important thing is to get the message through to the few
who can think for themselves and give them a chance to rise above the
mediocrity.

Somehow I'm reminded of a sequence in a novel I was reading at the weekend:

Q:"Do you exercise?"
A:"Only restraint!"

 

[Michele Simionato]

I suppose that Schemers and Lispers take the attitude that a lack of
syntax is an advantage, because you can ultimately program in any
paradigm you wish. It's "just" a case of writing code that implements
the paradigm.

Uh? The lack of syntax has nothing to do with the lack of paradigm,
I miss you point, sorry.

I have also heard claims that the existence of
parantheses in s-exprs is a red herring as far as readability is
concerned.

That's true, the parentheses are a not a problem for readability, they
are a problem for *writability*: in practice, they force you to use emacs
or The Other Editor. Somebody can argue that this is a Good Thing,
anyway So, it is somewhat true that Lisp/Scheme are difficult to
read, but this is due to the choice of names and to the unusual order
of evaluation more than to the parentheses. Just my 2 eurocents,

Michele Simionato

 

[Mark Carter]

I suppose that Schemers and Lispers take the attitude that a lack of

Uh? The lack of syntax has nothing to do with the lack of paradigm,
I miss you point, sorry.

What I meant was: programs written in s-exprs makes it possible to
accomodate new paradigms because, ultimately, everything is a list,
which you can parse to accomodate your new paradigm. Programs not
written in s-exprs require extra syntax to be bolted onto the
language.

But I suppose, if you want, to argue that all Turing Complete
languages are equivalent, so they support all the paradigms that the
others support.

 

[Eddie Corns]

What I meant was: programs written in s-exprs makes it possible to
accomodate new paradigms because, ultimately, everything is a list,
which you can parse to accomodate your new paradigm. Programs not
written in s-exprs require extra syntax to be bolted onto the
language.

The way I view it is that you can express _everything_ you want a computer to
do as:

COMMAND arg1 arg2 ...

When you have code as data thrown in to the mix you can extend this concept to
what you want done with code, so as well as saying:

ADD x y z
PUT this there
etc.

you have the ability to control the way code is executed

DO this-body-of-code
DO this-body-of-code for all these things

And essentially new paradigms ARE about how we organise code, so we can indeed
adapt to any paradigm AND we still have minimum syntax to deal with. One of
the things I like about scheme in this instance is that the rules of your
paradigm are explicit in the code/macros that you create to parse the basic
constructs of your paradigm (objects, messages, whatever).

But I suppose, if you want, to argue that all Turing Complete
languages are equivalent, so they support all the paradigms that the
others support.

Then you run into Greenspun's tenth rule amongst others. Also, of course, you
have to consider expressiveness which is much harder to pin down.

Eddie

 

[Dennis Lee Bieber]

ADD x y z
PUT this there
etc.

you have the ability to control the way code is executed

DO this-body-of-code
DO this-body-of-code for all these things

Or maybe COBOL

--