In our own experience we've seen errors like "Variable unassigned,
zero used" or "Return with no gosub" or "non-numeric value where
numeric required". We can call to subroutines with an invalid number
of parameters. We can accidentally reset some variable down a called
chain that affects code further up. All of these result in runtime
errors, often found by end-users before the developers. The rest of
the world perceives these runtime errors as being expensive to
correct, not "features" to dance around. Aren't we all tired of null
pointer exceptions, BSOD from Windows, and core dumps from *nix, where
some programmers have not properly written their code? Programmers
are as tired of it as end-users and that's why the mainstream
developer market considers strong typing to be generally "a good
thing". Of course there are successful exceptions like Perl and PHP.
There's no doubt that in Pick we're more free to focus on logic when
we're not constrained by the mechanics of fault prevention. As with
everything, freedom has costs. When we're talking about freedom of
speech we pay high costs. When we're talking about software, people
don't want to pay high costs in terms of quality because some
developer exercised too many freedoms in code - check the business
journals, software quality is one of the most highly discussed issues,
and has been for years. As always, I'm looking for some balance...

1- If end-users are finding errors in code, then you have a QA problem.
2- You are considerable weakening your case by quoting "BSOD from
Windows, and core dumps from *nix" etc. If I read this right, these systems
are all coded in more restrictive, typed languages, and there you have 'em.
Bugs. Failures. Is this indicative of poor programming or not? If so, are
you saying that there are less such in those environments than in Pick
Basic? Hard to prove, or disprove, but you know where I stand.
3- Return with no gosub has nothing to do with what we're talking about.
While a bounded function would force the compiler to catch errant returns,
you could just as well incorrectly add an extra return, valid syntactically
but invalid logically. The point is, there will always be errors.
4- Your much-vaunted compilers (e.g: C and jbase) have switches to turn
off, say, array boundary checking for supposedly "debugged" programs,
presumably for speed. If this is not an example of exactly what should
never, never be done, I don't know what is. What percentage of errors found
by "end-users" may result from this idiocy? Can we tell?
5- What are you referring to as "Of course there are successful exceptions
like Perl and PHP"? if they do not have stong typing and are successful,
what do you attribute that to? The syntax of many modern languages leaves
much to be desired, and contributes greatly to programmer errors, much more
so than Pick Basic does (willingly provide examples to those who have too
much time on their hands.) In fact, I'm surprised that those advocating
rigo(u)r accept a language as obscurationist as php (note the many ways of
screwing up by checking the official php website!); just that fact that
parts of string can embed the*value of a variable* merely by naming the
variable should have been a major nono in the design.
6- While I am regularly accused of being a devil's advocate, in this
instance I honestly feel that, yes, several thousand business journals and
computer science professionals are going along on issues just because that's
the perceived wisdom. All I can say is look at the original Pick results: a
full blown operating system and database well before its time with
performance and features years ahead of others, designed mainly by a English
Lit PhD and a Physics graduate. There was a reason that Pick was so
successful and productive -- it did not adhere to the conventional wisdom.
Whether that is a virtue in these days is debatable, but, in my mind, clear.

Chandru Murthi

Chandru, your points are well taken and it's clear you put considerable
thought into the subject.

Some time ago, I discovered the D3 runtime-errors file. There, you can
easily see those "fly-by" messages that one does not see on-screen. The
runtime-errors file, at least for me, is an indespensible programmer's
tool that can be used during development and even when the code is in
the production phase.

As a programmer/support aid, I wrote a simple little utility to help me
view and manage the runtime-errors file:

[LRTE] LIST AND MANAGE THE D3 RUNTIME-ERRORS FILE
1. List entire D3 RUNTIME-ERRORS file.
2. List errors for specific ITEM ID.
3. REMOVE errors for specific ITEM ID.
4. CLEAR entire D3 RUNTIME-ERRORS file.
Q. Quit the program. Also E or END quits.
Choose: 1
Output to (S)creen or (P)rinter.... S

