On 4/12/06, Roger Hui <[EMAIL PROTECTED]> wrote:
>It is a problem or "persistent irritant" only if you use x y etc.
>as _global names_ from within explicit definition. That is not
>a very good practice regardless of what the interpreter does,
>in my opinion.
>
>And no, I have not seen any good reason to withdraw the change.
(gmail HTML C&P loses the vertical bar denoting message quote)
Sadly, I think Raul Miller's prv comments on this thread, as well as
Roger's here,
both illuminate and miss the point;
I _concur_ with Raul (mainly) but_dsagree_ with Roger here:
1) "One letter nams are reserved for the language" would be a much clearer
one than the ad hoc exception of only two.
But it goes to show what problems adhoc idiosyncratic autocratic change
cause. ALways. In lnguage _re_redefinition.
After all of the threads on tacit prgramming, reserving explicit names
seems to flow contrary to the language path chosen by J.
2) "Not unfortunate, just pervasive with significant debugging for legacy
scripts".
Agreed. But, unfortunate that someghow a pervsive idiosyncratic
autocratic change seems to continue to creep in
from version to re-version that _causes_ such overheads on the J
community.
Sadly, the simple act of defining J[N+1] in J[N] seems to be lost as a
eans to avoid this type of problem for
_legacy_ script maintenance problems. ANd also as a means to aid clearer
and lesser iiosyncratic and less
provncial obsolete colloquialisms from recurring, as this appears to be.
3) Roger's comment seems to speak for itself: a significant thread that in
turn actually does point out tremendous
problem for those engaged in legacy maintenance:
The simple act of self discipline as once outlined by Dr. Grace
Murry Hopper in the concept of
"Desk Checking"
as applied to language development woud avoid this problem for
legacy scriptng:
If J's developers cannot come up with a (J in J) bootstrap
that is error free for each new generation
of thelanguage, perhas J's developers are not bothering to
fully think through the changes they are
contining to impress/force upon the J community.
The second, probably more important, of recidivism of language
"features" creepng (back) into a
language that notoriously (to the uninformed),
warrantedly (to thse in the know about the utility in J), and
to its great utlity and merit, has heretoforenow
[[['hiccup: sorry for the polysyllabic
multiphrasiology, folks;
I been exposed to that lower form of life know as
Liar *spelled with six letters in most Courts]]]
studiously _avoided_ in ts development and growth.
And, as such, appears to be denotative of the trend in J
that I see, hopefully not accurately, and if accurately, hopefully
rectifiable
and soon to be rectified,
a trend away from GOOD idiosyncracy in the language:
that derived form mathematical expertise drawn from the common
corpus of mankind,
english, and the combined expertise of the Jsoftware group and
users community as a whole
and towards BAD idiosyncracy in the language:
that derived fro the personal preferences of the same
personnel without adequate reflection
on whether or not what they in turn find _confortable_ or
_desired_ is in turn of sufficient
mathematical and utilitization merit to warrant such a
change.
especially in the presence of known historically proven methods of language
development and extension
that avoid this type of problem in the main to entirely.
perhaps if a change to J cannot be releaed as a library written in J, this
would indictae it is time
for J a a language to chage in such a way that J itself can in fact do that
with the nex release,
and do so in such a anner that nbot only with all future releases
contemplating changes _of_that_kind_
(which implies sufficient thought and consideration be applied
to new features that _cause_ such a difficulty at all
prior to _including_ one, with the general attributions of
generalization and integration into the wole of the _next_ version
of the language)
so as to avoid causing any of the following kbown "new lnaguage feature"
problems from occurring:
a) prevuous scrpt to fail to run correctly
b) new feature causing old practices to fail in new scripts un under
the new languages
from users who know the _old_ language an "old environment"
invocation in the new version,
c) as well as a "new environment exception monitor" or analyzer to
POINT OUT such fubars as they arise
And they alway will: because:
J is inherently intended (at least under what was originally given by
Dr. Kei) to be
not only a good mathematics notation and environment, but, as well,
a language prototyping and _language_develpment_ environment.
Which it has succeeded in, outstandingly.
If you look at the archives as to the thread sof discussions I have raised
previously,
you will see that this type of analysis is in common with wht I had at times
discussed:
Doing a full historical comparison of trends of how J has developed, and
ho it is or MAY be devleoping.
A language that doe snot do this (self inspect oer its entire history)
will inevitably suffer from the potential for cognitive dirft,
distortion, and loss of clarity and commun-ity
with its user base and potential new users.
Loss of commun-ity from loss of commun-ication;
as well as cognitive drift removig much to most of the utility of the
language by heaping in new factors:
sucvh as the overall size of the languagem, esceptions to simple
rules, the size of the base dictionary, etc.
If the clutter gets too big, perhaps it is time for a systematic attempt to
re-base the entire language.
(which I do not recmmend using the techniques I have WITHOUT doing a
full historial review)
((Please note that this does NOT preclude someone ELSE from coming up
with another
"sea change"
which either re-invents a wheel J had and lost (if any; I am referrig
as well to future changes here
cognitive drift or distortion lose past or curent utility factors now
present in the language;
not Microswift's persistent sage of re-invented relabelled
square whels to sell Microslow gasoline
for Microgonomore cars of the last version of their software
they wish to resell as the NEXT version:
Should J lose too much of earlier utility factors,
users will re0invent them in their own language,
and potentially compete with or drift away from using
J)
or, worse yet, catch Jsoftware with itds pants down, unprpared to see,
analyze, recognize
AND INCORPORATE
the next _real_ sea change that occurs.
Fast. Reliably.
Without causing maintenance problems for previous version users who
wish to use the new engine.
Because, otherwise, you _are_ going to get caught.
And co-opted.
This is why, in the same breath, I keep saying I want to know a smuch as I
can get about the _internal_ state
of the thinking/reasoning/eureka-ing from the language designers that has
lead to earlier version feature changes, as well as
what is going on _now_ (because I respect the previous and currently most of
the current results IN the
language (with exceptions you can see clearly marked from earlier discussion
threads); while at the same time:
I can clearly state I see _personal_ idiosyncracies creeping in that
were not present in earlier versions
were astoudingly outstandingly ABSENT as a _mind_set_ or
frame or worldview or inherent bias
that are now beginning to become more evident over
time.
especially in the areas of the most sterling brilliance of the efforts of
the historical and current developers of the language.
example: loss of the adqate usage of numerical analysis, categoricla
analysis, undefined, and path/entrypont analysis for the reduction or
removal of unrecognized error states in the computation acuracy of J, the
computation acuray of the acual calculation bsed on error domains present in
the _inputs_ to a calculation (direct data, as wll as inhernet language
factors such as errors in the execution domain), and the more subtle ones
that have to be observed and avoided in
the _important_ part of J:
the usage of the language and execution environment to _solve_problems_
in thge human domain,
WITHOUT causing or repeating earlier known cvauses of problem-solution
failure, such as distortion of meaning
induced by metrification failure (non-fixed or improperly based
assignation of metrification (wuantification or qualificaton),
and, more mportantly, piossibly MOST importantly:
the inherent cognitive distortion in the human mind induced by the
failure to recognize and ELIMINATE this
from the reasoning being used and then the NEW reasoning _induced_
(semiotically, via NNP effects) as a result.
Example: straight walls in buildings fall down if certain conditions are
not kept. over time, cognitive distortion (egineers fails to consider
original design limits, or do not apply correct new engineering
midification principles in their plans to moify or simply cvontnbue to use
or maintain an existing structure).
You can avoid this by maintaining the original principles, BUT ONLY if the
mind involved correctly recognizes, analyzes and uses the actual original
principles that were used that ARE still (actually) necessary to keeping the
walls up.
NOT the ones the newer cognitively drifted minds THINK they are using.
Unless these in turn form such a sufficiency set when NOT the samne as the
OriGINAL sufficency set.
You can in turn teachg a new way to build walls (Bucky Fuller's geodesics,
concet rebar, or FIbonacci/Fractal structtures);
but in turn, these _also_ have a known (hopefully) sufficiency set that
inturn can _also_ be lost through cognitive distorition and
drift over time.
THe SAME HAPPENS IN MATHEMATICS AND COMPUTER LANGUAGES.
Just: it happens a durn sight faster.
And, unfortunately, due to the incredible arroganc and complacency presebnt
in the _average_ programmer
(_and_ "new features" languages developer):
almost universally in the new web era.
J is NOT immune to this.
If this forum is the peferred environment for discusio on new language
features in terms of new labnguage development,
great; though the original conversation appears to more accurately be a
_development_ question, and probalby ought to be
carried on there as well.
If the Beta Forum is _not_ the place for discussion about the fevelopment of
the J language itself:
.. then what is the proper forum?
>From the definitions as given, there does not appear to be a single place
that is explcitily defined for that purpose.
In any event, nuf said, repetition all over thr place (read the archives and
_think_ on them for a while).
IMOHO, in summary: gimme back my xy, and stay away from stuff you gave me to
begin with.
'Cuz I WANT it. It's MINE.
...
>
> ----- Original Message -----
> From: "David Vincent-Jones" <[EMAIL PROTECTED]>
> To: "'Beta forum'" <[email protected]>
> Sent: Wednesday, April 12, 2006 3:39 PM
> Subject: RE: [Jbeta] x and y variables
>
> Is it really too late to sway minds away from the "persistent irritant" ?
>
> David
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of J. Patrick Harrington
> Sent: Wednesday, April 12, 2006 3:22 PM
> To: Beta forum
> Subject: RE: [Jbeta] x and y variables
>
> Amen!
>
> I think the replacement of x. by x, etc. is an idea "too clever by
> half".
> It's only broken some of my code in minor ways but will
> be a persistent irritant. x,y,z,u,v,w are the first variable names I tend
> to
> use & now you have to think twice before using them.
>
> Patrick
>
> On Wed, 12 Apr 2006, David Vincent-Jones wrote:
> > Correct Oleg;
> >
> > There are cleaver ways to avoid the problem .. but remember that x and
> > y are probably the most common of all mathematical variable names that
> > are now being boxed into a special significance.
> >
> > The names x., y. et all were special and looked special; fine but
> > eliminating any part of the a through Z series as regular nouns I
> > believe to be unfortunate.
> >
> > David
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
--
Roy A. Crabtree
UNC '76 gaa.lifer#11086
Room 207 Studio Plus
123 East McCullough Drive
Charlotte, NC 28262-3306
336-340-1304 (office/home/cell/vmail)
704-510-0108x7404 (voicemail residence)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.authorsden.com/royacrabtree
http://skyscraper.fortunecity.com/activex/720/resume/full.doc
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse Only
Profits Always Safe Traded
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
