Tracy Harms wrote:
> Everybody who is interested in promoting the use of J is
> interested in making J code more approachable to those who
> find it hard. At the same time, there is usually the intent
> to retain and employ the most remarkable features of J.
> These purposes do not mesh easily.
Bravo. This was a great post.
Yours was the best response I've seen to this question. It presented the
important facets of problem and addressed them
dispassionately but not impersonally *.
> those who show eagerness to make changes to the language
> inadvertently impede their own progress toward understanding
> what is already before us.
If this were a crime, I'd swing from the gallows (is it impolitic to say I'm
glad I'd have company)?
> I am personally disinclined to attempt thinking up improvements over J,
> at least until I have a strong grasp of what J actually is.
I have also reached this conclusion. I still have the urge, but I try to not
indulge it publically.
And, like many reformed sinners, I'm now evangelical on the subject. Which is
why I was so impressed by your post and its
diplomacy.
Addressing a couple of specific issues:
> Relying on naming to increase readability is important for programming in
> general,
One of the foundational design goals of J was (human) language independence.
Ken (and Roger?) explicitly attempted to divorce J
from English. For example, at
http://www.jsoftware.com/help/dictionary/dx009.htm#8 we read:
9!:9 y Error Messages. e.g. replace English messages (default) by
French.
Of course, in practice, this goal is somewhat confounded **. But that doesn't
mean we should just give up and start a priori
biasing the language towards English speakers.
English is only intuitive for people who don't remember learning it.
> to which J provides no exception.
Put another way: J does not provide an exception, but it does provide an
alternative.
> Any verb train may be put into either monadic or dyadic contexts, and
> figuring
> out what sort of verb train you have in hand does nothing to resolve valence.
I agree, and draw an analogy to polymorphism in OOP.
In a polymorphic OOPL, you can't know what foo(x, y, z) will do unless you
know all the definitions of foo() , how they
depend on the number and type of their formal parameters, and the types of your
actual x y z . But you can be pretty sure
(though not certain) that most foo() will be related. Similarly for valence
in J *** ,
-Dan
* Is there a good word for this? Journalistically?
** For example, the canonical Dictionary is in English (though translations
exist), the largest community of J users communicate
in English (AFAIK), the vast majority of supporting documentation is in
English, and, not least, J's grammar (or at least the
words it uses to describe its grammar) is adopted from English. See
http://portal.acm.org/citation.cfm?id=384283.801077 .
*** Perhaps a better analogy is operator overloading? In, e.g., java, int +
int has very different results from string+string
. Or, an even stricter analogy might be monadic:dyadic :: unary:binary .
For example, think of 10-4 vs -4 in C.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
