I agree with Raul's thoughts, and want to add some comments from
actually teaching J in the classroom.
The big hurdle for a professional to learn J is the requirement to think
about things differently. People have learned how to write loops, and
trained themselves so many years writing loops that they have an very
unpleasant feeling of being lost when they have to think of whole nouns
rather than atoms. It reminds them of when they were beginners, and
they don't like it.
It takes an unusual personality to make the effort. Only someone who is
committed to lifetime learning will do it. This is why J will always be
a language for the enlightened.
The kids I start out on J, on the other hand, pick it up naturally.
They feel lost too, but they expect that and they get over it.
First-year J programmers feel less lost than first-year Java
programmers, because they get more done.
We had an interesting incident this year. I was teaching recursion &
decided that I would allow the use of the for. control to allow early
termination of a search. After just 2 weeks of using for., the kids
wanted to use for. for everything, and it took about 2 weeks for them to
stop complaining when I made them use rank instead.
For anyone else teaching J, I have hit upon a good set of homework
assignments. My problem has always been that writing a long program is
so hard for the kids that they don't work on it much at home and try to
spend class time on it where they can work with the other kids. But
this year I have them writing a program to solve the game 'Rush Hour' (a
charming board game). I wrote the program to solve the game and animate
the solution. It's about 45 lines of J. I wrote commentary for each
line. I gave them the commentary without the code. Their job is to
write one line of code a night, given the commentary and the expected
result for the line. Some lines are quick, some take hours, but they
are at last doing the homework because it's the right size: one line.
Henry Rich
On 3/16/2013 11:26 AM, Raul Miller wrote:
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.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
