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
