Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach
alfps at start.no
Wed Oct 28 11:57:59 CET 2009
> On Oct 28, 10:48 am, "Alf P. Steinbach" <al... at start.no> wrote:
>> * eb303:
>>> On Oct 28, 7:52 am, "Alf P. Steinbach" <al... at start.no> wrote:
>>>> 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
>> 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.
Cheers, & thanks for your comments,
More information about the Python-list