You said:
"You don't like the current fork syntax"
That isn't what I said. It wouldn't be J without the fork syntax. Surely
I wouldn't have bothered stealing "{" and "}" for parentheses if I had
wanted to remove fork syntax.
My comments on the fork syntax - if I had been addressing it - would be:
1) There are circumstances where it isn't the best answer.
2) There are three disconnected and inconsistent environments -
interactive J, explicit J and fork syntax - and I would prefer to have them
integrated.
J appears complex not because it is complex, but because it has been
made complex.
You said:
"so you are proposing a new
one, using symbols that already have a well-established meaning in J
scripts '{' and '}', which is a disruptive change for existing J
experts."
What I am propsing is a syntax that I believe is based upon interactive
J, replaces explicit J and integrates better with fork syntax tacit J
I recognise the disruptiveness, which is why I keep emphasizing that I
am suggesting a separate environment that leaves existing J experts alone.
You don't like the current mappings of symbols to functions, so you
> are proposing a new set of two-character symbols, some of which may be
> obvious to mathematicians, but surely the rest are more or less
> arbitrary abbreviations of convenience.
>
> Your reasons for using two-character symbols were, hmm, less than
> compelling to me:
>
> Different length names being inconsistent?
> Lack of brevity prevents elegance?
>
> I disagree with these specific rationalizations, but perhaps that's
> just me. Mathematic formulae often use different length symbols: ln,
> exp, sin, cosh, sigma, avg, mean, etc.
>
> Most pure mathematical texts go through a sequence of definitions, so
> that the final summary equations are in units of single character
> symbols previously defined. This is easily accomplished in J, without
> needing "standard" two character symbols.
>
> Also, two character abbreviations will, at some point, be ambiguous.
> For instance, "Sq" could mean "Square" or "Square root". Of course, I
> can memorize it, but why is this any different than memorizing '*:' or
> '%:'?
You said:
"The association of '*' and '*:' to multiplication and '%' and '%:' to
division are more useful to me than the non-association that occurs
with character names. I like the feeling that occurs with '%:' and
'*:', one of unification.
I am responding not to what bothers me today, but what bothered me when
I first came across J. That is a valid experience to use as a basis for
recommending change.
I did specifically note that no one would want to replace "*" and "%" -
or in fact any single character primitives. I also emphasized the importance
of making choice available.
I also remember that it took me 15 minutes or less to change from being
very dubious about APL to being eager to enter the house. It was consistent
and elegant. I fully recognise the advantages of J and the difficulties in
working with a limited number of symbols. As I have noted before, if you
want potential buyers to come inside the house to see the wonderful
decoration, the outside of the house needs attention.
>
> On the other hand, I do like having names for certain phrases, because
> it helps with comprehension, later, when I'm re-reading the code.
> Verbs like "each" or "apply", or "select", etc. are J phrases,
> sometimes complex ones, and not just named symbols.
>
> The changes you are proposing would not be J, they would create a
> language more like R, Matlab, or Mathematica.
>
> Why not use those languages and environments? In some ways, R is even
> richer than J in its use of objects and attributes (something I wish J
> could do better, without having to cobble it up myself).
>
> More generally, it appears that you are trying to solve a currently
> intractable problem -- taking a concise, terse language, J, focused on
> mathematics and analysis and replacing it with something slightly less
> concise, slightly less terse, which you have been calling "S" and now,
> "J2", for the purpose of "lowering the barrier to entry" (as marketing
> folks say) and enabling more rapid comprehension of the language in
> order to teach mathematics.
>
> The problem is that using 2-character symbols, and changing basic
> parsing syntax (e.g. '{' and '}' being special and not normal verbs)
> does not produce a significantly easier language to learn, only a
> different one, that, perhaps you find easier.
>
> I would submit that using J to teach mathematics might be made easier
> if the teaching were to follow the standard sequence of most math
> texts. Here's a simple example of a sequence of definitions:
>
> d0 =: 100 NB. initial distance
> d1 =: 200 NB. next distance
> t0 =: 2 NB. initial time
> t1 =: 10 NB. next time
> v0 =: d%t0 NB. initial velocity
> v1 =: d%t1 NB. final velocity
> a =: (v1 - v0)%(t1-t0) NB. acceleration
>
> You can imagine the definitions leading up to the following complex
> equation:
>
> Esv =: ((3*(Rp^3)*(c^6)) % (8*pi*(G^3)*mp*(M^2))^%3)*Enb
>
> The point, IMHO, is that learning mathematics with J is possible
> without changing the language, and students can be brought along
> easily, incrementally, one symbol at a time. It's actually much
> simpler than learning a new alphabet, like cyrillic for Russian, or
> katakana, hiragana, and especially kanji, when learning Japanese. For
> example, これは、日本語です。Это Русский язык.
>
> Learning how to build hooks, forks, and using atop, bond, under, dual,
> and agenda can also be accomplished one lesson at a time. Practice
> makes perfect! повторение матъ ученя!f
>
> I have my own complaints about J, and K, and APL, but I don't think
> the solution to my complaints is to change the syntax of the
> languages. I'll explain my complaints in a separate email.
>
> Good luck with your teaching!
>
> --
> Alan
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
