Xref: utzoo comp.databases:1565 comp.os.misc:657
Path: utzoo!utgpu!attcan!lsuc!ncrcan!aimed!nick
From: nick@aimed.UUCP (Nick Pemberton)
Newsgroups: comp.databases,comp.os.misc
Subject: Re: The Cult of Pick -- Info on being Initiated? :)
Summary: Perhaps a more reasonable account of Pick is in order...
Message-ID: <30@aimed.UUCP>
Date: 22 Oct 88 21:27:27 GMT
References: <360@intek01.UUCP> <4655@pdn.UUCP>
Organization: AIM, Inc, Toronto, Ontario
Lines: 59

In article <4655@pdn.UUCP>, locke@pdn.UUCP (Richard Locke) writes:
> In article <360@intek01.UUCP> mark@intek01.UUCP (Mark McWiggins) writes:
>
  ...

> I worked with the Pick system on a plain IBM PC in 84-85 (not at Paradyne!!!).
> I was not at all impressed.  In fact, I was depressed!  The PC was supporting
> two developers.  If one of us did a compile, life slowed to a crawl.
>

On a PC eh? That really doesn't surprise me. Ever seen unix run on a PC
with more then one person and not crawl? Even this machine, a 286 at 12
MHz crawls when things get loaded (like just the news feed...)

The pick os is actually much less taxing on a given machine then unix. For
example, the ncr tower can run aprox. 3 times the number of concurrent
users on pick (ADDS version) then can unix (this is empirical, of course,
but easily observed)
 
> >I wasn't very interested up to now, mainly because (so the word went) a
> >BASIC dialect was the only programming interface.
> 
> This was true with the system I worked on.  Some of the problems with this
> were: 1) BASIC! yuck!  2) a limit of ~12K on source files (after that you
> had to delete comments ;-) 3) interpreted BASIC = comments slowing down
> execution, 4) file system subject to serious corruption due to power glitches,
> 5) no communication with DOS, DOS file system.
> 

Well, BASIC is objectionable, I agree, but pick has gone some distance to
ammend that. It *is* structured, it features dynamic linking of subroutines,
and it is fantastic at database manipulation, which is the niche into which
pick fits itself. I haven't seen any PICK machine with a 12 K limit on source
code, and I've worked on a lot of them over the last 7 years (pick systems for
AT, ADDS Mentor, HoneyWell Ultimate to name a few).

Comments only slow down execution (by one opcode) if you leave them in, there
is a compiler option to remove them. They are usually only left in if the
program is to be used with the debugger, so that the debugger can keep track
of where in the source it is executing. 

The file system shouldn't suffer at all in a reasonable hardware set up - like
any virtual system, if the power is cut off and there is no means of getting
whats in RAM back to disk, the file system will be corrupted. But even that
is recoverable.

There is communication with DOS if you are on the right package. I'd like to
know what version of PICK you were running... Sounds ancient.


Pick is definately limited, in that number crunching on it stinks (since the
string is the only real data type until you hit the assembly level), and it
doesn't have any real networking standards (although each major vendor has
their own nets...). But given those two restrictions, I bet I could blow
the pants off any unix program on equivalent hardwares....
 

Nick Pemberton
 ...utzoo!lsuc!aimed!nick