Upon exit from the program, this message is displayed:

NOTE! If background program PURGE.RUNTIME.ERRORS is
running, RUNTIME-ERRORS will be purged on a regular
basis depending on the settings in that program.

Utility PURGE.RUNTIME.ERRORS runs as a phantom process to keep the file
size reasonable. It purges all entries older than n-days old (set in
the program).

Dave Weaver, Weaver Consulting

Wow! Thanks for pointing that out Dave

Glen --- what platform are you using?

Here is a sample from my D3/Linux system with command SORT
RUNTIME-ERRORS

Page 1 RUNTIME-ERRORS 10:36:00 24 Feb
2006

DATE. TIME... pib/user md...
ERROR.............................................

02/24 10:35 21 DAVE DAVE [B10] in program "INVENTORY.RESET",
Line 34: Variable has not been assigned
a value; zero used.

Dave Weaver

WHOOPS! SORT RUNTIME-ERRORS <CR> only shows the keys!
Take a look at the dictionary for file RUNTIME-ERRORS.
On D3, at least, it has most of the data you need.

Here is a fragment from my utility. Ignore the carat at the end of each
line (that is an end-of-line marker from my Pick-Screen-Editor).

110 * Option 1, List entire file *^
* Note: This section also services option 2 with a hot list."^
PRINT @(15,14):"Output to (S)creen or (P)rinter.... S"^
PRINT @(51,14):^
INPUT SP.FLG ; SP.FLG = OCONV(SP.FLG,"MCU")^
IF SP.FLG = '' THEN SP.FLG = 'S'^
IF SP.FLG = 'S' OR SP.FLG = 'P' ELSE GO 110^
*^
TCL = "SORT RUNTIME-ERRORS BY-DSND DATE BY-DSND TIME"^
TCL = TCL:" DATE TIME USERPIB ERROR DBL-SPC ID-SUPP"^
IF SP.FLG = 'P' THEN TCL = TCL:" (P"^
EXECUTE TCL^
IF SP.FLG = 'S' THEN^
PRINT "================Press <Enter> for
menu===================
INPUT ZZZ^
END^
GO 10^

If you want the code for the whole (D3) utility, drop me a line at
weaver digit2 digit2 at pacbell dot net
I'll send you (for free!) LRTE and PURGE.RUNTIME.ERRORS in text form.
Dave Weaver, Weaver Consulting

"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

When I discovered the one in UniVerse I also felt the same way.

Hi
You are of course quite correct Chandru. I had a great laugh when our local
c "expert" had to race round fixing monumental stuffups on his one size
suits all code when Apple changed the definition of a variable type around
System 8 time. I do not remember exactly but I think that it was 32bit
integer.
I have suffered major problems from #$%$# Unix core dumps on the EDGE caused
by simple tape read error. Totally inconsequential to the 135 users on Pick
until the machine just dumped and stopped.
Memory leaks are phenomenal in all these fancy typed languages and are
normally caused by dumping an object higher up the chain without cleaning up
as you go. It cannot happen in Pick basic.
A major nuisance in the Pick compiler that was introduced by Unix gurus of
AP fame is the demand that definitions of DIMS be in line physically not
just logically.
crt "hello"
gosub setup
*mainline
print newdim(1)
end
setup
dim newdim(50)
mat newdim = ""
return
Crashes

crt "hello"
gosub setup
*mainline
print newdim(C1)
end
setup
dim newdim(50)
mat newdim = ""
C1 = 1
return
Compiles and works.

As for the misdefined end of a loop that is merely a nuisance when reading
the code although I personally would prefer for it to be checked. The only
time I have seen a loop problem of this nature was when the programmer used
the same variable in two places.
For A = 1 to 20
yadda yadda
For A = 1 to 3
YAdda
next A
yadda
Next A
as it was spread over too many pages it took some finding. Simple answer
avoid multi page loops and be more logical in selection of variables eg use
MAINLOOP instead of A etc.
In my opinion anybody programming without using standardised routines for
data entry, file handling and screen handling at least is incompetent.
Personally I have used what are now known as 4gls all my life.
PICK flexibility is a godsend strong typing is a nightmare. Just try
extending a file in anything other than Pick, eg when I tried INFORMIX every
new variation during design required dumping the database and kicking off
again.
Peter McMurray

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

