[Jprogramming] Learning J language - initial thoughts

[Henry Rich]

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 <borota at gmail.com> 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.
>