Hashtable ordering

[Eric Sosman]

What online translator came up with that?

Speaking for myself, I used an offline translator implemented
in aging wetware, and came up with nothing much more sensible. It
looks like some sort of pun on Vergil's famous line (third-year
Latin, Mr. Hersey), but the aforementioned offline translator has
such a low clock rate that I fear I'll never see the joke if I wait
for the iterations to converge. Also, a largish amount of time
has passed since Mr. Hersey last force-loaded the translator's
dictionary, and that region of RAM now more resembles a region
of RUM, riddled with triple-bit errors and worse. Hint, please?

(It was the aforementioned Mr. Hersey who in first-year Latin
tried to allay our fears about a construction called the Passive
Periphrastic. "Don't worry about that word `periphrasis'," he
said, comfortingly, "it's just Greek for `circumlocution.'" He
seemed oddly puzzled when our fears remained undiminished.)

 

[Dave Searles]

What online translator came up with that?

http://www.translation-guide.com/free_online_translators.php?from=Latin&to=English

 

[Dave Searles]

I can't say I know COBOL either. In fact I would generally describe my
background as being close to yours. However, ISAM is not even close to
being a mainframism or a COBOLism, as you put it...it's a term that
someone with a decent level of familiarity with databases (I don't mean
SQL, I mean databases) ought, IMHO, to have at least vaguely heard of.

I worked more at the client-side in the beginning, and my server-side is
more middleware and HTTP stuff than DB. DBs get used behind the scenes,
but I haven't tended to interact with them outside of generating SQL
queries from code.

I didn't write anything that was intended to "get personal". I could
have used a term other than "boutique coder" I figure - perhaps "niche
programmer" is closer to what I meant.

Well, it came off as something of a professional slur.

Think of that as simply being on the other end of the spectrum from
"well rounded" and you'll see that there's no insult meant. I used to
be a "niche programmer" way back when myself.

I don't think I'd characterize myself as such. Perhaps you disagree.

What exactly was the insult? _You_ used the term "practitioners in the
field", and to me that means a software developer, not someone who only
knows one programming language. I based my expectation on that.

The assumption that everyone reading in cljp will know a term that's
been disused for over two decades, when Java is younger than that, still
strikes me as awfully suspect. Especially when it did transpire that at
least one reader indeed didn't recognize it.

 

[John B. Matthews]

[...]

There was also the NCR CRAM. It consisted of a stack of magnetic
cards with rods running through the stack.

Featured here:

<http://www.computerhistory.org/brochures/companies.php
?alpha=m-p&company=com-42bc20992be7c>

Somehow the rods caused one of the cards to fall, and be sucked
around to be read, then replaced on the stack. It has been so long I
have forgotten precisely how it worked.

It looks like the notches represent a binary code. Shifting rods
laterally in the same pattern would release one card. I imagine using a
Gray binary code, or some other single-distance code, would reduce
jamming.

<http://en.wikipedia.org/wiki/Gray_code>

I don't think that would have been practical. When a card was released
from the drum, it always returned to the same end of the deck, so the
deck would be in last use order. The main attraction compared to
magnetic tape was random access to the cards, so last use order was
likely to be different from card number order.

Ah, this makes sense. The manual mentions "gating rods" being closed
during the transition from one binary value to the next.

I am an earwitness to the fact that whatever precautions were taken
against double drops were not totally effective.

My inner mechanical engineer cringes.

 

[Arved Sandstrom]

Speaking for myself, I used an offline translator implemented
in aging wetware, and came up with nothing much more sensible. It
looks like some sort of pun on Vergil's famous line (third-year
Latin, Mr. Hersey), but the aforementioned offline translator has
such a low clock rate that I fear I'll never see the joke if I wait
for the iterations to converge. Also, a largish amount of time
has passed since Mr. Hersey last force-loaded the translator's
dictionary, and that region of RAM now more resembles a region
of RUM, riddled with triple-bit errors and worse. Hint, please?

(It was the aforementioned Mr. Hersey who in first-year Latin
tried to allay our fears about a construction called the Passive
Periphrastic. "Don't worry about that word `periphrasis'," he
said, comfortingly, "it's just Greek for `circumlocution.'" He
seemed oddly puzzled when our fears remained undiminished.)

