Feedback wanted on programming introduction (Python in Windows)

A

Alf P. Steinbach

* bartc:
Alf P. Steinbach said:
[Cross-posted comp.programming and comp.lang.python]
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.

Have you ever done technical writing before? With positive feedback?

Yes, and yes.

You use the highly commercial-looking activatestate website; what's
wrong with www.python.org?

I guess "commercial looking" is something negative.

Please note regarding the question: I'm not a telepath. I don't know what you
think is wrong with [www.python.org]. And I have no interest in evaluating the
site for you, at least not unless you pay me for that job.

You say elsewhere that you're not specifically teaching Python, but the
text is full of technical details specific to both Python

Yes. A programming language is required to do programming. Can't do without it,
sorry.

and Windows,

not much actual programming!

Hm. There's /only/ programming in there and nothing else so far. But given that
you think programming can be done without a programming language, I hypothesize
that there is something to learn for you about what programming is. :)

Python has a lot of baggage which is OK if that's what's going to be
used, but otherwise is unnecessary confusion: where to put the program
code (typed in live or in a file, or some combination); whether to call
the file .py or .pyw; the difference between console and graphical
programs and so on.

Well.


Cheers & hth.,

- Alf
 
A

Alf P. Steinbach

* Rhodri James:
I'd say this was at best an extremely misleading statement. The robust,
dependable, usable, low-fat, carcinogen-free programs that I've written
fall into two categories; either they are embedded programs whose
environment is the silicon they're running on pretty much literally, or
they carefully *don't* know about their environment so run equally
effectively everywhere. It's the programs that do know about their
environment and go on to make assumptions about it that turn out
not to be robust, dependable, or very often usable.


Bwahahahahahahaha.

Uh, sorry. I know that wasn't terribly nice, but the politest answer
I can think of that gets over the utter wrongness of this assumption is
"Hell, no."


You may or may not be aware that some of these things are limitations of
the underlying disc format,

Sorry no, it isn't.

Even assuming you meant the more reasonable "file system", no, it isn't.

Depending on the file system a program may be unable to create such things as I
mentioned. And depending on the program design it may be reasonable to refuse to
create them.

But a program should have no trouble deleting the files etc. once they're there.

That's why the Windows API handles them just fine, while Windows Explorer does
not. You may consider, since you're unfamiliar with the API, that mostly it's no
problem doing these things in the command interpreter, which has no special
support (rather, the reason it's easy is because it doesn't properly check
command arguments). And from that you can deduce that the API support is there.


and some of them limitations of the API.
Laying them at the feet of Windows Explorer is a tad unfair.

Sorry, no. That's where the responsibility is. No other program or API is
responsible.

That rather depends on what tool you're using for what purpose. Tools
which require stonking amounts of flagging or button-pressing for simple
uses are IMHO bad tools. Most IDEs fall into this category. If your
tools make simple things hard, stop recommending them to people and get
better tools.


Mercifully this is rubbish. For most purposes with most tools even
Windows users don't need to know much if anything about environment
variables and the registry. Needing to know anything about the
registry is usually a sign that Windows has stuffed you up royally.

I deduce that you mainly use IDEs and don't know about the things you're
commenting on here (more than you did above). Sorry, but there it is.

The fact that you can say this and write "How to program" books
terrifies me. Don't make me compare you to Herbert Schildt!

I'm sorry but you haven't written anything correct in this article.


Cheers & hth.,

- Alf
 
S

Steven D'Aprano

The disservice is in teaching folks to use non-standard elements, which
is (sort-of) what __future__ is. Changes to the language are
experimented with in __future__

That is incorrect. Changes to the syntax or language semantics are
*introduced* with __future__, so as to avoid a sudden and disruptive
backwards incompatible change. If a feature makes it into __future__, it
is anything but experimental.

http://www.python.org/dev/peps/pep-0236/


There is nothing "non-standard" about features introduced with
__future__. The only thing that concerns me is that __future__ may be a
little too advanced for beginners.


and can change from one release to the next.

Python guarantees that no feature will ever be removed from __future__.
It may become a no-op, but it will always be there. Note that 3.0 still
defines nested_scopes, even though that's been standard in the language
since 2.2:

[steve@sylar ~]$ python3.0
Python 3.0.1 (r301:69556, Apr 2 2009, 00:41:38)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information._Feature((2, 1, 0, 'beta', 1), (2, 2, 0, 'alpha', 0), 16)


