Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Feedback wanted on programming introduction (Python in Windows)

Reply
Thread Tools

Feedback wanted on programming introduction (Python in Windows)

 
 
Martin P. Hellwig
Guest
Posts: n/a
 
      10-28-2009
Alf P. Steinbach wrote:
> * tm:
>> On 28 Okt., 07:52, "Alf P. Steinbach" <(E-Mail Removed)> 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.'
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      10-28-2009
* eb303:
> On Oct 28, 7:52 am, "Alf P. Steinbach" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
eb303
Guest
Posts: n/a
 
      10-28-2009
On Oct 28, 10:48 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * eb303:
>
> > On Oct 28, 7:52 am, "Alf P. Steinbach" <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Harris
Guest
Posts: n/a
 
      10-28-2009
On 28 Oct, 08:58, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * tm:
>
> > On 28 Okt., 07:52, "Alf P. Steinbach" <(E-Mail Removed)> 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
 
Reply With Quote
 
Francesco Bochicchio
Guest
Posts: n/a
 
      10-28-2009
>
> 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
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      10-28-2009
* eb303:
> On Oct 28, 10:48 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> * eb303:
>>
>>> On Oct 28, 7:52 am, "Alf P. Steinbach" <(E-Mail Removed)> 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
 
Reply With Quote
 
tm
Guest
Posts: n/a
 
      10-28-2009
On 28 Okt., 09:58, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * tm:
>
> > On 28 Okt., 07:52, "Alf P. Steinbach" <(E-Mail Removed)> 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.
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      10-28-2009
* Jon Clements:
> On 28 Oct, 08:58, "Alf P. Steinbach" <(E-Mail Removed)> 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
 
Reply With Quote
 
Jon Clements
Guest
Posts: n/a
 
      10-28-2009
Inline reply:

On 28 Oct, 11:49, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * Jon Clements:
>
> > On 28 Oct, 08:58, "Alf P. Steinbach" <(E-Mail Removed)> 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


 
Reply With Quote
 
eb303
Guest
Posts: n/a
 
      10-28-2009
On Oct 28, 11:57 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * eb303:
>
>
>
> > On Oct 28, 10:48 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> >> * eb303:

>
> >>> On Oct 28, 7:52 am, "Alf P. Steinbach" <(E-Mail Removed)> 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++...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Feedback from feedback on MCP questions Matt Adamson Microsoft Certification 0 04-27-2009 11:13 AM
Ruby Introduction material wanted Vassilis Rizopoulos Ruby 1 07-10-2007 06:37 PM
Introduction to Programming Using Java k.vidura@gmail.com Java 11 03-17-2006 04:05 PM
HELP WANTED HELP WANTED HELP WANTED Harvey ASP .Net 1 07-16-2004 01:12 PM
HELP WANTED HELP WANTED HELP WANTED Harvey ASP .Net 0 07-16-2004 10:00 AM



Advertisments