THAT is why you should run the processes with an (e ..... provided any
batch processes that are running (overnight) are either sequential OR
not inter-dependant.

I know that phantoms are supposed to abort when requesting input, but
IIRC they will "happily" hang around in the debugger - throw in TANDEM
and you can find out what is going on,and stop it happening again.

Failing this, we also schedule our overnight processing to take place
AFTER the backup has finished .... that way we can rollback if
necessary, but more importantly can re-process on another machine &
track the problem down (unless of course it is an indexing issue which
is "fixed" when transporteed to another machine & the indices are
rebuilt)

In D3 you can use list-runtime-errors to get a listing in reverse
chronological order that shows all of the relevent data in a very readable
format.

Bob Mitchell
President
Future Software Systems, Inc.

Chandru wrote:
Yes... and since many MV developers work alone with no QA staff it
seems more important to have tools which assist in the process.

As I said, the rest of the world recognizes the problem and is trying
to fix it. Microsoft is re-writing a large part of Windows to take
advantage of MORE strongly typed data, not less. Poor coding can only
be fixed by education which will or will not happen independent of the
tools. I think it's better to have tools with a safety catch than
with a loose trigger - we probably just disagree on where the happy
medium is. Honestly I think we're wasting our time debating something
that simply "is".

I have no idea how this discussion got started in the first place -
another example of how somehow I'm being asked to argue/debate/defend
something that wasn't even on my mind when I was accused of supporting
it.

No doubt. I've found the .NET compiler to be very clever about
finding possible runtime issues at compiler time. And FWIW, languages
like C++, Java, and C# have try/catch blocks to trap and handle such
logical errors so that the end-user doesn't see them. (I'm thinking
this is what I was talking about when we went off on compilers.) MV
has no such functionality. The point is that the developer really
doesn't know what all of the errors are that will occur, but if they
have really good error handling it will make their software look a lot
better than some green screen that dies with "Return no Gosub" and
leaves the user at a debug prompt.

At some point we know that the code is simply not going to fail and it
"may" be safe to loosen that safety switch in the name of performance.
Never say never...


Sheesh Chandru, what IS your point? I'm acknowledging that there are
different and valid ways to do things. Don't generalize specific
successes or failures into rules for the masses.


Maybe this is too fine a point but I don't consider data typing to be
syntactical. I also consider syntax (like tools) to be irrelevant.
Good or bad programming is a matter of developer skill, not so much
how easy it is for someone who doesn't speak the language to read the
code. If programmers are incompetent in general or with a specific
language then that's an issue that needs to be addressed separately
from condemning the syntax of modern programming languages. That
said, I don't appreciate syntactically obfuscated code either - I was
never very good with APL in it's native character set.

OK, so you're proving my point now (not that I had one) - PHP is
successful despite being loosely typed. Whoodda thunk it? Again,
(sheesh why do I need to keep saying this?) I really do try to strike
a balance in my posts by acknowledging the validities of many sides, I
rarely say "this sucks and that's good". I don't know if it's
surprising or not that other programmers can be so binary in their
thinking.


Hey, I go with what pays the bills and what works for me. Rigorous
syntax and intelligent compilers help me to write good code. Does
that put me in a mindless pool with millions of other people? OK,
whatever.

This notion about how good and right Pick is doesn't correlate to the
decreasing size of the market in relation to current mainstream IT.
Pick WAS ahead of its time but that time has passed and now it's
behind. We can't continue to ignore the present because of how right
we were in the past. I don't care if the mainstream market is right
or not, but they are mainstream, that's where the money is, and for
anyone who claims to be in business to make money I suggest they at
least try to understand why alternative technologies are successful.

T