If memory serves, the with statement is an example of having
different behavior when it was moved out of __future__ and made a
standard part of the language.

I feel safe to claim you are wrong without even checking.
 
A

Alf P. Steinbach

* Ethan Furman:
You don't agree, so it's a straw man? You didn't know, and when the
information is pointed out, it's a straw man?

No. It's a "straw man" argument when the argument is made against something
that's not the real position -- often it's the opposite position -- of the
opponent. And that's what you (probably unwittingly, but literally) did: you
claimed the text used "non-standard elements" and therefore was subject to
changes in new versions of the language, while the reality was opposite: a
defense against changes in new versions, and improvement in that respect.

Not that it matters much now. ;-)

I mean, I've started the work to change the text to 3.1.1.

I used "from __future__" to write forward-compatible calls of print,
so that those examples would not mysteriously work or not depending on
the Python version.

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.File "<stdin>", line 1
SyntaxError: future feature print_function is not defined

Hmmm... Doesn't seem to work in 2.5. So much for not working on a
different version.

That's a bit of a straw man argument. :) "Forward compatibility" is one way.
What you illustrate is lack of "backward compatibility", which is the other way.

It would be utterly silly to try to make the examples backward compatible.

I mean, how far back? :-D

From what I've seen of your posts so far, you wouldn't have known if
the print in __future__ was slightly different from the actual print in
3.x anyway.

Then you probably haven't read the passage in ch 2 where I introduced that.

If so then I understand why you commented as you did -- misled by the other
poster's comment.

That happens a lot on Usenet, people use all kinds of rhetoric devices and
assumptions, sometimes intentionally and sometimes uninentionally, and sometimes
that "works", misleading others.

Which is precisely the point raised by several -- writing a book for
novices, while still a novice, is going to be risky... especially if you
keep disregarding good advice about what to include and exclude.

Yes, it's risky.

Although please note that I'm very far from a novice at programming.

I have, through the years, learned quite a number of programming languages
(started with Basic and 8080 assembler back around 1980), so I believe there is
a >0 chance of doing this with a positive result, but yes, risky!

And no, I'm not disregarding advice; on the contrary, the reason I asked for
feedback in a public forum was precisely because I'm *very* aware of the risk,
as I stated in the thread's starting article. But there is also a risk with this
public exposure, of course. Not everyone on Usenet is equally serious.

Btw., regarding the serious ones, I really appreciated your point about
"Tkinter" -> "tkinter", for example. ;-)

You're missing the point. If it's in __future__ it's subject to change.
Most likely it won't be a drastic change, but it *can* change. The
'experimental' is more along the lines of "hey, this is coming down the
pike, let's do some stress-testing so we can nail down the final
implementation".

Does that mean that 'print' is still subject to change as of 3.1.1?


Cheers,

- Alf
 
A

alex23

Alf P. Steinbach said:
However, given what I've now learned about the current situation wrt. versions
of Python, where Python 3.x is effectively a new language, and where apparently
ActiveState has no installer for that, I'm rewriting to use the "official"
distribution.

I hope the rest of your research is a little more thorough:

"Current releases of ActivePython are 2.6.3.7, 3.1.1.2, and 2.5.4.4."

From: http://www.activestate.com/activepython/
 
A

Alf P. Steinbach

* alex23:
I hope the rest of your research is a little more thorough:

"Current releases of ActivePython are 2.6.3.7, 3.1.1.2, and 2.5.4.4."

From: http://www.activestate.com/activepython/

Thanks.

Several others have already mentioned the same else-thread, but thanks anyway! :)

And no, I didn't do any research on that. If it mattered more (e.g. appearing as
statement in the text) I'd have done that. The nice thing about Usenet is that
people rush in to correct things. ;-) <url: http://xkcd.com/386/>


Cheers,

- Alf
 
B

bartc

Alf P. Steinbach said:
* bartc:
Alf P. Steinbach said:
[Cross-posted comp.programming and comp.lang.python]
You use the highly commercial-looking activatestate website; what's wrong
with www.python.org?

I guess "commercial looking" is something negative.

Please note regarding the question: I'm not a telepath. I don't know what
you think is wrong with [www.python.org].

python.org seems to be the main site. Google "python download" and that is
the first hit.