I used "petro, petronis" as a very loose approximation to "geek". So
"petrones" is the plural accusative. In fact one meaning for it is like
"bumpkin" or "rustic". If anyone knows a better Latin translation for
geek, feel free. I'm thinking now that I might suggest "alienos" (in
the meaning of "outsider") in place of "petrones".

I can see (sort of) why an online translator might take a stab at
"rocky", going off the root of "petrosus, petrosa, petronum". But no
ending for that would be "-es".

AHS

 

[Martin Gregorie]

Roedy Green wrote:
...

The link Martin Gregorie posted,
http://archive.computerhistory.org/resources/text/NCR/ NCR.CRAM.1960.102646240.pdf,
is a brochure that describes how CRAM worked. Page 9 is a detailed view
of the top of a card, with the selection rods.

I viewed CRAM as a magnetic drum with a mechanically swappable surface.

The ICL version had a 'waste gate' - if it found an unreadable card it
ejected it through the gate, horizontally at high speed. They later added
a deflector.

Unfortunately I never saw one of these mechanical monstrosities running.
Were they as loud as I imagined they would be?

 

[Martin Gregorie]

The assumption that everyone reading in cljp will know a term that's
been disused for over two decades, when Java is younger than that, still
strikes me as awfully suspect. Especially when it did transpire that at
least one reader indeed didn't recognize it.

That's a reasonable viewpoint, but it simply doesn't apply to ISAM, which
is very much alive and well today.

Indexed sequential files were complex storage structures in mainframe
days, where for performance reasons the indexes existed at several
levels. In those days a 'disk' file was more like what we'd now call a
'partition'. One of more areas of disk, specified by cylinder and block
range, was allocated and formatted to be storage for an ISAM file. The
indexes existed on several levels:
- each cylinder started with a set of keys, each giving the highest key
value in a block and setting aside a set of 'overflow blocks' where
records that didn't fit into their home block were put
- each area had an index block at its start which have the highest key
in each cylinder
- the first area started with an index block containing the highest
key in each area.

Since then ISAM files have been used on more modern mainframes,
minicomputers (now called servers)and microcomputers (now called PCs and
Macs). ISAM files are the basic keyed storage for COBOL, RPG and PL/I.
Many BASICs can handle them. They are the ONLY files used by 4GLs like
Dbase, Cognos Powerhouse, Sculptor, Delphi, etc, etc. Viewed from this
perspective, its surprising that there's no IndexedSequentialFile class
in Java because they are simple to use, typically quite robust and often
implement record level locking.

The main difference between the mainframe ISAM files and modern versions
is that these implementations use two or three physical file system files
to hold one logical ISAM file - usually the actual records and the index
structure are in separate files and its not uncommon to put a file
descriptor (which lists, names and types fields and says which form the
key).

Oh, yeah, some of the more primitive databases also use them for table
storage too.

 

[Dave Searles]

That's a reasonable viewpoint, but it simply doesn't apply to ISAM, which
is very much alive and well today.

But apparently it does. I, for one, had never heard of it.

Since then ISAM files have been used on more modern mainframes,
minicomputers (now called servers)and microcomputers (now called PCs and
Macs). ISAM files are the basic keyed storage for COBOL, RPG and PL/I.

None of which I've used.

I have used systems that had some concept of a "random access file" with
identical-sized records, something like a poor-man's-database-table. But
they weren't *called* "ISAM"s, even if they may have been ones, or
related constructs. C code indexing into files consisting of repetitions
of an identical packed struct would be another case of "something
similar". Although the dedicated-partition stuff you mention seems to
have a closer descendant in the form of a modern large-scale database
that uses a raw partition and directly implements its own B-tree on this.

The main difference between the mainframe ISAM files and modern versions
is that these implementations use two or three physical file system files
to hold one logical ISAM file - usually the actual records and the index
structure are in separate files and its not uncommon to put a file
descriptor (which lists, names and types fields and says which form the
key).

Oh, yeah, some of the more primitive databases also use them for table
storage too.

There is apparently one other difference: these are all typically called
some other name than "ISAM".

 

[Mike Schilling]

