I don’t know, I was inspired by Guy’s ambition to actually try to *solve the problem* (of accepting that we live now, and for the foreseeable future, in a world of highly parallel computing, and we need to develop tools that make living in that world easier).
Ken made a huge leap forward in the 60s, 70s, and 80s in designing notations which separate the “what” from the “how”, which is a big handicap that holds back a lot of languages from automating or optimizing parallel execution. (Not that I blame them, a lot of our current languages retain the phenotype and “junk DNA” of FORTRAN and other 1st generation languages where even *having* a high-level programming language was a novelty and a huge productivity boost.) But we, as a community (both APL and J, but particularly J), have not really made a priority, or even any meaningful contributions, in realizing that advantage. We have the opportunity but we’ve never really bothered to seize it. Even today, in 2016, it’s not possible to spawn a new thread in J, not even manually, without leaving the language proper. Forget about high-level and productive frameworks for farming out work and collecting results from a heterogeneous cluster of compute nodes. To be clear: I am as guilty as anyone else for this lack of progress. So, I’d actually like to see more advocacy like Guy’s. It’s time for the next generation of programming languages, which take as an assumption a distributed computing model. -Dan PS: Dyalog does permit automatic threading, but that’s still a ways off from the modern map/reduce distribution of work that’s really important today. > On Feb 18, 2016, at 2:31 PM, Raul Miller <[email protected]> wrote: > > Yeah, it's actually kind of depressing that google engineers probably > being paid over $200k/year struggle to understand this kind of stuff. > > -- > Raul > > > On Thu, Feb 18, 2016 at 1:52 PM, Don Guinn <[email protected]> wrote: >> Guy's four solutions for the water problem really bothered me. Why does he >> make this sound so difficult? So I wrote a J definition for water: >> >> water =: +/ @: -~ >./\ <. >./\. >> water 2 6 3 5 2 8 1 4 2 2 5 3 5 7 4 1 >> 35 >> >> It is identical to his first serial solution except all "how to" (loops) >> are removed (left for the J interpreter to do as it sees best). I noticed >> that his fourth solution is the same as his first serial solution, >> rewriting it removing the "how to's", leaving that to library routines. The >> solution in J is also ready for parallel processing. It just so happens >> that the J interpreter does not support that right now. >> >> I can see that it would not be difficult for the J interpreter to use the >> tree approach to parallelizing the scans and summation to incorporate >> parallel computing. Or one of several other methods. And the definition of >> water is untouched. >> >> Watching the video a second time it amazed me to see people still >> struggling with and recreating concepts that Ken Iverson and others so >> clearly defined and exploited long ago. >> >> On Tue, Feb 16, 2016 at 5:33 AM, Raul Miller <[email protected]> wrote: >> >>> On Tue, Feb 16, 2016 at 2:21 AM, Roger Hui <[email protected]> >>> wrote: >>>>> He presents a loop to compute +/1+i.1e6 using a loop and then >>>>> introduces some concerns. But, of course, the efficient implementation >>>>> of that algorithm here would be -:@(*>:) 1e6 or perhaps 0 0.5 0.5 p. 1e6 >>>> >>>> 2!1+1e6 >>> >>> Nicer. >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>>> On Mon, Feb 15, 2016 at 11:09 PM, Raul Miller <[email protected]> >>> wrote: >>>> >>>>> Hmm.... >>>>> >>>>> I think Guy Steele is being sort of relevant, in his Growing a >>>>> Language paper, but I think he's definitely oversimplifying also. >>>>> >>>>> Let's consider his first example involving "noun that names one thing". >>>>> >>>>> First off, note that he does not actually include any information >>>>> about how to distinguish between nouns that get 's' and nouns that get >>>>> 'es' when made plural. So if we take some example nouns, like 'city', >>>>> 'leaf', 'life', 'man' or 'geese' we do not know which of those rules >>>>> to apply to any of them. >>>>> >>>>> Second off, let's consider his next example of "numbers with no >>>>> bound". From experience, we know that if we want to have a lot of >>>>> numbers we're going to have to put some bound on them, or things crawl >>>>> to a stop. In J, that's the difference between 10^100 and 10^100x. >>>>> >>>>> Anyways, to make a long story short, I think there's a lot more to the >>>>> suitability of a language than its size. There's always going to be >>>>> limitations, and there's more to the usefulness of a language than the >>>>> size of the vocabulary it provides. >>>>> >>>>> That said, I think I understand some of his frustrations. >>>>> >>>>> But let's jump to his youtube talk about parallelization. >>>>> >>>>> He presents a loop to compute +/1+i.1e6 using a loop and then >>>>> introduces some concerns. But, of course, the efficient implementation >>>>> of that algorithm here would be -:@(*>:) 1e6 or perhaps 0 0.5 0.5 p. >>>>> 1e6 >>>>> >>>>> This is a general problem with a lot of "computer science" - we've got >>>>> solutions looking for problems, and we rather lazily go for the wrong >>>>> solution all too often. Brute force works (by "brute force" here, I >>>>> mean: acting without attempting to understand further), and is often >>>>> enough the best choice. But that does not mean we couldn't do a lot >>>>> better, and sometimes that's the best choice (like, for example, when >>>>> brute force isn't working). If it's stupid and it works, it's not >>>>> stupid. >>>>> >>>>> Anyways, playing with this kind of thing can be fun, so that's >>>>> probably a good thing. To some degree. >>>>> >>>>> But, getting back to parallelization, the motivating issue for >>>>> parallelization is efficiency. But that's meaningless if you're not >>>>> making some effort to track relevant resource costs. But that's a >>>>> pain. So he's not doing that, and he's kind of glossing over that >>>>> issue in his youtube talk (though he did touch on it in a few places). >>>>> >>>>> But I guess I sort of drifted off during his talk and didn't pay >>>>> enough attention to a lot of it. >>>>> >>>>> Still, his water histogram thing was kind of fun, so here's some >>>>> operations on those things: >>>>> >>>>> NB. go above this and water spills out >>>>> hull=: >./\ <. >./\. >>>>> >>>>> NB. how much water can be poured into a structure >>>>> water=: [: +/ ] - hull >>>>> >>>>> NB. how much water you can add when you join two globs together: >>>>> combine=: water@,&hull >>>>> >>>>> (Though you might make the case that hull should be left out of the >>>>> combine operation?) >>>>> >>>>> Example uses: >>>>> water 2 6 3 5 2 8 1 4 2 2 5 3 5 7 4 1 >>>>> 35 >>>>> 2 6 3 5 2 8 1 4 combine 2 2 5 3 5 7 4 1 >>>>> 22 >>>>> >>>>> Note that I've left out some of the details of his representation. >>>>> Also, I guess there's still a fair bit that could be said here, in the >>>>> context of his talk. For example, I guess hull is an idempotent >>>>> operation: >>>>> hull 2 6 3 5 2 8 1 4 >>>>> 2 6 6 6 6 8 4 4 >>>>> hull hull 2 6 3 5 2 8 1 4 >>>>> 2 6 6 6 6 8 4 4 >>>>> >>>>> And, that might be significant if we were building a J compiler. >>>>> (Which, to be useful, would probably need to deal with constraining to >>>>> relevant collections of types and shapes.) >>>>> >>>>> Or, at least, that's my current current thought. But I guess the big >>>>> thing, from my point of view, is how much of the detail he presented >>>>> I'm glossing over. But simplification is good, right? >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Raul >>>>> >>>>> >>>>> >>>>> On Mon, Feb 15, 2016 at 6:00 AM, June Kim (김창준) <[email protected]> >>>>> wrote: >>>>>> Hello >>>>>> >>>>>> I watched an interesting video from Guy Steel. who is famous for his >>>>>> Growing a Language paper : >>>>>> https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf and his >>>>> design >>>>>> of scheme, common lisp, and java. >>>>>> >>>>>> He is also a famous researcher in concurrent mathematical >>> programming. He >>>>>> designed the Fortress language. >>>>>> https://en.wikipedia.org/wiki/Fortress_(programming_language) >>>>>> >>>>>> The following video is his lecture at Google. >>>>>> https://www.youtube.com/watch?v=ftcIcn8AmSY >>>>>> >>>>>> He shows the solutions for water histogram problem and compares >>>>> sequential >>>>>> and parallel approaches. It is interesting from the perspective of >>> array >>>>>> oriented languages. >>>>>> >>>>>> June >>>>>> ---------------------------------------------------------------------- >>>>>> 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 >>> ---------------------------------------------------------------------- >>> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