Their windows download seems to be 13MB against the 32MB of activestate, and
the IDE provided seems more advanced that the 'console window' you have in
your tutorial. I'm just asking why your chose one over the other...
And I have no interest in evaluating the site for you, at least not unless
you pay me for that job.

....but if that answer is going to cost me money, then forget it. I think
that statement just answered it.
Yes. A programming language is required to do programming. Can't do
without it, sorry.

You make it sound complicated however.
 
B

Bruno Desthuilliers

Alf P. Steinbach a écrit :
(snip)
Microsoft's
own Windows Explorer, the main GUI shell for Windows, which presumably
was made by the best programmers available

Mouarf !!!

+1 JOFY (=> Joke Of The Year)
 
A

Alf P. Steinbach

* bartc:
python.org seems to be the main site. Google "python download" and that
is the first hit.

Their windows download seems to be 13MB against the 32MB of activestate,
and the IDE provided seems more advanced that the 'console window' you
have in your tutorial. I'm just asking why your chose one over the other...

I've changed that choice, so it's not something very important, but an
ActiveState installation of some language generally Just Works, while other
installations of non-Windows-specific programming stuff generally doesn't,
requiring manual fixups.

For example, the mainstream Python 2.6 distribution failed to install when asked
to pre-compile (advanced option).

Regarding the "IDE" I'm not sure what you're referring to because there's no
such thing AFAICS. There's IDLE, which is referred to as an IDE but is (1) also
present in the ActiveState distribution and is (2) not really an IDE in any but
perhaps a formal sense. It's just a primitive editor with a primitive debugger
that, in Windows, has an annoying bug regarding highlighting of code.


[snippety]

Cheers & hth.,

- Alf
 
A

Alf P. Steinbach

* Alf P. Steinbach:
* bartc:

I've changed that choice, so it's not something very important, but an
ActiveState installation of some language generally Just Works, while
other installations of non-Windows-specific programming stuff generally
doesn't, requiring manual fixups.

For example, the mainstream Python 2.6 distribution failed to install
when asked to pre-compile (advanced option).

Sorry, I meant 3.1.1. I posted links to screenshots else-thread. Earlier.


Regarding the "IDE" I'm not sure what you're referring to because
there's no such thing AFAICS. There's IDLE, which is referred to as an
IDE but is (1) also present in the ActiveState distribution and is (2)
not really an IDE in any but perhaps a formal sense. It's just a
primitive editor with a primitive debugger that, in Windows, has an
annoying bug regarding highlighting of code.


[snippety]

Cheers & hth.,

- Alf
 
D

Dann Corbit

In <[email protected]>, Dann
Corbit wrote:



Agreed. But why should you have to?

As opposed to...?
PDF and PS are no more or less proprietary than any other format. And
Ghostscript is open source.
A man who doesn't particularly enjoy relying on proprietary non-text
formats, however, is not crippled, just cautious.

Since Ghostscript is an open source project, this is a non-sequitor.
A man who cannot express what he needs to express /without/ resorting
to .pdf format is computer-illiterate.

You have two choices at citeseer:
PDF, PS.

All college papers are also posed in one of those two formats.

It takes me about 7 seconds to download the latest reader from
Ghostscript/Ghostgum or Adobe. If I need to know the guts of these
formats, I can simply examine the Ghostscript guts. Quite frankly, I
don't care at all, since I am interested in the information content and
find the method of delivery utterly irrelevant.

To me, the argument is like objecting to money because it is either
paper or metal and you would prefer stone.

Everyone uses paper or metal and either is superior to stone anyway.
 
A

Alf P. Steinbach

* bartc:
Python has a lot of baggage which is OK if that's what's going to be
used, but otherwise is unnecessary confusion: where to put the program
code (typed in live or in a file, or some combination); whether to call
the file .py or .pyw; the difference between console and graphical
programs and so on.

Hi.

I forgot or decided not to really answer this part earlier, so...

First of all, note that nothing of this is specific to Python.


(1)
"Where to put the program (typed in live or in a file)".

This is common to all languages that offer interpreted execution.

It is a feature, not a problem: in *addition* to putting your statements in a
file for later execution, i.e. in addition to creating ordinary programs, you
can explore the effects of statements by typing them at the interpreter.

Storing the statements in a file is to create a "program" in the usual sense.

Typing statements at the interpreter is just interactive use of the interpreter.
Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.

Which is very convenient. :)


(2)
"the difference between console and graphical programs"

This is a Windows issue.

Windows makes this differentiation.

