Hi Henri, My observation about JfC was not meant to be negative. I think it could be understood that way. Just an observation that LJ seems gentler on the beginner - given that JfC is next in line in the help system after the Primer. I thought that indicated difficulty progression, with LJ being more difficult than JfC, which is not the case though. Thank you for making JfC work available, that's next on my reading list!
You seem to indicate you are willing to share your homework assignments. If that's the case, I am interested too. Also do you have an URL that goes with them? To everybody else, thanks for all the pointers. They have all been noted. There is plenty for the beginner here to come up to speeds, just that not everything is captured in the main help pages. After reading all your replies, I have spent more time on the other areas of J site, there are gems all over. Thank you! On Sat, Mar 16, 2013 at 10:49 AM, Henry Rich <[email protected]> wrote: > 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<http://www.jsoftware.com/forums.htm> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
