Dear Larry,

Thank you for your contribution.

I've seen that one in so many newbie tomes about email etiquette, that were 
written on a first to (new small, alternative) market, by newbie to the net 
journalists, and originally for decades in internet news groups that were 
appropriately for the Phds. who predominated then to give us the net itself.

Well, who's impressed with what?  Wasn't it you who typed "Phd.".

You have impressed me, some.

Everybody's a critic.

I was responded to in public, rather than private, as again here, and in a 
subtleness missed by many,  am responding (again) in (un)kind to demonstrate 
it's effects: your "public" correspondance (sic), and now my response in 
(un)kind, rather than traditional "offline" personalized reply email 
traditions.  I went to college.  I (like your and my retorts here have) took 
up space.

Now it's traditional for me to feel I'm supposed to answer back things like:

"If you don't like what you see, go see something else.  Don't whine.  Don't 
impose your personality on others.  And always criticize in private.  Don't 
intimidate those who seldom contribute into contributing more seldom, if 
never.  I bet those guys know things we don't know but could sure use, even 
if they are only confirmations and afirmations, or exactly the opposite, that 
can broaden the perspective of the subjects at hand for some of us.  If they 
speak to the forum's theme, in any real way or part, I hope to get the chance 
to see what they have to say." 

but I just don't have the time to take a shot at you; to return a volley of 
fire.

OK, lets play for just a moment.

Rodney King, after taking "the greatest ass whoopin of all time", bounced 
back from his feelings and said "Couldn't we all just get along".

Let's play nice together kids.

This isn't technical writing here.  It's only email.  A "forum" for'em.  "We 
have met the enemy, and he is us" (POGO).  "Yeah, and we're beating him back, 
Sir" (ANON).

Personalized expository submissions that attempt to use same to stimulate not 
only thought, but what is too rarely achieved in "dry" forums; memory that 
inspires action and change by larger numbers of people, from larger audience 
participation (short of the Jerry Springer effect, we pray, ... some of us) 
are what's sought and expected here, IMHO.  That's what we were "chided" to 
do by the creators of this forum, when it was first created, and again when 
it was revitalized.

e.g.

Just postings of things like new cool URLs that fit recent threads herein 
takes a lot of my time (to go and see, lest I miss out) that could be saved 
by reading nice short reports/revues of their content that is more 
"sufficient", as reported, to facilitate my just appending these emails to an 
archive file for keyword searching, to then find those URLs in useful 
context, on demand.  I greatly appreciate such URL notification and posting, 
but many are soooooooo terse (yet so valuable, in so many cases, so many 
ways).  To those that did "revue" for us, many thanks, for saving so many 
minutes in the present and the potential to save so many in the future, when 
I remember one of your phrases and use it to locate the source you cared 
enough to apprise us of.  I won't be appraising creative writing skils tho 
(sic),.  That's bottom-feeding by those who truely are self impressed.  I 
understand typos and keystroe errors that look like misspellings being left 
in so contributors can find brief of moments to share w/us, (not too) poorly 
formed or punctuated sentences, and run-ons that are actually stream of 
thought w/no time to seperate.  Fortunately, I type well enough that my doing 
all those is usually mistaken as colloquial prose (which it will 
unfortunately soon be, I fear).

Is this a forum or an e-bibliography (a running library card).  This is new 
millennium EDI/XML/e-biz stuff.  Our pocket protector is now our e-holster.  
Draw (compose), pardon-ne'r.

Consult the primal emails that started this forum.  I read many the day 
published and remember many well, and abide the encouraging requests.  Mostly 
bc. those encouragement's (pronounced "incur rage mants,  but not meaning 
anything like that) were so "wisely" crafted and have now been so successful.

My self discipline to immediately follow each "chide" to try something by 
giving my own real world example may too often be seen as something else, by 
others with different motivation than what mine really is.  When I can't be 
clear enough to chide clearly bc. the narration is growing enough already, I 
skip straight to my example's methods.  I write what I'm attempting to 
describe to my target portion of the total audience.  I avoid writing to the 
Phds. in the manner they publish in front of the other Phds..  That's for the 
journals.  This isn't such a forum, nor am I trying to describe chopped liver.

Sorry! Thank you very much,