Thus, it's there *regardless* of programming language. And for example, it
doesn't matter whether the language offers an interpreter. With C or C++ you
tell the linker which subsystem you want. With Java you use 'java' or 'javaw' to
run the program as respectively console or GUI subsystem. With JScript and
VBScript (script languages bundled with Windows) you use 'cscript' or 'wscript'
to run the program as respectively console or GUI subsystem. With Ruby you use
'ruby' or 'rubyw' to run the program. And so on -- in the end it's always the
bottom level executing machine code program that is console or GUI subsystem.

Do you think I should mention this in the text?

It will make the text longer, and I worked hard to make ch 1 as *short* as
possible! :)


(3)
"Whether to call the file .py or .pyw"

This is a feature, that you can relieve the user from the burden of choosing the
most sensible way to execute the file (the user doesn't have to choose whether
to use a console or GUI subsystem version of the interpreter, and the user
doesn't even have to know that there is an interpreter involved).

It's a common convention for many languages (using those languages' filename
extensions, of course), but it's not universal.


Cheers & hth.,

- Alf


PS: and yes, programming *is* a bit complex! That's what also makes it fun. <g>
 
M

Mensanator

* bartc:




Hi.

I forgot or decided not to really answer this part earlier, so...

First of all, note that nothing of this is specific to Python.

(1)
"Where to put the program (typed in live or in a file)".

This is common to all languages that offer interpreted execution.

It is a feature, not a problem: in *addition* to putting your statements in a
file for later execution, i.e. in addition to creating ordinary programs, you
can explore the effects of statements by typing them at the interpreter.

Storing the statements in a file is to create a "program" in the usual sense.

Typing statements at the interpreter is just interactive use of the interpreter.
Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.

Unless you type something like:
while n>1:
if n%2 == 0:
n //= 2
else:
n = 3*n + 1
print(n)

which *IS* a stored program. It's just stored in RAM and will
be lost on shutdown if not specifically saved.

Even a single line is a "stored" program in the sense that you
can put your cursor on the line and hit return to repeat the
execution, so obviously, it's stored somewhere.
 
A

Alf P. Steinbach

* Mensanator:
Unless you type something like:

while n>1:
if n%2 == 0:
n //= 2
else:
n = 3*n + 1
print(n)

which *IS* a stored program. It's just stored in RAM and will
be lost on shutdown if not specifically saved.

Even a single line is a "stored" program in the sense that you
can put your cursor on the line and hit return to repeat the
execution, so obviously, it's stored somewhere.

Yes.

As you quoted me on:

Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.

However, at least for [comp.programming] the term "stored program" has a
different often used meaning, the one that you employ above (which, by the way,
was not von Neumann's invention, he was falsely credited with that idea).

And perhaps that needs to be pointed out when or if I discuss stored programs,
like some kind of Wikipedia disambiguation page, so, thanks! :)

But geneally getting into that kind of terminological fine distinction, such as
here, what can be regarded as "stored", isn't really useful, though. It assumes
an adversarial reading, which is not a useful assumption. And the only possible
way out with that assumption is to define all relevant terms in a very technical
way, which (1) leads to qualifications that end up being umpteen times longer
than a simple statement of whatever one attempts to communicate (like,
replicating all thousand+ pages of a technical language standard just to define
the concept of "variable", which is silly), (2) leads to ungrokkable lawyereese
language, absolutely not suitable for novices, and (3) in practice never
actually accomplishes the purpose of ironclad definitions, as evidenced by e.g.
"variable" in C++ still being subject to some disagreement over what it is...

I'm very very happy that most comments about perceived defects in the text and
in my responses here, have only disagreements over terminology. I had expected a
slew of errors being pointed out, since I'm new to Python. <g> Still, I'm fairly
sure that there actually *is* such a slew of errors, because there is in any
text of more than ten pages or so; any good book has a volumious errata list...


Cheers, & thanks,

- Alf
 
A

alex23

Alf P. Steinbach said:
And no, I didn't do any research on that. If it mattered more (e.g. appearing as
statement in the text) I'd have done that. The nice thing about Usenet is that
people rush in to correct things. ;-) <url:http://xkcd.com/386/>

Unfortunately, the idiocy people say on the internet can be linked to
and referenced forever.

I guess it's better to say things like "you seem to have a bunch of
astoundingly ignorant preconceptions for someone passing themselves
off as a teacher" if I append a smiley to it, yeah? :)
 
