RE: TV Ad (I'm the man)

A few years ago I wrote an MQ Series based application and used XML to
structure the message 'packet'. The XML tags were created using the 6
character DDS field names. Response time across the network was fine. An
ex-colleague of mine is now at a development site using JAVA. The
developers there are doing much the same thing, except now they're using
the very long and very descriptive JAVA field names as the tag
identifiers.

The thing runs like a 3 legged dog. 

The JAVA developers solution? Get a fatter pipe or a faster cpu, or just
get more resources.
The idea that their use of 40 character field names as tags might be
causing an over head of (2 * 40) + 5 (for the brackets and slash) for a
field which might in fact be 1 character long was not a consideration.

We should remember that a variable name is just a code for a memory
address. It's length has to simply be sufficient to distinguish it from
other codes.

I agree that 6 characters can be a little difficult in a large
development, However the shift to 10 and 14 characters is more than
suffficient. The ability to have very long field names eventually makes
code unreadable (IMHO), especially with poorlu structured free-format
coding.

In order to maximize the 'meaningfulness' of variable names we use a
mnemonics dictionary which provides a 3 character mnemonic for commonly
used terms in our application (which happens to be insurance).
Developers are required to create variable names using combinations of
these mnemonics. This, combined with the PREFIX and QUALIFIED keywords
is more than sufficient to uniquely and meaningfully define variable
names. 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H H Lampert
Sent: Wednesday, 19 October 2005 11:21 AM
To: Midrange Systems Technical Discussion
Subject: Re: TV Ad (I'm the man)


James Rich <james@xxxxxxxxxxx> wrote:

> So what if 10^36 is a large number?  . . .  How many
>sensible english descriptive phrases can be made with 10 
>characters?  Not very many, and that is the problem.  The 
>problem is not running out of unique character 
>combinations, it is running out of sensible descriptive 
>contractions.

Who wants to type a 50-character-long command? We have 
something beyond the wildest dreams of the WinDoze, Mac, 
and Linux world (not to mention the DOS world): 
DESCRIPTIVE TEXT. We can have up to 50 characters, with no 
rules whatsoever, to describe what some QSYS.LIB object 
does.

Over a quarter of a century ago, when I was in high 
school, we had a district-wide student timeshare system. 
Running on multiplexed modems, we had 5 300-Baud lines and 
a 150-Baud line on each of 2 phone lines. The system used 
an obscure OS called MUSIC (McGill University System for 
Interactive Computing), running on an IBM 370/135. It had 
six-character filenames. The first character had to be a 
letter, an @-sign, a $-sign, or a #-sign; the other 5 
could also be digits. And everybody's files, including 
private ones, were in one big common library.

We thought 300 baud was fast. We thought 6-character 
filenames were great, even with the possibility of 
different users' filenames colliding with each other. An 
operating system upgrade eventually got us longer 
filenames and separate private libraries (but still no 
hierarchical directory structure), and we thought that was 
downright incredible.

Then came RT11, RSTS, TRSDOS, CP/M, and PC/DOS, which all 
used 8.3 or 8/3 format filenames, and eventually 
hierarchical directories. And we all thought that was 
great.

Then came the Macintosh. Long filenames. With spaces. 
Fancy that. And of course, WinDoze had to be a copycat on 
that.

I remember a company I worked for back in the late 1980s. 
All the DOS machines were strict command-line boxes. And 
the boss set them all up so that all the common commands 
had one- or two-character synonyms, so that nobody had to 
type an 8-character command.

You want descriptive text to tell what an object is? 
Great! Put it in the descriptive text. That's what it's 
there for!

--
JHHL