On Oct 28, 11:57 am, "Alf P. Steinbach" <al...@start.no> wrote: > * eb303: > > > > > On Oct 28, 10:48 am, "Alf P. Steinbach" <al...@start.no> wrote: > >> * eb303: > > >>> On Oct 28, 7:52 am, "Alf P. Steinbach" <al...@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++... ;-) -- http://mail.python.org/mailman/listinfo/python-list