A

Alf P. Steinbach

* alex23:
Unfortunately, the idiocy people say on the internet can be linked to
and referenced forever.

I guess it's better to say things like "you seem to have a bunch of
astoundingly ignorant preconceptions for someone passing themselves
off as a teacher" if I append a smiley to it, yeah? :)

Don't know, but you sound like a troll.

Of course since you post anonymously it doesn't matter.


Goodbye,

- Alf
 
A

Alf P. Steinbach

* Rhodri James:
Actually I should have mentioned the filing system as well as the disc
format (which does matter). I may not be using correct Windows
terminology,
since I'm referring to both the bytes on hardware and the software stack
that terminates in the OS API.

Still, colour me surprised. I had assumed that NTFS had some (large)
limit on filenames, and 256 sounded plausible.

For NTFS it's 32K or 64K wide characters, I don't recall which. But what's
important is that that's also the API level limit. You can find most of the
details in Microsoft's documentation of CreateFile (but it's off-topic here).

Given that the API level makes it possible for long paths/names to exist, a
program should be prepared to handle them, although it may reasonably refuse to
create them. Windows Explorer fails to handle them. Not only to create them.

A filesystem may impose a lower limit, but a program should ideally not be
limited to or just work with a given filesystem (note: Windows supports multiple
different filesystems, but accessed via the same general API).

More to the point, I
was under the impression that path manipulation logic in the filing
system had limited sized buffers, which were the cause of this fault,
and that Exploder's only sin was not programming around the bug. In
fact, the more I think about it, the more sure I am that I've had to
play silly buggers on the command line myself to get around this.


Your faith is touching, but fundamentally misplaced.

By the facts, if I believed that most programs have no problem it would be a
misplaced belief, yes (assuming that's what you mean above). But my argument and
concrete example was the opposite. It expanded on my statement that

"Unfortunately even most professional programs do not handle the requirements
of their environs very well"

So in what you quoted above I used "should" in the sense of the ideal to strive
for, and illustrated the harsh reality that it currently isn't that way, by the
concrete Windows Explorer example.

This is worth keeping in mind: in a Usenet discussion, context often disappears.
Looking up-thread is then one way to find out what it's all about. :)

Having stuffed this up many, many years ago, my recollection is that
it needed a certain deviousness to get around.

Yes.


<example>
C:\> md rhodri & cd rhodri

C:\rhodri> md \\?\c:\rhodri\con

C:\rhodri> dir
Volume in drive C is maindisk
Volume Serial Number is C469-4FA2

Directory of C:\rhodri

01.11.2009 22:16 <DIR> .
01.11.2009 22:16 <DIR> ..
01.11.2009 22:16 <DIR> con
0 File(s) 0 bytes
3 Dir(s) 18 405 834 752 bytes free

C:\rhodri> cd con
The system cannot find the path specified.

C:\rhodri> cd \\?\c:\rhodri\con
'\\?\c:\rhodri\con'
CMD does not support UNC paths as current directories.

C:\rhodri> rd \\?\c:\rhodri\con

C:\rhodri> _
</example>


To keep it short the above example is of something that no program really is
expected to handle. It's just an example of the mechanisms involved. Also, it's
nice with concrete examples, to show that one is not just blowing wind. :)

In the case of the long
path names, my deduction from comparing the behaviours of the command
line and Explorer was that the API limited the path name length, and
Explorer didn't use relative paths to get around it. I find it hard
to call that a bug, when it's only really exposing a limitation of the
underlying FS.

No, it's not exposing a limitation of the underlying FS.

It's exposing a limitation in the way that the program deals with paths.

Apparently Windows Explorer uses fixed size buffers for paths, rather small buffers.

You deduce incorrectly. I'd unbend enough to admit that setting
environment variables is frequently very useful to inveterate command-
line users like myself, and that Windows makes that a lot harder than
necessary, but your original statement still reads like scaremongering.

Why am I defending Windows again?

Because I used a Windows-based concrete example. Then by attempting to raise
doubts about that which you found hard to believe, you got into an absurd
rhetorical position. He he, it happens very often, but happily you saw it at
once & adjusted: some folks just go on defending an indefensible position, they
happily disregard facts and logic, and then it gets, "interesting". :)


Cheers,

- Alf
 
A

Alf P. Steinbach

* Rhodri James:
This is a weird attribution style, by the way. I don't think it helps.

