FP MF Laser Printers - Dave in Port Orange

[Fairlight]

On Wed, Jan 11, 2017 at 03:11:52PM -0500, Jose Lerebours via Filepro-list thus spoke:
> I have no problem with asking dumb questions as I believe it would
> be worst to pretend knowing and miss the opportunity to learn
> something.

I'm not even sure I have a problem with people asking 'dumb' questions.
Theoretically, the axiom says that there are no dumb questions.  I'm not
sure I buy into that 100%, but...  In any event, asking dumb questions,
okay, cool.  I think it's more irritating to me when people either don't
recognise that they should know something already, or that they don't
accept that they screwed up.  That's when I start getting irritable,
especially if they pull an attitude after they get a helpful response, even
if it had a bit of bite to it.

> Even today, after well over 20 years of programming in more than one
> language, I rarely ever bother to deal with "printer" compatibility
> issues.  I have written code to use Monarch, Zebra, HP, Oki and a
> number other printers and I paid attention, and focused on, the
> project at hand. I have never made an attempt to become an expert in
> all thing printers related - I think that knowing that one has other
> experts within reach, one chooses to hire that expert should the
> need rise - Like Jim.

The issue, I believe, is that PCL6 basically came about around the time
of host-based printers.  Really, it's supposed to be in the domain of a
print driver to do translations.  I thought consesus amongst those who
"do" printers was that these are really to be considered dumb devices
unless connected to a driver-bearing host.  They're not intended to be
bring-your-own-programming like the older standalone models.  That's my
distillation of every thread I've read about PCL6 printers.

> There is also the chance that a programmer comes into a shop and now
> has to clean up a poorly written application.  If you walk into this
> situation, you might want to clean up fixed fields and asking the
> original posted question may explain that - Most of us
> directed/suggested the problem be addressed at its root.

Yeah, I'll grant that as a possibility.  It's probably actually more
probable given the number of people falling over or otherwise moving on
from filePro, and the need for replacements.  I don't think I really have
that in my head as a consideration when I read most things here, honestly.
That's probably because I moved to many RTFM-oriented communities, where
most of the questions are either -very- novice, or -very- obscure, with
little middle ground.  That's largely because if you ask the simple stuff,
you'll get pointed at the manual, and if you ask the hard stuff, well
you're already past the middle ground where you've learned the bulk of the
material.

I grant that it's a legitimate situation which I probably should consider
as a possibility.

> Also, we do not know if this person asking the question is 110% up
> to speed with filePro syntax and asking the question should not be
> frowned upon, at least I would not.

There I'll beg to differ.  /0 is a language-agnostic practise against which
one should implement safeguards.  Syntax is irrelevant, past the point of
detection, and it should never have to -get- to the point of detection.
That's why we almost universally said it should be stemmed at the source.
If someone doesn't know enough syntax to check for a zero or a blank,
/0 is really going to quickly become the least of their worries, so I
wouldn't even concern myself with that particular benefit of the doubt.  I
mean...you're checking an equality in a conditional. filePro is structured
-entirely- around If/Then.  If you can't get 50% of that structure correct
enough to do a basic equivalency test, there's a problem, right? 

To ask how one detects that something was allowed to go grievously wrong
instead of preventing it from doing so in the first place is to not
recognise a very basic and foundational issue.  An ounce of prevention, and
all that...

mark->
-- 
Audio panton, cogito singularis.