On Sat, Mar 16, 2013 at 10:29 AM, Greg Borota <[email protected]> wrote:
We have a huge army of developers who are used to approach learning a new
language in the way established by Brian W. Kernighan/Dennis M. Ritchie.
Basically just plunge the user in the language and have them writing
programs right from the beginning. Now J is different, that approach
might
not work quite the same. Yet because so many of us don't know better
I believe we need this kind of help.
I had a similar problem when I first learned C.
There, my problems turned out to have to do with understanding how to
refer to the C compiler.
Nowadays, I can go:
$ cat >hello.c <<end
#include <stdio.h>
main(){printf("hello\n");}
end
$ make hello && ./hello
... and understand what I am doing. I know that the '$' is the prompt
so I would not type that part in. I know that the compiler will emit
dire messages that I will ignore. I know that make will do what I
want here unless I have a makefile in this directory which tells it
otherwise. I know that 'end' is a directive to the shell which is not
actually a part of the program (and that normally I'd not use <<end
and instead just use ^D ... no, actually, normally I'd use a text
editor instead of cat - these are compromises I've made for clarity of
presentation in email).
And, yes, that kind of thing you do solve just by jumping in and
seeing what breaks.
But, for example, most people that I have interacted with do not use
make to compile programs like this. (Why? Is that a deficiency in the
way K&R taught C?) Similarly, people have all sorts of different ideas
about how to author C programs - and mostly that does not matter,
because mostly we ignore them.
J currently has a "higher bar to entry" than C, I think, because J
overconstrains execution - if you do a literal transcription of C to J
you will get something that works but is too slow to bother with. If
you do not learn how to simplify your code, in J, you might as well
not bother because other languages will do a better job.
I have very mixed feelings about this.
Hypothetically speaking, there's no reason we could not have a J
compiler that emits programs for use at the unix command line. J
already includes a variety of transformations on code as well as links
out into the OS, and gcc includes a rich and accessible infrastructure
for building programs. And, now that J's source is available under
the GPL there are no licensing restrictions preventing a mix of J and
gcc - we could emit RTL directly if we had the energy to do so, and
hand any part of the resulting system to anyone. We could use
something analogous to Hindley-Milner type inference (except instead
of finding the largest containing type, often we would want to find
the smallest acceptable type) and J's existing structure would mostly
just work as is. But removing this bottleneck would bring us other
issues and problems. Already people avoid useful J constructs for a
variety of reasons and this problem could easily get "worse". [Plus,
of course, it takes time and energy to write a compiler.] Anyways,
there's a lot of potential noise off in this direction, and it seems
fun but it would get complicated.
Anyways...
J is "different" but not all of the problems are in the documentation.
Some of the problems are in the implementation, some of the problems
are in other programming languages, some of the problems are in math
curriculum.
Consider, for example:
1 2 3 * 2 3 4
2 6 12
In many other languages, that would be a loop (SQL is an exception but
is clumsy enough that you can't quite do this this way).
But if you have had any higher math, you have probably been taught to
expect an answer of 20 here. And, that's bad. (scalar product is a
monoid, inner product is not*. We should not use the same symbol for
scalar product as we use for inner product because it's misleading and
it encourages the reader to jump to false conclusions.) But the
problem here hides under the flag of "standard math notation". So how
do we deal with this issue? Do we go on a discursive tangent
addressing all of the potential bad assumption because of the notation
a person might have been exposed to? It seems to me that that's just
unnecessary noise for anyone not caught up in those kinds of problems.
But that does not mean that the problems are not real.
*Of course, matrix products can be monoids but a "2 by 2 identity
matrix" "multiplied by" a 3 by 3 matrix is not an identity so that
still introduces complexities.
J's
1 * 2 3 4
2 3 4
is a beautiful thing, but it's also boring if you don't understand the
context that makes it beautiful. Why should anyone care?
And... similarly... people may be put off by the use of whitespace as
a prompt - they have learned how to cope with prompts that need to be
removed to understand the code, and J's approach is just "wrong" for
"reasons" which are difficult to express.
Do you see where I am going here?
Some of J's problems are that we have not learned how to recognize
things issus that are probably rooted in bogus assumptions. And that
can be a real difficulty, sometimes, for some people.
Anyways, Ken Iverson's approach here was to be presenting some other
topic which had some intrinsic merit. The math, after all, is just a
notation used for conveying ideas. It's the ideas that make it
interesting. I think we need more documentation like Ken Iverson would
have written.
Having an interesting subject gives you something to think about and
helps you focus on ideas which are relevant to your interests.
------------------------------**------------------------------**