But apparently it does. I, for one, had never heard of it.

Well, if you haven't heard of ISAM. clearly ISAM of no importance.
Unlike the fact that you haven't heard of ISAM, which is worth an
entire thread to itself.

 

[Arved Sandstrom]

I think Martin's point is that you are wrong to assert that the term
ISAM has been disused for two decades. No one is assuming that everyone
knows a term that's been discontinued for two decades. Since your
premise is wrong, your conclusion cannot follow.

The people of whom you complain are probably unconsciously assuming that
most people know a term, familiar to them, for a technology that is
still in widespread use. Furthermore they probably expect that people
that don't know the term will simply look it up, as they would.

IMHO reasonable folk will redouble their efforts both to avoid using
niche jargon and to look up unfamiliar terms without complaint.

Or you use the term in a harmless kind of way. Roedy's original
reference to it was such that even if you never looked "ISAM" up it did
not really affect what he was trying to say.

We all know dickheads that salt their speech and documents with
acronyms, to the point that you spend so much time looking up the
definitions that the use of the acronyms is counterproductive. But
that's not what we're talking about here, as far as I'm concerned.

Let me take another term as an example. These days, in 2009, I guarantee
that over half of Java developers that consider themselves to be at
least somewhat accomplished will not know what CORBA stands for (indeed,
many have never heard of it), and they sure as hell don't know that Java
since 1.2 has had increasingly strong support for using it. If I am
talking to another Java developer who styles himself as being senior,
and the conversation calls for a reference to CORBA, I am not going to
hesitate to use it, even though I know damn well that half the time said
senior developer is going to be hitting Google after we finish talking.

I don't think "ISAM" is quite in that same league - I'll concede that. I
have to grudgingly admit that most Java programmers will never have
heard of it. However, casual reference to the term, as Roedy used it
(and he did use it with sufficient context so that the interpretation of
the post did not depend on understanding the term), should be OK. There
are other contexts, however, where I'd expect a senior Java programmer
who claims certain experience to have at least heard of it.

I'll admit it - I personally may have unrealistic standards. I expect an
intermediate Java programmer to be able to tell me what ACID stands for,
give a somewhat reasonable explanation of big-O notation and where they
would use it, and not get a glazed look in their eyes when you start
discussing PKI concepts. Well, good luck with that...

AHS

 

[Dave Searles]

I think Martin's point is that you are wrong

No. I am not.

The people of whom you complain are probably unconsciously assuming that
most people know a term, familiar to them, for a technology that is
still in widespread use.

The point being that the *term* no longer appears to be in widespread use.

IMHO reasonable folk will redouble their efforts both to avoid using
niche jargon and to look up unfamiliar terms without complaint.

There's an inherent conflict between those two: if, as you say, people
who cut their teeth during a time when a term was common don't
necessarily realize when it no longer is, then it is helpful to remind
them in case they use such a term undefined.

 

[Dave Searles]

I don't think "ISAM" is quite in that same league - I'll concede that. I
have to grudgingly admit that most Java programmers will never have
heard of it. ...

I'll admit it - I personally may have unrealistic standards. I expect an
intermediate Java programmer to be able to tell me what ACID stands for,
give a somewhat reasonable explanation of big-O notation and where they
would use it, and not get a glazed look in their eyes when you start
discussing PKI concepts. Well, good luck with that...

