Feedback wanted on programming introduction (Python in Windows)

Discussion in 'Python' started by Alf P. Steinbach, Oct 28, 2009.

  1. [Cross-posted comp.programming and comp.lang.python]

    Hi.

    I may finally have found the perfect language for a practically oriented
    introductory book on programming, namely Python.

    C++ was way too complex for the novice, JScript and C# suffered from too
    fast-changing specifications and runtime environment, Java, well, nothing
    particularly wrong but it's sort of too large and unwieldy and inefficient.

    I don't know whether this will ever become an actual book. I hope so!

    But since I don't know much Python -- I'm *learning* Python as I write -- I know
    that there's a significant chance of communicating misconceptions, non-idiomatic
    ways to do things, bad conventions, etc., in addition to of course plain errors
    of fact and understanding in general, to which I'm not yet immune...

    So I would would be very happy for feedback.

    But note: although I'm a complete Python newbie I'm not a novice programmer; my
    usual programming language is C++. So if you are a novice and think there's
    something wrong, then please do report it because it may help me explain things
    better, but since it's likely my explanation that is misleading, don't waste
    time on building up a case! This also goes for something that is simply
    difficult to understand. Then reporting that may help me explain it better. On
    the other hand, if you do have some experience, then chances are that what you
    think is an error, actually *is* an error! :)

    Unfortunately Google docs doesn't display the nice table of contents in each
    document, but here's the public view of ch 1 (complete) and ch 2 (about one
    third completed, I've not yet settled on a title so it's just chapter "asd"):

    http://preview.tinyurl.com/progintro

    Cheers,

    - Alf

    PS: Please use the groups, this thread, for feedback; not e-mail. -DS
    Alf P. Steinbach, Oct 28, 2009
    #1
    1. Advertising

  2. Alf P. Steinbach

    Chris Rebert Guest

    On Tue, Oct 27, 2009 at 11:52 PM, Alf P. Steinbach <> wrote:
    > [Cross-posted comp.programming and comp.lang.python]
    >
    > Hi.
    >
    > I may finally have found the perfect language for a practically oriented
    > introductory book on programming, namely Python.
    >
    > C++ was way too complex for the novice, JScript and C# suffered from too
    > fast-changing specifications and runtime environment, Java, well, nothing
    > particularly wrong but it's sort of too large and unwieldy and inefficient.
    >
    > I don't know whether this will ever become an actual book. I hope so!
    >
    > But since I don't know much Python -- I'm *learning* Python as I write -- I
    > know that there's a significant chance of communicating misconceptions,
    > non-idiomatic ways to do things, bad conventions, etc., in addition to of
    > course plain errors of fact and understanding in general, to which I'm not
    > yet immune...
    >
    > So I would would be very happy for feedback.

    <snip>
    >
    >    http://preview.tinyurl.com/progintro
    >
    > Cheers,
    >
    > - Alf
    >
    > PS: Please use the groups, this thread, for feedback; not e-mail. -DS


    - The slogan is "batteries included", not "all batteries included".
    - As a user of the platform, I can tell you it's "Mac OS X" (with a
    space, not a slash).
    - ActivePython is a distribution, not an implementation. It's just the
    standard CPython from python.org with some bundled extras.
    - I might consider making the first example multiline. Most cringe at
    the use of semicolons in a Python program, although I can understand
    it might be easier for the newbie to type correctly.
    - You might mention how unit testing is used in interpreted languages
    to detect many sorts of errors detected by the compiler in compiled
    languages

    Cheers,
    Chris
    --
    http://blog.rebertia.com
    Chris Rebert, Oct 28, 2009
    #2
    1. Advertising

  3. On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote:

    > Unfortunately Google docs doesn't display the nice table of contents in
    > each document, but here's the public view of ch 1 (complete) and ch 2
    > (about one third completed, I've not yet settled on a title so it's just
    > chapter "asd"):
    >
    > http://preview.tinyurl.com/progintro


    Unfortunately Google wants me to change my browser, accept a privacy
    breach (cookies), and open a moderately large security hole in my browser
    (Javascript). Any one of these on its own, and I wouldn't mind; two of
    them, and I'd give it some thought; but all three, well, no thank you.


    I don't suppose you have these chapters available on a public website in
    an open document format like .odt or similar? Or even better, plain text
    with markup?



    --
    Steven
    Steven D'Aprano, Oct 28, 2009
    #3
  4. * Chris Rebert:
    > On Tue, Oct 27, 2009 at 11:52 PM, Alf P. Steinbach <> wrote:
    >> [Cross-posted comp.programming and comp.lang.python]
    >>
    >> Hi.
    >>
    >> I may finally have found the perfect language for a practically oriented
    >> introductory book on programming, namely Python.
    >>
    >> C++ was way too complex for the novice, JScript and C# suffered from too
    >> fast-changing specifications and runtime environment, Java, well, nothing
    >> particularly wrong but it's sort of too large and unwieldy and inefficient.
    >>
    >> I don't know whether this will ever become an actual book. I hope so!
    >>
    >> But since I don't know much Python -- I'm *learning* Python as I write -- I
    >> know that there's a significant chance of communicating misconceptions,
    >> non-idiomatic ways to do things, bad conventions, etc., in addition to of
    >> course plain errors of fact and understanding in general, to which I'm not
    >> yet immune...
    >>
    >> So I would would be very happy for feedback.

    > <snip>
    >> http://preview.tinyurl.com/progintro
    >>
    >> Cheers,
    >>
    >> - Alf
    >>
    >> PS: Please use the groups, this thread, for feedback; not e-mail. -DS

    >
    > - The slogan is "batteries included", not "all batteries included".
    > - As a user of the platform, I can tell you it's "Mac OS X" (with a
    > space, not a slash).


    Thanks!

    I'll fix that right away. :)


    > - ActivePython is a distribution, not an implementation. It's just the
    > standard CPython from python.org with some bundled extras.


    Thanks, but it's also a language implementation, the way I use that word :).
    This is the same as the MinGW g++ C++ compiler is a language implementation, in
    spite of being just a packaging of the CygWin compiler. Its origin doesn't
    matter. But perhaps there is some better term than implementation, something not
    involving discussing distributions and derivative works and so on? I.e. a term
    that can be introduced in one line of text and is even more clear?


    > - I might consider making the first example multiline. Most cringe at
    > the use of semicolons in a Python program, although I can understand
    > it might be easier for the newbie to type correctly.


    Hm. I didn't know that about "most cringe at" semicolons in Python. But I still
    think the example is better on one line: short, concise, not introducing extra
    tool usage (which is what the reader absolutely *has* to relate to).


    > - You might mention how unit testing is used in interpreted languages
    > to detect many sorts of errors detected by the compiler in compiled
    > languages


    Yes, later. Unit-testing is done also for statically type checked languages. The
    big difference lies in how much testing and at what time; this involves in
    particular test-driven development (TDD). And it's touchy. Proponents of this
    and that methodology will invariably argue that their methodology is best... :)



    Cheers, & thanks,

    - Alf

    PS: I added back in [comp.programming], since I think it's simplest to have all
    the discussion, both Python-specific and general, in one single thread.
    Alf P. Steinbach, Oct 28, 2009
    #4
  5. Alf P. Steinbach

    Jon Clements Guest

    On 28 Oct, 07:31, Steven D'Aprano
    <> wrote:
    > On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote:
    > > Unfortunately Google docs doesn't display the nice table of contents in
    > > each document, but here's the public view of ch 1 (complete) and ch 2
    > > (about one third completed, I've not yet settled on a title so it's just
    > > chapter "asd"):

    >
    > >      http://preview.tinyurl.com/progintro

    >
    > Unfortunately Google wants me to change my browser, accept a privacy
    > breach (cookies), and open a moderately large security hole in my browser
    > (Javascript). Any one of these on its own, and I wouldn't mind; two of
    > them, and I'd give it some thought; but all three, well, no thank you.
    >
    > I don't suppose you have these chapters available on a public website in
    > an open document format like .odt or similar? Or even better, plain text
    > with markup?
    >
    > --
    > Steven


    Umm, seem to have woken up in a good mood this morning (for a change);
    just in case the OP can't...

    http://datasyzygy.com/alf/01 - getting started.pdf
    http://datasyzygy.com/alf/02 - asd.pdf

    Jon.
    Jon Clements, Oct 28, 2009
    #5
  6. Alf P. Steinbach

    Jon Clements Guest

    On 28 Oct, 07:44, Jon Clements <> wrote:
    > On 28 Oct, 07:31, Steven D'Aprano
    >
    >
    >
    > <> wrote:
    > > On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote:
    > > > Unfortunately Google docs doesn't display the nice table of contents in
    > > > each document, but here's the public view of ch 1 (complete) and ch 2
    > > > (about one third completed, I've not yet settled on a title so it's just
    > > > chapter "asd"):

    >
    > > >      http://preview.tinyurl.com/progintro

    >
    > > Unfortunately Google wants me to change my browser, accept a privacy
    > > breach (cookies), and open a moderately large security hole in my browser
    > > (Javascript). Any one of these on its own, and I wouldn't mind; two of
    > > them, and I'd give it some thought; but all three, well, no thank you.

    >
    > > I don't suppose you have these chapters available on a public website in
    > > an open document format like .odt or similar? Or even better, plain text
    > > with markup?

    >
    > > --
    > > Steven

    >
    > Umm, seem to have woken up in a good mood this morning (for a change);
    > just in case the OP can't...
    >
    > http://datasyzygy.com/alf/01- getting started.pdfhttp://datasyzygy.com/alf/02- asd.pdf
    >
    > Jon.


    Maybe not quite 'woken up'...

    http://datasyzygy.com/alf/01 - getting started.pdf
    http://datasyzygy.com/alf/02 - asd.pdf
    Jon Clements, Oct 28, 2009
    #6
  7. Alf P. Steinbach

    tm Guest

    On 28 Okt., 07:52, "Alf P. Steinbach" <> wrote:
    > [Cross-posted comp.programming and comp.lang.python]


    Looking at your topic '(Python in Windows)', without taking a
    glimpse at your actual introduction, I have the following to say:
    I think it is not a good idea to teach programming with a focus
    on a specific operating system. Programming should IMHO be taught
    without reference to an operating system. Otherwise you just teach
    how to write unportable programs.

    > Hi.
    >
    > I may finally have found the perfect language for a practically oriented
    > introductory book on programming, namely Python.


    What is considered 'perfect' depends on the point of view. Languages
    have assets and drawbacks and I don't even use the term 'perfect'
    for my own language. :) There is always room to improve. Some of
    the features I consider important are discussed here:

    http://seed7.sourceforge.net/faq.htm

    > C++ was way too complex for the novice, JScript and C# suffered from too
    > fast-changing specifications and runtime environment, Java, well, nothing
    > particularly wrong but it's sort of too large and unwieldy and inefficient.


    While many people consider Java inefficient they do so in comparison
    to C/C++. I doubt that Java is inefficient compared to most
    interpreted languages.

    > I don't know whether this will ever become an actual book. I hope so!
    >
    > But since I don't know much Python -- I'm *learning* Python as I write


    Normally I prefer books written by people who already know the
    stuff they are writing about. I would consider that it is not a good
    selling argument when a book was written to *learn* a language. :)

    Greetings Thomas Mertes

    Seed7 Homepage: http://seed7.sourceforge.net
    Seed7 - The extensible programming language: User defined statements
    and operators, abstract data types, templates without special
    syntax, OO with interfaces and multiple dispatch, statically typed,
    interpreted or compiled, portable, runs under linux/unix/windows.
    tm, Oct 28, 2009
    #7
  8. * tm:
    > On 28 Okt., 07:52, "Alf P. Steinbach" <> wrote:
    >> [Cross-posted comp.programming and comp.lang.python]

    >
    > Looking at your topic '(Python in Windows)', without taking a
    > glimpse at your actual introduction, I have the following to say:
    > I think it is not a good idea to teach programming with a focus
    > on a specific operating system. Programming should IMHO be taught
    > without reference to an operating system. Otherwise you just teach
    > how to write unportable programs.


    I think you're trolling a little. :)

    Without reference to an OS you can't address any of the issues that a beginner
    has to grapple with, including most importantly tool usage, without which it's
    not even possible to get started, but also, very importantly, a file system.

    Learning programming without tools and without using files (or only using the
    common denominator for file systems in OSes X, Y and Z) is sort of vacuous...

    In addition there's the motivational factor.

    Doing only academic examples, utilizing only a language's more or less portable
    functionality, is very de-motivational, while the opposite is motivational.



    >> Hi.
    >>
    >> I may finally have found the perfect language for a practically oriented
    >> introductory book on programming, namely Python.

    >
    > What is considered 'perfect' depends on the point of view. Languages
    > have assets and drawbacks and I don't even use the term 'perfect'
    > for my own language. :) There is always room to improve. Some of
    > the features I consider important are discussed here:
    >
    > http://seed7.sourceforge.net/faq.htm
    >
    >> C++ was way too complex for the novice, JScript and C# suffered from too
    >> fast-changing specifications and runtime environment, Java, well, nothing
    >> particularly wrong but it's sort of too large and unwieldy and inefficient.

    >
    > While many people consider Java inefficient they do so in comparison
    > to C/C++. I doubt that Java is inefficient compared to most
    > interpreted languages.
    >
    >> I don't know whether this will ever become an actual book. I hope so!
    >>
    >> But since I don't know much Python -- I'm *learning* Python as I write

    >
    > Normally I prefer books written by people who already know the
    > stuff they are writing about. I would consider that it is not a good
    > selling argument when a book was written to *learn* a language. :)


    Yes, it would be silly to write a book or whatever about Python. This text is
    primarily about programming, at the novice level, not about the Python language.
    The programming language is only a vehicle.

    However, as a vehicle the language needs to be suited for transport of the
    novice. :)

    And it seems that Python is very well suited for that.


    > Seed7 Homepage: http://seed7.sourceforge.net


    I'm not familiar with Seed, sorry.


    Cheers, & thanks for your thoughts,

    - Alf
    Alf P. Steinbach, Oct 28, 2009
    #8
  9. Alf P. Steinbach

    eb303 Guest

    On Oct 28, 7:52 am, "Alf P. Steinbach" <> wrote:
    [snip]
    > But since I don't know much Python -- I'm *learning* Python as I write -- I know
    > that there's a significant chance of communicating misconceptions, non-idiomatic
    > ways to do things, bad conventions, etc., in addition to of course plain errors
    > of fact and understanding in general, to which I'm not yet immune...
    >
    > So I would would be very happy for feedback.


    OK, I'll start the flame war then: I can see the purpose of section
    1.5, but from the end of the 3rd paragraph, you seem to go into
    religious matters rather than actual facts, which seems to me a bit
    out of place in a book only supposed to teach programming. Basically
    saying that any "serious" program has to be written in a statically
    typed language and that such a language kind of automatically makes
    the development faster and the quality higher is just not true from my
    experience, and from the experience of many people on this group, I
    guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
    highly subjective and should be completely rewritten, if not simply
    removed.

    Sorry if that sounds rough: I've seen this written too many times
    (usually without any argumentation, BTW) and it has a tendency to make
    me a little upset.
    eb303, Oct 28, 2009
    #9
  10. Alf P. Steinbach

    Jon Clements Guest

    On 28 Oct, 08:58, "Alf P. Steinbach" <> wrote:
    [snip]
    > Without reference to an OS you can't address any of the issues that a beginner
    > has to grapple with, including most importantly tool usage, without which it's
    > not even possible to get started, but also, very importantly, a file system.
    >
    > Learning programming without tools and without using files (or only using the
    > common denominator for file systems in OSes X, Y and Z) is sort of vacuous...
    >
    > In addition there's the motivational factor.


    I certainly agree that focusing on Windows, you may be able to suggest
    certain tools. IDE's, RAD environments, etc... However, I'm sure you
    would consider that if you were writing a C++ guide, you would promote
    portability and the STL. Of course, both languages offer platform-
    specific libraries. Maybe a 'down side' with Python is that the
    "batteries included" also include some functions marked in the
    documentation as "Available on Windows only" etc... And specifically
    suggesting an ActiveState install which includes COM interop etc...
    (although I hope this would appear much later, if at all).

    Cheers,

    Jon.

    PS. Can I suggest PSpad as an editor for the Windows environment, I
    much prefer it to Notepad++ and it may well be worth mentioning.
    Jon Clements, Oct 28, 2009
    #10
  11. Alf P. Steinbach wrote:
    > * tm:
    >> On 28 Okt., 07:52, "Alf P. Steinbach" <> wrote:
    >>> [Cross-posted comp.programming and comp.lang.python]

    >>
    >> Looking at your topic '(Python in Windows)', without taking a
    >> glimpse at your actual introduction, I have the following to say:
    >> I think it is not a good idea to teach programming with a focus
    >> on a specific operating system. Programming should IMHO be taught
    >> without reference to an operating system. Otherwise you just teach
    >> how to write unportable programs.

    >
    > I think you're trolling a little. :)
    >
    > Without reference to an OS you can't address any of the issues that a
    > beginner has to grapple with, including most importantly tool usage,
    > without which it's not even possible to get started, but also, very
    > importantly, a file system.
    >
    > Learning programming without tools and without using files (or only
    > using the common denominator for file systems in OSes X, Y and Z) is
    > sort of vacuous...
    >
    > In addition there's the motivational factor.


    I conclude from this that your assumption is that the reader might not
    be competent enough to have basic portable knowledge of using a
    computer. Which is fair enough, however I would suggest writing an
    introduction to solve this fundamental absence of knowledge first before
    introducing concepts like programming in python for which already are a
    number of freely available/modifiable resources online.

    I don't think it is a virtue to help adding to the pool of programmers
    unaware of the command line, whatever platform that might be.

    But ignoring the above (I assumed and assumption you made, so it is
    likely I've got it totally wrong :) ), I think that creating such a
    document provides a unique opportunity to document things that the more
    experienced developers take for granted but is a complete enigma for
    beginners in programming and using computers in general.

    Good luck with your effort!

    --
    MPH
    http://blog.dcuktec.com
    'If consumed, best digested with added seasoning to own preference.'
    Martin P. Hellwig, Oct 28, 2009
    #11
  12. * eb303:
    > On Oct 28, 7:52 am, "Alf P. Steinbach" <> wrote:
    > [snip]
    >> But since I don't know much Python -- I'm *learning* Python as I write -- I know
    >> that there's a significant chance of communicating misconceptions, non-idiomatic
    >> ways to do things, bad conventions, etc., in addition to of course plain errors
    >> of fact and understanding in general, to which I'm not yet immune...
    >>
    >> So I would would be very happy for feedback.

    >
    > OK, I'll start the flame war then: I can see the purpose of section
    > 1.5, but from the end of the 3rd paragraph, you seem to go into
    > religious matters rather than actual facts, which seems to me a bit
    > out of place in a book only supposed to teach programming. Basically
    > saying that any "serious" program has to be written in a statically
    > typed language


    No, I didn't write that.


    > and that such a language kind of automatically makes
    > the development faster and the quality higher


    No, I didn't write that.


    > is just not true from my experience,


    Yes, that's a strawman -- nearly always good in flame wars. ;-)


    > and from the experience of many people on this group, I
    > guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
    > highly subjective and should be completely rewritten, if not simply
    > removed.


    Just to fuel the flame war, consider a million line Python system. It's not
    uncommon with C++. :)


    > Sorry if that sounds rough: I've seen this written too many times
    > (usually without any argumentation, BTW) and it has a tendency to make
    > me a little upset.


    Sorry if the above sounds a little harsh, but, u know, flame wars & all that. He
    he. Thanks anyway!


    Cheers,

    - Alf
    Alf P. Steinbach, Oct 28, 2009
    #12
  13. Alf P. Steinbach

    eb303 Guest

    On Oct 28, 10:48 am, "Alf P. Steinbach" <> wrote:
    > * eb303:
    >
    > > On Oct 28, 7:52 am, "Alf P. Steinbach" <> wrote:
    > > [snip]
    > >> But since I don't know much Python -- I'm *learning* Python as I write -- I know
    > >> that there's a significant chance of communicating misconceptions, non-idiomatic
    > >> ways to do things, bad conventions, etc., in addition to of course plain errors
    > >> of fact and understanding in general, to which I'm not yet immune...

    >
    > >> So I would would be very happy for feedback.

    >
    > > OK, I'll start the flame war then: I can see the purpose of section
    > > 1.5, but from the end of the 3rd paragraph, you seem to go into
    > > religious matters rather than actual facts, which seems to me a bit
    > > out of place in a book only supposed to teach programming. Basically
    > > saying that any "serious" program has to be written in a statically
    > > typed language

    >
    > No, I didn't write that.
    >
    > > and that such a language kind of automatically makes
    > > the development faster and the quality higher

    >
    > No, I didn't write that.


    Well, honestly, this is really what I understood when I've read:
    "the compiler can detect a lot of errors and save you from having to
    painstakingly & laboriously test every little detail. For a large
    program or system that really cuts down on the work (and hence time)
    and really increases quality"
    which what you did write, right?

    So maybe it is an understanding problem on my side, but even if it is,
    other people may have the same as I had, don't you think?

    > > is just not true from my experience,

    >
    > Yes, that's a strawman -- nearly always good in flame wars. ;-)
    >
    > > and from the experience of many people on this group, I
    > > guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
    > > highly subjective and should be completely rewritten, if not simply
    > > removed.

    >
    > Just to fuel the flame war, consider a million line Python system. It's not
    > uncommon with C++. :)


    Well, I won't go into how C++ code tends to be quite longer than their
    Python equivalent (maybe I'm not too good at flame wars after
    all... ;-) ). But the application I'm working on right now includes
    nearly 300000 lines of Python (among other languages). That's not a
    million indeed, but I wouldn't call it a small application. I've done
    a lot of C, Java, and some C++ as well before. And so far, what I'm
    seeing is that if you organize your work properly (TDD mainly...), the
    development goes faster, with no significant decrease in quality for
    the final product. So yes: I would consider a million line Python
    system without fear.
    eb303, Oct 28, 2009
    #13
  14. Alf P. Steinbach

    James Harris Guest

    On 28 Oct, 08:58, "Alf P. Steinbach" <> wrote:
    > * tm:
    >
    > > On 28 Okt., 07:52, "Alf P. Steinbach" <> wrote:
    > >> [Cross-posted comp.programming and comp.lang.python]

    >
    > > Looking at your topic '(Python in Windows)', without taking a
    > > glimpse at your actual introduction, I have the following to say:
    > > I think it is not a good idea to teach programming with a focus
    > > on a specific operating system. Programming should IMHO be taught
    > > without reference to an operating system. Otherwise you just teach
    > > how to write unportable programs.

    >
    > I think you're trolling a little. :)


    Whether tm is promoting his own language or not I agree with some of
    his comments. I was going to avoid giving any feedback because most of
    my thoughts are, I'm afraid, negative but seeing your response to tm
    here I changed my mind. You asked for feedback. Hopefully you are
    looking for genuine criticism and honest opinions rather than flattery
    'cause I'm not going to flatter.

    If you want to teach programming then target programming concepts
    (albeit using Python as a means to express them) and as tm says, avoid
    teaching either a particular OS or a particular set of bundled tools.

    If you want to teach programming under Windows then change the title
    to say so.

    Sorry but I find the overall tone too patronising. Phrases like "send
    your browser galloping in the direction of" are offputting. With this
    and other phrases it sounds like you are either

    1) writing this for young children, or
    2) having more fun writing it than your readers will have reading it
    or,
    3) being self-indulgent and not planning to help others at all.

    I know you don't mean any of these. Hopefully you can change the
    approach to suit. There are many of these jocular phrases and they
    appear in both chapters.

    Given that this is a Windows-based course it's good that you include
    teaching on Notepad rather than just the IDE.

    The x squared graph is a good example to show that some fun can be had
    in a small space.

    I wouldn't condemn but I would query the use of Activestate's
    distribution. A vanilla Python may have been better if you want to
    teach transportable skills. Teaching Activestate reminds me of how
    Compuserve bundled their own stuff with Internet access so people
    thought the Internet was what they saw on Compuserve.

    You get way too deep into Python in places (for a beginner's course in
    programming). For example, "from now on I’ll always use from
    __future__ in any program that uses print."

    The MIT course that you mention takes a more apt approach for teaching
    *programming*. For example, it explains some things like floating
    point numbers in Python not being able to express 0.1 perfectly in
    binary but that's appropriate as other languages have the same issue.

    As you say, you are an experienced programmer who is learning Python
    and the chapters read that way. They rush in to all kinds of gotchas
    and mechanisms. Perhaps you should either change it to be a book on
    learning Python for experienced programmers (this seems the best
    option) or start again and take a different approach.

    With what you have written so far your audience seems to be youself
    (or someone in your position).

    >
    > Without reference to an OS you can't address any of the issues that a beginner
    > has to grapple with, including most importantly tool usage, without which it's
    > not even possible to get started, but also, very importantly, a file system.


    There's a difference between referring to an OS and tieing it in
    throughout the text which is what I think tm was getting at.

    >
    > Learning programming without tools and without using files (or only using the
    > common denominator for file systems in OSes X, Y and Z) is sort of vacuous...


    OSes generally support concepts of files and editors. If you cannot
    teach the general concepts make it clear that you are teaching
    Activestate Python under Windows.

    > In addition there's the motivational factor.
    >
    > Doing only academic examples, utilizing only a language's more or less portable
    > functionality, is very de-motivational, while the opposite is motivational.


    The graphics and examples are fun. Be clear about what you are
    teaching, though, and who your intended audience is.

    ....

    > >> C++ was way too complex for the novice, JScript and C# suffered from too
    > >> fast-changing specifications and runtime environment, Java, well, nothing
    > >> particularly wrong but it's sort of too large and unwieldy and inefficient.


    Agreed. Python is a good introductory language.

    > >> I don't know whether this will ever become an actual book. I hope so!


    It's a good start.

    >
    > >> But since I don't know much Python -- I'm *learning* Python as I write


    This and that you are an experienced programmer show in what you have
    written. If you don't recast the material for a beginner now it will
    only get harder to change the approach later.

    ....

    > Yes, it would be silly to write a book or whatever about Python. This text is
    > primarily about programming, at the novice level, not about the Python language.
    > The programming language is only a vehicle.


    It doesn't seem that way. Whether intended or not the text is about
    Python.

    ....

    I don't think you will get my meaning and will want to stick to what
    you have started so I'll try to illustrate:

    If you really want to teach *programming* start by planning out what
    concepts you need to teach. You might come up with a list such as:

    1. Values, types, variables, expressions.
    2. Immediate and stored operations.
    3. Statements, functions, arguments and parameters.
    4. Control flow.
    5. etc.

    Once you have worked out the concepts you want to teach break them
    down to key points and then think about how to express them in the
    language you have chosen.

    If, on the other hand, you want to teach Python to experienced
    programmers, carry on as you are doing. Judged from that position I
    would rate the text far more positively.

    HTH

    James
    James Harris, Oct 28, 2009
    #14
  15. >
    > Just to fuel the flame war, consider a million line Python system. It's not
    > uncommon with C++. :)
    >


    In python, with one-miliion lines of code, you can demonstrate
    the existence of God, and then demostrate its non-existance by
    changing a single line of code :)


    Ciao
    -----
    FB
    Francesco Bochicchio, Oct 28, 2009
    #15
  16. * eb303:
    > On Oct 28, 10:48 am, "Alf P. Steinbach" <> wrote:
    >> * eb303:
    >>
    >>> On Oct 28, 7:52 am, "Alf P. Steinbach" <> wrote:
    >>> [snip]
    >>>> But since I don't know much Python -- I'm *learning* Python as I write -- I know
    >>>> that there's a significant chance of communicating misconceptions, non-idiomatic
    >>>> ways to do things, bad conventions, etc., in addition to of course plain errors
    >>>> of fact and understanding in general, to which I'm not yet immune...
    >>>> So I would would be very happy for feedback.
    >>> OK, I'll start the flame war then: I can see the purpose of section
    >>> 1.5, but from the end of the 3rd paragraph, you seem to go into
    >>> religious matters rather than actual facts, which seems to me a bit
    >>> out of place in a book only supposed to teach programming. Basically
    >>> saying that any "serious" program has to be written in a statically
    >>> typed language

    >> No, I didn't write that.
    >>
    >>> and that such a language kind of automatically makes
    >>> the development faster and the quality higher

    >> No, I didn't write that.

    >
    > Well, honestly, this is really what I understood when I've read:
    > "the compiler can detect a lot of errors and save you from having to
    > painstakingly & laboriously test every little detail. For a large
    > program or system that really cuts down on the work (and hence time)
    > and really increases quality"
    > which what you did write, right?


    Yes that's what I wrote. What I intended to communicate was literally what I
    wrote (which is true), but that's very far from what you understood, e.g. it
    seems that you read my word "can" as, quoting you, "will automatically",
    apparently with an implied "always".


    > So maybe it is an understanding problem on my side, but even if it is,
    > other people may have the same as I had, don't you think?


    Some will have the same misreading, and some will probably have other misreadings.

    I could reformulate it to cater for people who'd tend to read it your way and
    other ways, but one the problem with that is that there are so many possible
    ways to read a text when one s/can/will automatically/g, insert frivoluous
    claims about a "serious" (what's that?) category of programs, etc., and, being a
    fallible human being, I would be bound to miss some of them. ;-).

    Another problem is that delving into such details about possible things that
    I've *not* intended to write, listing all possible such things I could imagine,
    like, "note: I'm not claiming XYZ, even though that claim, made by some, is
    vaguely associated with some of what I'm discussing", would make the first get
    started chapter not 9 pages or whatever this one is, but 150 pages and going.


    >>> is just not true from my experience,

    >> Yes, that's a strawman -- nearly always good in flame wars. ;-)
    >>
    >>> and from the experience of many people on this group, I
    >>> guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
    >>> highly subjective and should be completely rewritten, if not simply
    >>> removed.

    >> Just to fuel the flame war, consider a million line Python system. It's not
    >> uncommon with C++. :)

    >
    > Well, I won't go into how C++ code tends to be quite longer than their
    > Python equivalent (maybe I'm not too good at flame wars after
    > all... ;-) ). But the application I'm working on right now includes
    > nearly 300000 lines of Python (among other languages). That's not a
    > million indeed, but I wouldn't call it a small application. I've done
    > a lot of C, Java, and some C++ as well before. And so far, what I'm
    > seeing is that if you organize your work properly (TDD mainly...), the
    > development goes faster, with no significant decrease in quality for
    > the final product. So yes: I would consider a million line Python
    > system without fear.


    Uhm. :)


    Cheers, & thanks for your comments,

    - Alf
    Alf P. Steinbach, Oct 28, 2009
    #16
  17. Alf P. Steinbach

    tm Guest

    On 28 Okt., 09:58, "Alf P. Steinbach" <> wrote:
    > * tm:
    >
    > > On 28 Okt., 07:52, "Alf P. Steinbach" <> wrote:
    > >> [Cross-posted comp.programming and comp.lang.python]

    >
    > > Looking at your topic '(Python in Windows)', without taking a
    > > glimpse at your actual introduction, I have the following to say:
    > > I think it is not a good idea to teach programming with a focus
    > > on a specific operating system. Programming should IMHO be taught
    > > without reference to an operating system. Otherwise you just teach
    > > how to write unportable programs.

    >
    > I think you're trolling a little. :)


    No, I just saw too much stuff which pretends to teach something, but
    instead promotes an operating system. Contrary to many people I do
    not believe that something is automatically better when it runs
    under windows and when 'win' is part of the name.

    > Without reference to an OS you can't address any of the issues that a beginner
    > has to grapple with, including most importantly tool usage, without which it's
    > not even possible to get started, but also, very importantly, a file system.


    IMHO a beginner needs to use an editor and an interpreter or
    compiler. How to copy and remove files and directories is helpful
    also.

    > Learning programming without tools and without using files (or only using the
    > common denominator for file systems in OSes X, Y and Z) is sort of vacuous...


    I did not consider to teach programming without tools and without
    using files. The common denominator for file systems is IMHO enough
    to teach programming to beginners. Do you consider access control
    lists, mount points and symbolic links essential for the programs
    taught after 'hello world'?

    > In addition there's the motivational factor.
    >
    > Doing only academic examples, utilizing only a language's more or less portable
    > functionality, is very de-motivational, while the opposite is motivational.


    You obviously think that unportable programming is needed to
    motivate people. This is IMHO far from true. There are many portable
    programs which are motivational. I cannot provide portable Python
    examples but examples of portable Seed7 programs can be found here:

    http://seed7.sourceforge.net/scrshots/index.htm

    > >> Hi.

    >
    > >> I may finally have found the perfect language for a practically oriented
    > >> introductory book on programming, namely Python.

    >
    > > What is considered 'perfect' depends on the point of view. Languages
    > > have assets and drawbacks and I don't even use the term 'perfect'
    > > for my own language. :) There is always room to improve. Some of
    > > the features I consider important are discussed here:

    >
    > > http://seed7.sourceforge.net/faq.htm

    >
    > >> C++ was way too complex for the novice, JScript and C# suffered from too
    > >> fast-changing specifications and runtime environment, Java, well, nothing
    > >> particularly wrong but it's sort of too large and unwieldy and inefficient.

    >
    > > While many people consider Java inefficient they do so in comparison
    > > to C/C++. I doubt that Java is inefficient compared to most
    > > interpreted languages.

    >
    > >> I don't know whether this will ever become an actual book. I hope so!

    >
    > >> But since I don't know much Python -- I'm *learning* Python as I write

    >
    > > Normally I prefer books written by people who already know the
    > > stuff they are writing about. I would consider that it is not a good
    > > selling argument when a book was written to *learn* a language. :)

    >
    > Yes, it would be silly to write a book or whatever about Python. This text is
    > primarily about programming, at the novice level, not about the Python language.
    > The programming language is only a vehicle.
    >
    > However, as a vehicle the language needs to be suited for transport of the
    > novice. :)
    >
    > And it seems that Python is very well suited for that.


    I can think of several reasons why some people would not see it this
    way.

    > > Seed7 Homepage: http://seed7.sourceforge.net

    >
    > I'm not familiar with Seed, sorry.


    Maybe you take the opportunity and look at it now. :)

    Greetings Thomas Mertes

    Seed7 Homepage: http://seed7.sourceforge.net
    Seed7 - The extensible programming language: User defined statements
    and operators, abstract data types, templates without special
    syntax, OO with interfaces and multiple dispatch, statically typed,
    interpreted or compiled, portable, runs under linux/unix/windows.
    tm, Oct 28, 2009
    #17
  18. * Jon Clements:
    > On 28 Oct, 08:58, "Alf P. Steinbach" <> wrote:
    > [snip]
    >> Without reference to an OS you can't address any of the issues that a beginner
    >> has to grapple with, including most importantly tool usage, without which it's
    >> not even possible to get started, but also, very importantly, a file system.
    >>
    >> Learning programming without tools and without using files (or only using the
    >> common denominator for file systems in OSes X, Y and Z) is sort of vacuous...
    >>
    >> In addition there's the motivational factor.

    >
    > I certainly agree that focusing on Windows, you may be able to suggest
    > certain tools. IDE's, RAD environments, etc...


    I'm more thinking of things like the command interpreter.

    It's rather different in Windows and *nix.

    The first exploratory programs a novice makes almost have to be text-oriented,
    thus, some exposure to the command interpreter from the start. And most
    programming languages' text i/o facilities, including those of Python, are
    oriented towards standard streams and redirection of them, done from some
    command interpreter. And most Windows users, those who'd like to learn
    programming, know nothing about that, so unless they learn in a setting with
    knowledgable people around, it needs to be addressed in the text they're using.


    > However, I'm sure you
    > would consider that if you were writing a C++ guide, you would promote
    > portability and the STL. Of course, both languages offer platform-
    > specific libraries. Maybe a 'down side' with Python is that the
    > "batteries included" also include some functions marked in the
    > documentation as "Available on Windows only" etc... And specifically
    > suggesting an ActiveState install


    I suggested ActiveState because I know from earlier that their packages are easy
    to install and provide documentation in reasonable Windows CHM help file format.
    I did try the IronPython .NET implementation first :). But my experience with
    *nix folks' porting efforts is that they create Windows ports that don't handle
    spaces in paths, don't even handle backspace in dialogs they present, require
    undocumented environment variables set up (and explaining such takes a lot of
    pages & is demotivating), and just generally without any forethought or any
    reasonable automation, requiring a lot of explanation and hand-holding which
    would run to many pages, so I didn't even look at the CPython implementation.

    Perhaps I should.

    However, since ActivePython is said here to be just be CPython + packaging +
    stuff, I don't think there's any point in suggesting CPython, except perhaps to
    get version 3.x but that would currently have its own problems wrt. libraries
    and such, wouldn't it?


    > which includes COM interop etc...
    > (although I hope this would appear much later, if at all).


    I haven't looked at that part of things yet in Python but I guess it's the same
    as with other languages, some Automation-interface.

    I can't think of anything useful to do with that, though, except that some
    hardware is supplied with Automation interface drivers.

    For example, if I wanted to automate Excel (Microsoft's spreadsheet) I'd rather
    do that in VBA in Excel than in Python with COM interop driving the Excel
    Automation model.

    Microsoft has discontinued all the fun beginner's stuff that earlier was
    available via Automation.

    The only thing left in XP is the Microsoft assistant with an animated Wizard
    figure on the screen, but IIRC that's discontinued already in Vista.


    > PS. Can I suggest PSpad as an editor for the Windows environment, I
    > much prefer it to Notepad++ and it may well be worth mentioning.


    He he, it supports Esperanto!

    Great!

    Thx.


    Cheers,

    - Alf
    Alf P. Steinbach, Oct 28, 2009
    #18
  19. Alf P. Steinbach

    Jon Clements Guest

    Inline reply:

    On 28 Oct, 11:49, "Alf P. Steinbach" <> wrote:
    > * Jon Clements:
    >
    > > On 28 Oct, 08:58, "Alf P. Steinbach" <> wrote:
    > > [snip]
    > >> Without reference to an OS you can't address any of the issues that a beginner
    > >> has to grapple with, including most importantly tool usage, without which it's
    > >> not even possible to get started, but also, very importantly, a file system.

    >
    > >> Learning programming without tools and without using files (or only using the
    > >> common denominator for file systems in OSes X, Y and Z) is sort of vacuous...

    >
    > >> In addition there's the motivational factor.

    >
    > > I certainly agree that focusing on Windows, you may be able to suggest
    > > certain tools. IDE's, RAD environments, etc...

    >
    > I'm more thinking of things like the command interpreter.
    >
    > It's rather different in Windows and *nix.


    Yes, but not to the point it's required to make a massive distinction.
    'python myfile.py' will work whatever... This isn't meant to be
    'shell' scripting / system administration documentation :)

    >
    > The first exploratory programs a novice makes almost have to be text-oriented,
    > thus, some exposure to the command interpreter from the start. And most
    > programming languages' text i/o facilities, including those of Python, are
    > oriented towards standard streams and redirection of them, done from some
    > command interpreter. And most Windows users, those who'd like to learn
    > programming, know nothing about that, so unless they learn in a setting with
    > knowledgable people around, it needs to be addressed in the text they're using.
    >


    I've found the average Windows user (even Uni. students studying
    programming) are somewhat amazed at the black window with white text
    that pops up when they run cmd.exe. My favourite comment thus far is,
    "Hey, it's like really dark and stuff, and it knows my name, is that
    good?" :)




    > > However, I'm sure you
    > > would consider that if you were writing a C++ guide, you would promote
    > > portability and the STL. Of course, both languages offer platform-
    > > specific libraries. Maybe a 'down side' with Python is that the
    > > "batteries included" also include some functions marked in the
    > > documentation as "Available on Windows only" etc... And specifically
    > > suggesting an ActiveState install

    >
    > I suggested ActiveState because I know from earlier that their packages are easy
    > to install and provide documentation in reasonable Windows CHM help file format.
    > I did try the IronPython .NET implementation first :). But my experience with
    > *nix folks' porting efforts is that they create Windows ports that don't handle
    > spaces in paths, don't even handle backspace in dialogs they present, require
    > undocumented environment variables set up (and explaining such takes a lot of
    > pages & is demotivating), and just generally without any forethought or any
    > reasonable automation, requiring a lot of explanation and hand-holding which
    > would run to many pages, so I didn't even look at the CPython implementation.
    >
    > Perhaps I should.


    Sorry you've had bad experiences. However, I would take a leap that
    someone has used system/os specific calls (which are mostly un-
    necessary) and that at least they've made an effort to port to
    Windows. How many projects do you see authors porting from Win to
    *nix? :)
    [This could be construed as a slight rant, but oh well...]

    >
    > However, since ActivePython is said here to be just be CPython + packaging +
    > stuff, I don't think there's any point in suggesting CPython, except perhaps to
    > get version 3.x but that would currently have its own problems wrt. libraries
    > and such, wouldn't it?


    Libraries are moving towards the 3.* series. The development team have
    provided tools to assist in migrating, but yes, it's not going to be a
    smooth ride. I think the Python development team, and the timelines
    planned, are brilliant - take for instance the Boost libraries, of
    which some are only making it into the C++200X or whatever now.
    >
    > > which includes COM interop etc...
    > > (although I hope this would appear much later, if at all).

    >
    > I haven't looked at that part of things yet in Python but I guess it's the same
    > as with other languages, some Automation-interface.
    >
    > I can't think of anything useful to do with that, though, except that some
    > hardware is supplied with Automation interface drivers.
    >
    > For example, if I wanted to automate Excel (Microsoft's spreadsheet) I'd rather
    > do that in VBA in Excel than in Python with COM interop driving the Excel
    > Automation model.


    My most used tools for Excel (as you mention it) are listed on
    www.python-excel.org where John Machin has done a brilliant job of a
    platform independent library for reading content from excel
    spreadsheets [check out xlwt (for writing) and xlutils (by Chris
    Withers for convenience functions)].



    >
    > Microsoft has discontinued all the fun beginner's stuff that earlier was
    > available via Automation.
    >
    > The only thing left in XP is the Microsoft assistant with an animated Wizard
    > figure on the screen, but IIRC that's discontinued already in Vista.


    Oh the memories! The fun of programming another one, and popping up
    messages such as: "Are you making a phone call yet?", "You have a
    virus, call your doctor" etc... etc...

    Can't say I'm sad it's gone though :)

    >
    > > PS. Can I suggest PSpad as an editor for the Windows environment, I
    > > much prefer it to Notepad++ and it may well be worth mentioning.

    >
    > He he, it supports Esperanto!
    >
    > Great!
    >
    > Thx.
    >
    > Cheers,
    >
    > - Alf
    Jon Clements, Oct 28, 2009
    #19
  20. Alf P. Steinbach

    eb303 Guest

    On Oct 28, 11:57 am, "Alf P. Steinbach" <> wrote:
    > * eb303:
    >
    >
    >
    > > On Oct 28, 10:48 am, "Alf P. Steinbach" <> wrote:
    > >> * eb303:

    >
    > >>> On Oct 28, 7:52 am, "Alf P. Steinbach" <> wrote:
    > >>> [snip]
    > >>>> But since I don't know much Python -- I'm *learning* Python as I write -- I know
    > >>>> that there's a significant chance of communicating misconceptions, non-idiomatic
    > >>>> ways to do things, bad conventions, etc., in addition to of course plain errors
    > >>>> of fact and understanding in general, to which I'm not yet immune...
    > >>>> So I would would be very happy for feedback.
    > >>> OK, I'll start the flame war then: I can see the purpose of section
    > >>> 1.5, but from the end of the 3rd paragraph, you seem to go into
    > >>> religious matters rather than actual facts, which seems to me a bit
    > >>> out of place in a book only supposed to teach programming. Basically
    > >>> saying that any "serious" program has to be written in a statically
    > >>> typed language
    > >> No, I didn't write that.

    >
    > >>> and that such a language kind of automatically makes
    > >>> the development faster and the quality higher
    > >> No, I didn't write that.

    >
    > > Well, honestly, this is really what I understood when I've read:
    > > "the compiler can detect a lot of errors and save you from having to
    > > painstakingly & laboriously test every little detail. For a large
    > > program or system that really cuts down on the work (and hence time)
    > > and really increases quality"
    > > which what you did write, right?

    >
    > Yes that's what I wrote. What I intended to communicate was literally what I
    > wrote (which is true), but that's very far from what you understood, e.g. it
    > seems that you read my word "can" as, quoting you, "will automatically",
    > apparently with an implied "always".


    Well, sorry to keep the topic going, but I have a really hard time
    understanding your text as you claim you mean it. The word 'can' is
    actually there, but in the first sentence, not in the second. And when
    I read "For a large program or system that really cuts down on the
    work (and hence time) and really increases quality" after stating the
    supposed benefits of statically typed compiled languages, I do
    understand that a "large program or system" just has to be written in
    such a language, and certainly not in Python, which - again according
    to my experience - I know is just not true.

    But well, it seems I'm the only one around bothered by this text, so I
    guess the problem is with me. So if I ever get to teach programming, I
    guess I'll just have to find another book than yours... ;-)

    > > So maybe it is an understanding problem on my side, but even if it is,
    > > other people may have the same as I had, don't you think?

    >
    > Some will have the same misreading, and some will probably have other misreadings.
    >
    > I could reformulate it to cater for people who'd tend to read it your way and
    > other ways, but one the problem with that is that there are so many possible
    > ways to read a text when one s/can/will automatically/g, insert frivoluous
    > claims about a "serious" (what's that?) category of programs, etc., and, being a
    > fallible human being, I would be bound to miss some of them. ;-).
    >
    > Another problem is that delving into such details about possible things that
    > I've *not* intended to write, listing all possible such things I could imagine,
    > like, "note: I'm not claiming XYZ, even though that claim, made by some, is
    > vaguely associated with some of what I'm discussing", would make the first get
    > started chapter not 9 pages or whatever this one is, but 150 pages and going.
    >
    >
    >
    > >>> is just not true from my experience,
    > >> Yes, that's a strawman -- nearly always good in flame wars. ;-)

    >
    > >>> and from the experience of many people on this group, I
    > >>> guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
    > >>> highly subjective and should be completely rewritten, if not simply
    > >>> removed.
    > >> Just to fuel the flame war, consider a million line Python system. It's not
    > >> uncommon with C++. :)

    >
    > > Well, I won't go into how C++ code tends to be quite longer than their
    > > Python equivalent (maybe I'm not too good at flame wars after
    > > all... ;-) ). But the application I'm working on right now includes
    > > nearly 300000 lines of Python (among other languages). That's not a
    > > million indeed, but I wouldn't call it a small application. I've done
    > > a lot of C, Java, and some C++ as well before. And so far, what I'm
    > > seeing is that if you organize your work properly (TDD mainly...), the
    > > development goes faster, with no significant decrease in quality for
    > > the final product. So yes: I would consider a million line Python
    > > system without fear.

    >
    > Uhm. :)


    I'm serious. And even more: I'd fear a *lot* more a million lines
    application written in C++... But I do have a problem with C++... ;-)
    eb303, Oct 28, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harvey
    Replies:
    0
    Views:
    677
    Harvey
    Jul 16, 2004
  2. Harvey
    Replies:
    1
    Views:
    823
    Daniel
    Jul 16, 2004
  3. Snuffy
    Replies:
    1
    Views:
    333
    Andrew Thompson
    Apr 9, 2004
  4. windandwaves

    feedback wanted

    windandwaves, Jan 11, 2006, in forum: HTML
    Replies:
    5
    Views:
    557
    Toby Inkster
    Jan 12, 2006
  5. Vassilis Rizopoulos

    Ruby Introduction material wanted

    Vassilis Rizopoulos, Jul 10, 2007, in forum: Ruby
    Replies:
    1
    Views:
    79
    SonOfLilit
    Jul 10, 2007
Loading...

Share This Page