Re: Another idea from pick goes mainstream...


Albert D. Kallal wrote:
Having been around pick a long time, each year that passes, some neat-o
technologies that comes out tends to be something that pick had for 30+
years.

Hmmm. I don't think that this is a very correct statement Albert, as
much as I migh tlike to belive it and as much as "not very correct" is
probably fuzzy logic ;-)


I can remember when UNIX folks talked about how neat the new "demand" paged
operating systems were. Of course, pick was like that from day one.
(totally virtual memory)

The UNIX concept of demand paged memory was only vaguely related to the
very simplistic virtual memory concet contained within Pick and
developed only a little to cover larger memory configurations. UNIX did
have other ways of doing such things before the advent of demand paged
memory, and this was an advance in the alogorithms that furhter begat
predictive paging and so on. Pick was not the first system to use paged
memory by any means - it probably was the first to implement the idea
of frames in such a manner - but I would not even be so sure of that.

Hence both Pick and UNIX had ways to use virutal memory, and UNIX was
developed and advanced and Pick was not. UNIX demand paged memory was
not stolen from Pick and I cannot agree that it was the same idea
developed independantly as the algorithms involved are very, if not
compeltely, different.


I can remember in the early 90's how big of a deal was variable length
fields for a database - this would save lots of disk space when it cost lots
back then!! .....again, pick had that from day one!!

Well, again, be careful, because varaible length records were not new
to Pick particularly. It is possible that Pick was a very early
implementation of such concepts. The intent of other databases was to
implement the relational model in a commercially succesful way, not to
think about storage per se. A relational database has nothing to do
with physical storage (nor SQL really) and variable length records are
more of an application programming convenience than anything else.
Handling such things lower down starts to make things less efficient
rather than more efficient (other than storage, potentially, but few
care about that these days).


I can remember all the hype about how Java is a p-code system with a
runtime. Makes it easer to port the system to different processors. Of
course we all know that a LARGE number of vendors used to exist for pick
systems..an they ran on every concavely conceivable of the day. (And, so is
the new .net stuff). Again, pick was a p-code based system. p-code
architectures are in vogue today...and we had that since day one (java and
.net are both these types of systems).

Again, the Pick operating system did not engender the idea of an
interpreted P code system. In fact, if you are referring to the way
BASIC works, it was not until quite a bit later that such a thing
turned up. Before that you had PROC, which was purely interpretted
text, which certainly was not interpretted, and a few other things that
are lost to the mists of time for most. I suspect that Ken used a pcode
for Pick BASIC because it was the easiest way to fit it in; I also
prefer to think that he wrote it so he could write Star Trek for Pick,
though he denied it. I also think that the birdmen are coming... ;-)

The Java pCode engine is touted too much of course. If it was any good,
then you would not need a JIT to make it perform (after it has used
38MB of memory to load the pcode that is). It is well organized and
sensible for easy porting, but it is organized in a way that makes it
difficult to perform. A JIT compiler can still be a good idea, but it
is sad if you MUST have it for performance.


Then, XML came out. This hot new idea was a delimited string that could
represent a whole invoice. You think this was the hottest new idea on the
planet....again, pick has this delimited string concept from day one......

Well, again, XML can easilly model the delimited strings of Pick, but
Pick cannot easilly model the things that XML can. While XML has been
hijacked in to all sorts of uses that it should not be used for, and
has expanded quadratically in complexity such that you need 72 external
libraries to be able to deal with all the possible things that are now
"XML".

At the end of the day though, the fact that XML can easily model a Pick
delimited record is just coincidence, as XML, even in its original
formulation contains much that PIck does not.


Then there is multi-valued fields....The new version of ms-access has
multi-valued fields..(here is a video..and multi-value fields are
mentioned).

http://www.microsoft.com/office/preview/programs/access/demo.mspx

The term multi-valued is unfortunate, but only for Pick and MUMPS.
Multidimensional means something else here.


Funny, each time some vendor points out how some new great feature is in the
marketplace, It seems it always came from pick!!

Though it is tempting to believe that, I am not able to agree with it
very much. There are a few common concepts that almost certainly
evolved independantly, but at the end of the day, a realational
database has few things in common with the Pick/MV model and the
technolgies developed to go with the relational model did not have MV
models as their basis.


Somehow, I feel opportunities where missed along the way by mv vendors....

It is certainly true that more could have been and still could be done.
I personally believe that I am working at a company, in Intersystems,
that sees that very clearly. In fact, a lot of the work I am doing is
to enable MV to catch up with the technology integrations within Cache.
I hope I managed to say that without too much advertising being
involved!

Jim

.

Loading