Those ones I know. Atomic, Consistent, Isolated, Durable.
Industrial-strength databases must adhere to all four. Big-O notation is
how the resources (cycles/time, memory, or something) consumed by an
algorithm grow with the problem size. HashMap has O(1) lookup and
mutation; TreeMap O(log N) where N is the size of the collection.
ArrayList has O(n) search for a specific element (O(log n) if sorted and
binary-searched)) and O(n) in-middle insertions, but O(1) appends and
removals at the tail. Deque has O(1) add and remove at both ends.
LinkedList likewise. LinkedList has O(n) retrieval by numerical
position, ArrayList O(1). (So yes, I also know the performance
characteristics of all the common collections, and thus which to use for
a given access pattern.) PKI is public key infrastructure.
Authentication (of people or data objects, via digital signatures; e.g.
signing an email (identifying its author securely) or some code (so
malicious changes can't be snuck in undetected)) and encryption (so an
email can be sent that can't be eavesdropped on, or a VOIP call, though
I'd expect the latter to use PKI just for key exchange for a symmetric
cipher used for the actual streaming audio).

But I didn't know "ISAM". So sue me.

 

[Eric Sosman]

[...]
The people of whom you complain are probably unconsciously assuming
that most people know a term, familiar to them, for a technology that
is still in widespread use.

The point being that the *term* no longer appears to be in widespread use.

Quite right. The Wikipedia page for "ISAM" hasn't been
updated since late July. Anything more than five weeks old
has just *got* to be obsolete.

There's an inherent conflict between those two: if, as you say, people
who cut their teeth during a time when a term was common don't
necessarily realize when it no longer is, then it is helpful to remind
them in case they use such a term undefined.

People who encounter an unfamiliar term and seek to fill in
the gap in their knowledge are to be admired. People who try to
fill the gap by demanding that others fill it for them and who
the reject the advice that GIYF[*] are to be endured. People who
get all shirty and cantankerous at not being spoon-fed with due
deference and adoration are to be avoided. <PLONK>[**]

[*] Another term which has become obsolete (last Wiktionary
update was in early May, more than XVI weeks ago -- given the
antiquity, Roman numerals seem appropriate). And another term
I'm not going to waste time trying to explain to you.

[**] GIYF.

 

[Martin Gregorie]

I have used systems that had some concept of a "random access file" with
identical-sized records, something like a poor-man's-database-table.

Many definitions of 'random access file' don't use a key, just the record
'index' (its position in the file) and are more properly called 'self-
indexed' files. The typical access looks something like:

seek(file, n * reclen); /* n is the record number */
read(file, reclen, buffer);

Is this what you're referring to?

But they weren't *called* "ISAM"s

If you're referring to ba self-indexed file, it can't possibly be called
an ISAM file because it has no meaningful key.

C code indexing into files consisting of repetitions
of an identical packed struct would be another case of "something
similar".

No that's another example of a self-indexed structure - a record has the
index of 5 because its the physical 5th record - the index has no meaning
in the context of the application.

Although the dedicated-partition stuff you mention seems to
have a closer descendant in the form of a modern large-scale database
that uses a raw partition and directly implements its own B-tree on
this.

Some of the earlier databases, e.g. Sybase, used raw partitions for data
storage which may or may not hold indexes as B-trees, hash tables or
whatever.

Many more modern databases simply use a set of files in a directory. No
raw partition needed.

There is apparently one other difference: these are all typically called
some other name than "ISAM".

indexed sequential access method, indexed sequential file, keyed file,
key file are all interchangeable but the first two are the most
descriptive and widely understood terms.

The salient point is that these files exist outside of a database and
that individual records can be accessed randomly via a key value that has
meaning to the user and/or application, the whole file can be read in key
sequence, or that a random access can be followed by reading successor
records in key sequence.

Just because you've never written applications that have this type of
data access requirement (or have always used a database manager for data
access) doesn't mean that keyed sequential files don't exist, just they
you've not heard of them or the generic acronym 'isam'.

 

[Dave Searles]

[...]
The people of whom you complain are probably unconsciously assuming
that most people know a term, familiar to them, for a technology that
is still in widespread use.

The point being that the *term* no longer appears to be in widespread
use.

Quite right.

There's an inherent conflict between those two: if, as you say, people
who cut their teeth during a time when a term was common don't
necessarily realize when it no longer is, then it is helpful to remind
them in case they use such a term undefined.

People who encounter an unfamiliar term and seek to fill in
the gap in their knowledge are to be admired. People who try to
fill the gap by demanding that others fill it for them and who
the reject the advice that GIYF[*] are to be endured.

Here you assume that I demanded that others fill it for me. I did not.
My purpose in posting was to alert Roedy to the fact that the term he
was using was not as widely known as he had likely thought.

I found the tone of your post to be quite rude and inflammatory, by the
way, and have not bothered to quote or respond to much of it as a
result. Please show greater courtesy to others in your future posts.

 

[Dave Searles]

Is this what you're referring to?

it can't possibly be
it has no meaningful key.
No that's another example

I'm not sure I care for your tone, mister.

Some of the earlier databases, e.g. Sybase, used raw partitions for data
storage which may or may not hold indexes as B-trees, hash tables or
whatever.

Many more modern databases simply use a set of files in a directory. No
raw partition needed.

Industrial-strength ones, I'd heard, usually bypass the OS filesystem
for performance reasons.

doesn't mean that keyed sequential files don't exist, just they
you've not heard of them or the generic acronym 'isam'.

I never claimed that they don't exist.

I claimed that the acronym "ISAM" is not in widespread-enough use among
Java programmers that people can safely use it in the Java newsgroup
undefined by assuming that everyone here knows it.

At least one other person agrees with me: Arved Sandstrom, who recently
wrote "I have to grudgingly admit that most Java programmers will never
have heard of it." in reference to "ISAM".

 

[Martin Gregorie]

I'm not sure I care for your tone, mister.

Thats your problem if you read into my answer anything that wasn't
explicit.

In any case kindly answer the question: when you said "I have used
systems that had some concept of a 'random access file' with identical-
sized records, something like a poor-man's-database-table." were you
referring to a self indexed file or to some other type of file using
record keys whose values are meaningful within the application domain.

Industrial-strength ones, I'd heard, usually bypass the OS filesystem
for performance reasons.

Some do, some don't. The more recent implementations either use the
filing system or offer the choice of filing system or raw partition.

I claimed that the acronym "ISAM" is not in widespread-enough use among
Java programmers that people can safely use it in the Java newsgroup
undefined by assuming that everyone here knows it.

Sorry, but that's incorrect. I've just been back through the thread and
nowhere have you qualified your assertion with "widespread-enough use
among Java programmers" until just now.

At least one other person agrees with me: Arved Sandstrom, who recently
wrote "I have to grudgingly admit that most Java programmers will never
have heard of it." in reference to "ISAM".

Arved's qualification is correct insofar as it refers to the subset of
Java programmers with little or no other programming experience.

 

[Dave Searles]

Sorry, but that's incorrect.

No, it is not! We have concrete *proof* in fact that, at least as of a
week or so ago, at least one person here did not know it. And if there
was one there were, and are, very likely to be several more.

Arved's qualification is correct insofar as it refers to the subset of
Java programmers with little or no other programming experience.

Apparently it is correct in a broader context than that. I have quite a
bit of "other programming experience", as I believe I mentioned elsethread.

I find it bothersome that I am being forced on the defensive for a)
reminding someone that they cannot assume that everyone knows what they
know and b) providing some evidence to support some of the things I've said.

