I agree with you Don. In my opinion J's "always right to left evaluation" and monadic/dyadic verbs with hook/train forming rules are very flexible which make data transformations and function composition quite easy. But what I'm very unclear about is how does one do pipelining in J? Say we have functions f, g, and h (all used monadically) and it is applied like f@g@h y and function g was particularly costly how can we parallelize (maybe the user has to program it himself or the interpreter can do some cost analysis [like query planning in SQL databases]) it to make it faster? Isn't this what the presenters were mentioning when they were using the example of airbus pipeline system?
Regardless, thanks for taking the time to share your thoughts. On Sat, Sep 26, 2015 at 2:30 PM, Don Guinn <[email protected]> wrote: > One major problem with programming today is that it is too easy to develop > and publish something. We don't take time to really understand what we want > and need. In my first job the computer was behind a locked wall which I > couldn't see behind. I got one test run a day, sometimes two if I was > really fast with keypunch and lucky. So, what did I do while waiting for > the results of my next test run? I studied what I had written looking for > better ways to do it. I got really good at simulating the computer with > pencil and paper. Now testing is so fast and easy one never has to > thoroughly understand the problem. Raul's comment about rewriting once one > understands the problem is most important. But companies don't allow people > to do that. > > > I found their comments about parallel processing most interesting and a > little confusing. They claimed that parallel processing is extremely > difficult. Then they talk about the advantages of asynchronous processing. > Kind of similar, different in geography. I think that parallel processing > is easy, particularly with tools like J has. One trap with parallel > processing is that if one is to do parallel processing is that one has to > run processes in parallel. Instead, identify processes that can run in > parallel, but not to force them to run in parallel. > > > J's constructs for arrays and rank, along with Under, Atop and adverbs like > Insert etc. identify things that can be done in parallel, but don't force > them to be done in parallel. If I write a verb to handle one item and I > pass it many items via rank specification and the underlying hardware can > split the items over many processors, great. If not run them serially. The > important thing is to identify and tell the interpreter, compiler or > whatever if a thing can be done in parallel if it is capable of doing so. > > > That is one reason I prefer to use Atop (@) instead of At (@:) as it tells > the J interpreter that verbs can be pipelined given verb ranks if it > chooses to. OK, in today's implementation of J @. is faster, but maybe that > will change in the future. Vijay, is this what you are looking for? > >> >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
