Feedback wanted on programming introduction (Python in Windows)

[eb303]

On Oct 28, 11:57 am, "Alf P. Steinbach" <al... at start.no> wrote:
> * eb303:
>
>
>
> > 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:
> >>> [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++... ;-)