There seems to be a distinct politeness vacuum around here; you are not
the only person who has responded to my quite-reasonable posts with
attempts to publicly suggest that I'm some sort of amateur or not
"well-rounded" or something of the sort. As far as I am concerned, such
comments, however indirect, constitute off-topic and uncalled-for
personal attacks. There is no need for judgmental attitudes here that I
can see. Please -- you and the two or three others that have displayed
similar behavior -- leave the "I'm superior" attitudes at home when you
come here to discuss Java. Bringing them along is counterproductive.

 

[Dave Searles]

No offense to the participants.. but is this really important enough to
dedicate a whole thread too.

No. That doesn't stop some people for turning a formerly useful thread
about Java's hash-dictionary classes into a platform for one-upmanship,
put-downs of others, and similar childish games, though, unfortunately.
(What do they think this is, anyway, an alt group?)

 

[Mike Schilling]

There seems to be a distinct politeness vacuum around here; you are
not the only person who has responded to my quite-reasonable posts
with
attempts to publicly suggest that I'm some sort of amateur or not
"well-rounded" or something of the sort. As far as I am concerned,
such comments, however indirect, constitute off-topic and
uncalled-for
personal attacks. There is no need for judgmental attitudes here
that
I can see. Please -- you and the two or three others that have
displayed
similar behavior -- leave the "I'm superior" attitudes at home when
you come here to discuss Java. Bringing them along is
counterproductive.

It's not your ignorance that's being criticized; I'm sure there are
many important topics I know little or nothing about. What's being
objected to your claim of effective omniscience: that anything you
don't know is ipso facto unworthy of mention.