Learning J language - initial thoughts

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

slocklin
I'll add my voice as a  beginner: I agree with Greg that JforC is a tough slog for a beginner. However, it contains most of the actual information needed to get things done. I find myself returning to it all the time when I don't know how to do something. The others are great as introductions.


Personally, I think the vocabulary is fine. I use the subset I use. Maybe a reduced vocabulary would help for didactics, but the introductory material does fine in teaching some basics.


Here's what would help me a lot: examples which look like things we're used to seeing in other interpreted languages (Matlab or R), with a step by step reduction of them to do things the "J way." I can usually .... very slowly ... parse what is happening in the "Phrases." But, my mind is bent from 20 years of Matlab, C, Fortran, Lisp and R. I think in terms of 3 : 0 with the x's and y's explicitly defined and used. I'm already somewhat productive in that idiom. However, constructing 13 : 0 verbs is something I find difficult. If I can express it as a quote escaped one-liner like stuff=:'verb1 x verb2 y' the interpretor does the tacit conversion for me. But I want to be able to do it myself on non-trivial verbs. There are some examples on the wiki and plenty on the archives of this list, but "the more the better."


As an example from this afternoon: I'm trying to make an add-on which does primitive information theoretic calculations. To do this, you need a discretizer to change the numbers to a reduced set of 'symbols' and the Miller-Madow entropy calculation. I figured I'd look for histograms for the discretizer, and found two  helpful essays by Roger Hui and Brian Schott on how to do this. OK, almost done. I know the right way to do this is with a verb train which looks like the histogram verbs they wrote. How do I change the verbs? Well, there is a decent explanation breaking the histogram verb down in 2009 on this elist. Looking at the atomic form or boxed form of the histogram verb helps too, but if I had a lot more examples which broke down a longish tacit verb train into elementary particles, this would be a lot easier. I *think* I can do this; it will run faster if I do, and I know it will be good for me to do so, but maybe taking the dumb way out with
 explicit and loops is better. It will probably be more easily changed if I need to do equal frequency or some complex thing like the MDL of Fayyad & Irani. Probably though, I'll just discretize by dividing by the range and rounding to convenient ints; because I am lazy. *kicks dirt*


Please don't take this as complaining: I realize I'm basically just saying, "I wish I were better at J." But I think this is the intellectual leap which others would like to make: going from explicit verbs to longer trains like histogram=: <: @ (#/.~) @ (i.@#@[ , I.)
I know it would help me, and I think it would help others.


-Scott
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

Linda Alvord
I, too, had to struggle to figure out your "histogram"


   ]A=:?8$8