Jim Cunningham

P.S.

Yeah. Soooo?

My goal therefrom is unabashedly selfish: to ---->vigorously<---- promote the 
drastic reduction of source code by the very drastic reduction of all the 
"asides" and distractions of definitions, initializations, validations, tests 
etc.  The same old keystrokes that have been typed too many times, just 
because the names were changed to protect the income, and make "hand 
compiling" or "divining the pith of the program" so distracting and tedious 
from so many "side-trips", despite the necessity of their function.  The 
power of not only a data-dictionary but of multiple normalized 
data-dictionary relational records or "appendations of function" to/within 
such data dictionary tools seems rarely implemented and thus underutilized, 
if not substantially not understood.  Thus I feel compelled to make an 
attempt to contribute (but let's not tell them about "the power of Progress"? 
 Yeah, they're gonna find out anyway).  Finish crafting the tools, I say.

Thus, having successfully "removed" all that to the dB, prepending 
nomalization's keys to trivialize auto-reinsertion to source-code "streams" 
via dB record driven pre-preprocessor(s), "pattern hatching" of the remainder 
becomes much easier and much more clear.  Then I strive to move actual source 
code (patterns), first  to callable files organized in directory trees of 
"names" that announce function, then to template files and subsequently to dB 
records of normalized pattern elements.  The tokens left in the smaller 
compact modules of source code, when wisely "tokenized" themselves with names 
chosen in appropriate vernaculars (and these "facets" especially, can further 
be reduced to tokens for overlayment from dB records, for very useful 
translations/vernaculars/points-of-view, documentations and 
internationalizations and such) can be further exploited.  It's simply a 
matter of taking all of such work and encapsulating all the code I 
"keystroked" to achieve all this into tokenized preprocessors, moving any and 
everything "specific" to a particular invocation of such work to generalized 
dB records, which I then normalize and make "populable" for the specifics of 
the next times I want to do such things on other things.  Patterns seem then 
to "pop out" at me, as I realize I never need to stroke the keys in that 
particular pattern ever again, if I "press on".  Then I write a driver to use 
from now on to interview me for the current specifics so IT, calling a 
cascade of preprocessing,  now populates additional dB record sets to feed 
another preprocessor to overlay templates (constructed/generated from the 
other dB record sets by preprocessing) to then generate the new source code 
suite (which turns out to be not so "new" overall), truly in microseconds.  
There can be so little code left in the source code, quite reasonable data 
constructs to get all the rest into the dB become obvious, IMHO.  

Since, not only can every program be reduced to combinations of the three 
simple constructs of loop, assignment and comparison, let's not forget they 
themselves are constructs and can be further reduced to "lists" containing 
only the token 0 or 1 (since that's all each of the transistors can manage), 
if laid out in the appropriate patterns (of patterns).  The nomenclatures of 
the new languages, IMHO, run in the opposite direction.  It's time to work at 
higher levels, not great long executable statements with soooo many 
keystrokes; so much reaching for the punctuation and shift keys with the 
weakest, least coordinated and shortest fingers (can't we quit QWERTing).  I 
typically ran my prototype documentation generator in multiple passes "by 
hand" over the source code, creating, by editing, multiple sets of various 
useful "manifestations" of same, but particularly enjoyed producing English 
documentation, in outline form, that compiled "directly", by that form being 
pipelined through a short cascade of preprocessing reconstitution.  Getting 
such to work in reverse is more work at first but you quickly get connected 
to seeing everything the other way round and it quickly feels familiar. Then 
that tool set is then quite useful for many things; not just translators, but 
translator generation in a nicely general, clear, seriously self documenting, 
easily maintainable system.  Thus, "single click regeneration" from updated 
structure records melded with the particular data of the particular 
instance/project/package seems an attractive alternative to traditional 
version control techniques.
 
Long about now, could EDI/XML aficionados help move us all forward to higher 
level data structures, higher methods of organizing and ordering them, 
opportunities of reuse, (spoken/written) language independence, etc?  e.g. if 
you've done the work in English, why not have the work, done in a/all other 
languages, be available, "a keystroke away"?  It's not their job; not so much 
as our friends at XML-PERL-DOM; tho that forum is ""hooked" on PERL" (but you 
go guys! GREAT work!).  I was attempting to empower the office clerks of the 
world (many sans diplomas at many levels, yet intelligent nevertheless) who 
had for so many decades excelled at paper form creation (pencil and ruler > 
copy mach.), organization, implementation and utilization of work, yet lost 
so many of their number from the writing of programs, and give them back the 
utility they had provided.  They lived and worked among those who actually 
did the work of industry.  They knew the "real" names of "things" in their 
contexts.  A potential loss in the numbers of programmers, having to give 
those jobs back, is likely.  But I predict global business will insist.  Why 
spend scarce hard currency of third world countries on their people learning 
to keep current on the newest fad programming languages when those languages 
themselves can be completely obviated, when implemented as well as we can and 
should.

I think that with things like multiple dBs of EDI, XML, records about their 
structure etc. and auto-generated browsers triggered by record updates, and 
auto-regenerated generators, why do we keep stroke-in (sic) our boards?  We 
ought to be (strictly) dragging, dropping and clicking.  That's what I 
envisioned many years ago and delivered at the prototype level.  But why do 
most developers of program development workbenches/suites, themselves, still 
use the keyboard?  They didn't finish the work for their own benefit (double 
entant? I'll never tell).  The cobblers children go shoeless.

That all this should then be "interfaced" with voice recognition and speech 
synthesis (simply pipelined) so the computer would simply interview the 
worker who needed something, so as to then immediately provide it, did not 
escape me, (many) years ago, as those technologies were around back then and 
reporting some very good work.  We just had to wait for R&D cost recovery, 
part count reduction, programmed ASIC production lines, surface mount 
technology, and accumulation of heat sink data by trial and error (so few 
graduated engineers actually did well enough at heat transfer differential 
equations for sufficiently accurate/usable modelling/predicting, until 
programmable automatons for same became widely distributed, so as to break 
the gigahertz and "real estate" barriers long ago), not to mention marketing 
channel/distribution-rights conflict resolution, etc.

I have a question.

Why aren't we there yet?

Or better yet:

Why are we still just here?

Are the continuously repeated tediums of nonautomated code production, and 
especially nonautomated production of the underlying code production 
productions, holding us all back?  Do those who sponsor/pay_for (I'll try to  
even work in camel notation, to inspire the readers to take note of how much 
is actually available to pursue clarity in nomenclaturizations) our work 
continue to be double and triple billed (at a minimum)?

Why do we "hatch" patterns, instead of the other way round, generating them 
with the purpose of reuse, selecting/clicking/speaking them and 
ordering/dropping/speaking them?  Because we're not doing same on the things 
they are made out of?  Shoeless AND clueless?  Barefoot and loving it?  Does 
the emperor have such a small wardrobe?  Why isn't the computer asking to 
interview us to provide us with more and more empowerment?

"Generated code is usually unoptimized" is a misstatement of the problem.  
That's the compiler's job!  The compiler writers job, specifically.  So let's 
get the EDI and XML specs. done as well as they need them.  But then we 
really should take those raw languages away from any but the compiler 
writers, and their compilers should translate optimized code into much more 
readable and still compilable form.  Give me my own version of same, with 
much renaming of most things, transposition of punctuations and nomenclature, 
in English outline form.  And I don't want to do any more work than scrolling 
and clicking.  They should move as much of the source out of itself and into 
something like generated "CORBA tables",  to reincorporate in not only 
reconstituted source code, but time-linked/up-to-date "help"/documentation 
(these should never be separate "things")

Things self-referential are only ambiguous. They are seldom intractable over 
long enough periods of thinking about them in search of clarity of thought 
about them.  Certainly none of  the ones we consider here are intractable.  
They often yield to parallel thinking.  We can walk and chew gum at the same 
time w/o either of a trip and fall incident or foot in mouth event, pretty 
much w/o breaking a sweat.  And, after all, we have forums for'em, too.  And 
journals.


P.P.S.

If you can't remember it, forget it.


------   XML/edi Group Discussion List   ------
Homepage =  http://www.XMLedi-Group.org

Unsubscribe =  send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank

Questions/requests:  [EMAIL PROTECTED]

To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm


Reply via email to