That's a pretty weird thing to comment on.

And as far as I can see the comment doesn't make sense except as an attempt to
find something negative to say.

But anyway, the point about '*' was, once upon a time, that it made for a very
clear style of quoting in old newsreaders. Nowadays the tools are generally of
lesser quality (e.g. I'm using Thunderbird). And so it doesn't really have much
of that advantage left, but I'm using it anyway; I can be pretty stubborn about
issues of quality.

For NTFS it's 32K or 64K wide characters, I don't recall which. But
what's important is that that's also the API level limit. You can find
most of the details in Microsoft's documentation of CreateFile (but
it's off-topic here).

Actually it [the limit]'s not

You're disputing a plain fact.

For which you've been given a technical reference, as well as concrete example.

I'm sorry, but it's idiotic to dispute plain facts.

, since it's a perfect example of the "not reading quite
carefully enough" others have pointed out before. You make this statement
as an absolute, iron-clad assertion. Checking the MS website, we find it
actually says:

"Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following
paragraphs), the maximum length for a path is MAX_PATH, which is defined
as 260 characters."

The exceptions are unicode versions of some of the functions, which do
give you ~32K characters. However, the docs are pretty specific about
what is and isn't the API limit.

I'm sorry but you're misunderstanding the documentation.

In your own words, you're "not reading quite carefully enough".

By the way, your technique of vague ad hominem attack here is detestable.

But anyway, if you read the documentation of CreateFile as I directed you to, or
simply read on where you was, then you get a more technically correct picture.

Or, by applying logic you can /deduce/ that since >260 character paths can and
do exist, 260 characters is not "the limit".

The MS documentation is unfortunately not all that clear. In many cases (the
most infamous one is perhaps the claim that a program's entry point is WinMain)
it's just plain incorrect, being written by technical writers. But it's simple
enough to write a few programs to check it out.

Since this applies to the command
line just as much as to GUIs,

No, it doesn't. And you've been given a concrete example of how.

You can't just go on *inventing* facts.

Facts are facts, your fantasies & wishes are your fantasies & wishes.

I'll repeat my claim that blaming Explorer
for something that causes just as much grief on a command line is a
tad unfair.

I'm sorry, but there's a complete lack of logic in that, as well as misdirection.

First, regarding the misdirection, it is untrue that I have "blamed" Windows
Explorer for this. The blame, if any is to be affixed anywhere, belongs
elsewhere than with a computer program.

Second, regarding the logic, that a program exhibits low quality in some respect
is not OK just because there's another program that also exhibits low quality.

More importantly, I accuse you of making very definitive statments
that turn out to be insufficiently researched.

That would be OK and what I want. :) But you haven't. You're making general
vague statements about quality, but haven't addressed any concrete thing in the
text. And what you have responded to here in this thread, it's all been
incorrect. In this latest article you have even started disputing simple
technical facts and started making fallacious deductions, shown above.

That's not an
encouraging state of affairs in someone planning to write a beginners'
textbook. Having originally learned C from one of Herbert Schildt's
books, I reckon I've earned the right to be highly allergic to this!

I'm sorry to hear that you had to endure that.

It's an old saying that the low price of Herbert's annotated C++ reference,
compared to the official standard, reflected the value of his annotations...

But that's no excuse to now start emulating Herbert, regarding blatant disregard
for facts and logic, as you've done above.


Cheers & hth.,

- Alf
 
T

Thad Smith

Richard said:
... so I cheerfully installed it on the
user's desktop machine (Windows ME, would you believe), and then set
about configuring the reader, when... ouch! No PDF reader on the
machine. Not even an ancient Adobe version. Oh dear. Program suddenly
rendered completely useless for that person.

There is a Catch 22 for installing Adobe Reader from the Adobe site (
http://get.adobe.com/reader/ ) for the first time, without making a
blind promise: "By clicking the Download button you agree to the License
Agreements and Privacy Policies for the software included." Guess what
format the license agreement is in. ;-)
 
P

Pascal J. Bourguignon

Thad Smith said:
There is a Catch 22 for installing Adobe Reader from the Adobe site (
http://get.adobe.com/reader/ ) for the first time, without making a
blind promise: "By clicking the Download button you agree to the
License Agreements and Privacy Policies for the software included."
Guess what format the license agreement is in. ;-)

Use xpdf to read it!

Then use xpdf to read the other pdf documents, and forget about
proprietary software?
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top