2 2 6 5 6 3 4 6
 
   histogram=: <: @ (#/.~) @ (i.@#@[ , I.)
   
   (/:~~.A) histogram A
2 1 1 1 3

I think it must be dyadic and this seems to be how it works.

You might like a frequency distribution which Ric Sherlock wrote:
   
   fdrs=: 13 :'/:~({.,#)/.~y'
   fdrs A
2 2
3 1
4 1
5 1
6 3
     
   fdrs
[: /:~ ({. , #)/.~
   

Linda


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Scott Locklin
Sent: Saturday, March 16, 2013 8:25 PM
To: [hidden email]
Subject: Re: [Jprogramming] Learning J language - initial thoughts

I'll add my voice as a  beginner: I agree with Greg that JforC is a tough
slog for a beginner. However, it contains most of the actual information
needed to get things done. I find myself returning to it all the time when I
don't know how to do something. The others are great as introductions.


Personally, I think the vocabulary is fine. I use the subset I use. Maybe a
reduced vocabulary would help for didactics, but the introductory material
does fine in teaching some basics.


Here's what would help me a lot: examples which look like things we're used
to seeing in other interpreted languages (Matlab or R), with a step by step
reduction of them to do things the "J way." I can usually .... very slowly
... parse what is happening in the "Phrases." But, my mind is bent from 20
years of Matlab, C, Fortran, Lisp and R. I think in terms of 3 : 0 with the
x's and y's explicitly defined and used. I'm already somewhat productive in
that idiom. However, constructing 13 : 0 verbs is something I find
difficult. If I can express it as a quote escaped one-liner like
stuff=:'verb1 x verb2 y' the interpretor does the tacit conversion for me.
But I want to be able to do it myself on non-trivial verbs. There are some
examples on the wiki and plenty on the archives of this list, but "the more
the better."


As an example from this afternoon: I'm trying to make an add-on which does
primitive information theoretic calculations. To do this, you need a
discretizer to change the numbers to a reduced set of 'symbols' and the
Miller-Madow entropy calculation. I figured I'd look for histograms for the
discretizer, and found two  helpful essays by Roger Hui and Brian Schott on
how to do this. OK, almost done. I know the right way to do this is with a
verb train which looks like the histogram verbs they wrote. How do I change
the verbs? Well, there is a decent explanation breaking the histogram verb
down in 2009 on this elist. Looking at the atomic form or boxed form of the
histogram verb helps too, but if I had a lot more examples which broke down
a longish tacit verb train into elementary particles, this would be a lot
easier. I *think* I can do this; it will run faster if I do, and I know it
will be good for me to do so, but maybe taking the dumb way out with
explicit and loops is better. It will probably be more easily changed if I
need to do equal frequency or some complex thing like the MDL of Fayyad &
Irani. Probably though, I'll just discretize by dividing by the range and
rounding to convenient ints; because I am lazy. *kicks dirt*


Please don't take this as complaining: I realize I'm basically just saying,
"I wish I were better at J." But I think this is the intellectual leap which
others would like to make: going from explicit verbs to longer trains like
histogram=: <: @ (#/.~) @ (i.@#@[ , I.) I know it would help me, and I think
it would help others.


-Scott
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

Dan Bron
In reply to this post by slocklin
Hey Scott,

Due to time constraints, I have not been following this thread closely, but
the topic does interest me.

If you post your explicit (that's what we call the 3 : 'x stuff y other
stuff' style of code), I can take a whack at showing you how to translate it
to tacit code (that's what we call the cartoon-characters-cursing style of
code).  

Though at first blush, tacit code can look intimidating and impenetrable,
it's really not such a mystery.  I won't really even have to understand your
domain (information theory) in order to do the translation.

-Dan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Scott Locklin
Sent: Saturday, March 16, 2013 8:25 PM
To: [hidden email]
Subject: Re: [Jprogramming] Learning J language - initial thoughts

I'll add my voice as a  beginner: I agree with Greg that JforC is a tough
slog for a beginner. However, it contains most of the actual information
needed to get things done. I find myself returning to it all the time when I
don't know how to do something. The others are great as introductions.


Personally, I think the vocabulary is fine. I use the subset I use. Maybe a
reduced vocabulary would help for didactics, but the introductory material
does fine in teaching some basics.


Here's what would help me a lot: examples which look like things we're used
to seeing in other interpreted languages (Matlab or R), with a step by step
reduction of them to do things the "J way." I can usually .... very slowly
... parse what is happening in the "Phrases." But, my mind is bent from 20
years of Matlab, C, Fortran, Lisp and R. I think in terms of 3 : 0 with the
x's and y's explicitly defined and used. I'm already somewhat productive in
that idiom. However, constructing 13 : 0 verbs is something I find
difficult. If I can express it as a quote escaped one-liner like
stuff=:'verb1 x verb2 y' the interpretor does the tacit conversion for me.
But I want to be able to do it myself on non-trivial verbs. There are some
examples on the wiki and plenty on the archives of this list, but "the more
the better."


As an example from this afternoon: I'm trying to make an add-on which does
primitive information theoretic calculations. To do this, you need a
discretizer to change the numbers to a reduced set of 'symbols' and the
Miller-Madow entropy calculation. I figured I'd look for histograms for the
discretizer, and found two  helpful essays by Roger Hui and Brian Schott on
how to do this. OK, almost done. I know the right way to do this is with a
verb train which looks like the histogram verbs they wrote. How do I change
the verbs? Well, there is a decent explanation breaking the histogram verb
down in 2009 on this elist. Looking at the atomic form or boxed form of the
histogram verb helps too, but if I had a lot more examples which broke down
a longish tacit verb train into elementary particles, this would be a lot
easier. I *think* I can do this; it will run faster if I do, and I know it
will be good for me to do so, but maybe taking the dumb way out with
explicit and loops is better. It will probably be more easily changed if I
need to do equal frequency or some complex thing like the MDL of Fayyad &
Irani. Probably though, I'll just discretize by dividing by the range and
rounding to convenient ints; because I am lazy. *kicks dirt*


Please don't take this as complaining: I realize I'm basically just saying,
"I wish I were better at J." But I think this is the intellectual leap which
others would like to make: going from explicit verbs to longer trains like
histogram=: <: @ (#/.~) @ (i.@#@[ , I.) I know it would help me, and I think
it would help others.


-Scott
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

Don Guinn-3
Tacit code and explicit code are not exclusive. You can use tacit
expressions within explicit definitions. And these tacit expressions don't
have to be monsters. Short tacit expressions on a line in an explicit
definition can really simplify and make easier writing and reading.

Say you need the the minimum and maximum of a list of numbers.
   range =. (<./,>./)numbers
is simpler than
   range =. (<./numbers),(>./numbers)
as a line in an explicit definition.

Well, maybe not if you're not used to reading forks. But you'd be surprised
how quickly short tacit expressions become easy to see and use whenever
convenient.

On Sun, Mar 17, 2013 at 7:36 AM, Dan Bron <[hidden email]> wrote:

> Hey Scott,
>
> Due to time constraints, I have not been following this thread closely, but
> the topic does interest me.
>
> If you post your explicit (that's what we call the 3 : 'x stuff y other
> stuff' style of code), I can take a whack at showing you how to translate
> it
> to tacit code (that's what we call the cartoon-characters-cursing style of
> code).
>
> Though at first blush, tacit code can look intimidating and impenetrable,
> it's really not such a mystery.  I won't really even have to understand
> your
> domain (information theory) in order to do the translation.
>
> -Dan
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Scott
> Locklin
> Sent: Saturday, March 16, 2013 8:25 PM
> To: [hidden email]
> Subject: Re: [Jprogramming] Learning J language - initial thoughts
>
> I'll add my voice as a  beginner: I agree with Greg that JforC is a tough
> slog for a beginner. However, it contains most of the actual information
> needed to get things done. I find myself returning to it all the time when
> I
> don't know how to do something. The others are great as introductions.
>
>
> Personally, I think the vocabulary is fine. I use the subset I use. Maybe a
> reduced vocabulary would help for didactics, but the introductory material
> does fine in teaching some basics.
>
>
> Here's what would help me a lot: examples which look like things we're used
> to seeing in other interpreted languages (Matlab or R), with a step by step
> reduction of them to do things the "J way." I can usually .... very slowly
> ... parse what is happening in the "Phrases." But, my mind is bent from 20
> years of Matlab, C, Fortran, Lisp and R. I think in terms of 3 : 0 with the
> x's and y's explicitly defined and used. I'm already somewhat productive in
> that idiom. However, constructing 13 : 0 verbs is something I find
> difficult. If I can express it as a quote escaped one-liner like
> stuff=:'verb1 x verb2 y' the interpretor does the tacit conversion for me.
> But I want to be able to do it myself on non-trivial verbs. There are some
> examples on the wiki and plenty on the archives of this list, but "the more
> the better."
>
>
> As an example from this afternoon: I'm trying to make an add-on which does
> primitive information theoretic calculations. To do this, you need a
> discretizer to change the numbers to a reduced set of 'symbols' and the
> Miller-Madow entropy calculation. I figured I'd look for histograms for the
> discretizer, and found two  helpful essays by Roger Hui and Brian Schott on
> how to do this. OK, almost done. I know the right way to do this is with a
> verb train which looks like the histogram verbs they wrote. How do I change
> the verbs? Well, there is a decent explanation breaking the histogram verb
> down in 2009 on this elist. Looking at the atomic form or boxed form of the
> histogram verb helps too, but if I had a lot more examples which broke down
> a longish tacit verb train into elementary particles, this would be a lot
> easier. I *think* I can do this; it will run faster if I do, and I know it
> will be good for me to do so, but maybe taking the dumb way out with
> explicit and loops is better. It will probably be more easily changed if I
> need to do equal frequency or some complex thing like the MDL of Fayyad &
> Irani. Probably though, I'll just discretize by dividing by the range and
> rounding to convenient ints; because I am lazy. *kicks dirt*
>
>
> Please don't take this as complaining: I realize I'm basically just saying,
> "I wish I were better at J." But I think this is the intellectual leap
> which
> others would like to make: going from explicit verbs to longer trains like
> histogram=: <: @ (#/.~) @ (i.@#@[ , I.) I know it would help me, and I
> think
> it would help others.
>
>
> -Scott
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

David Lambert
In reply to this post by Greg Borota

Affirming Greg, "I believe this wikipedia quote conveys a somewhat
distorted and untrue idea"

While it's true that I use matrix divide far more often than "twice and
only because domino is a glorious symbol", recently I've been parsing
some web sites.  At first I tried to implement in python a finite state
machine based on the python html parser to extract information I needed.

Next I tried a j implementation involving heavy use of cut based on
member of interval, variants of (<;.1~ '<tr'&E.@:tolower) PAGE_DATA
I quickly discovered that looking at the data in parallel as j aligns
common elements easily for display made the html source readily
comprehensible leading to less programmer time and solutions robust
against flawed web pages.

> From: Greg Borota <[hidden email]>
> To: [hidden email]
> Subject: Re: [Jprogramming] Learning J language - initial thoughts
> Message-ID:
>         <CADpZFrydhjk-_aJ8=cMXNJXiThdJFGPa7DJhRYz_TztP
> +[hidden email]>
> All the the great feedback helps define better what I, and I think
> many who
> have come in touch with J, were looking for: the general-purpose core
> of
> the language. That is a quite vaguely defined concept, many do
> understand it intuitively though.
> J is "a general purpose programming language" http://www.jsoftware
> .com/help/primer/why_j.htm
>
> I believe this wikipedia quote conveys a somewhat destorted and untrue
> idea
> http://en.wikipedia.org/wiki/J_(programming_language): "J is a very
> terse
> array programming language, and is most suited to mathematical and
> statistical programming, especially when performing operations on
> matrices." There are things that could be done to correct that wrong
> perception. This general-purpose "core" might be one of them.


----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

Greg Borota
In reply to this post by Henry Rich
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Learning J language - initial thoughts

Henry Rich
I took no umbrage at your observation.

The Rush Hour assignment is at

http://www.raleighcharterhs.org/faculty/hhrich/Courses/PSE/Unit%203%20Some%20Small%20Problems/Project%201%20Rush%20Hour.html

The entire list of assignments for the year is at

http://www.raleighcharterhs.org/faculty/hhrich/Courses/PSE/PSE%20Syllabus%202012-2013.html

Henry Rich


On 3/18/2013 11:34 AM, Greg Borota wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
123