4 ms·

> I am so baffled by these claims that I wonder if I'm missing your point. My reaction is: A tremendous amount is gained by this abstraction. addOne =. 1+[

by geocar 7y ago

> I am so baffled by these claims that I wonder if I'm missing your point. My reaction is: A tremendous amount is gained by this abstraction. addOne =. 1+[ isPrime =. 1&p: I do not think these functions are useful enough abstractions to be given a separate functions.

jonahx 7y ago
> addOne =. 1+[ The J authors did (correctly imo) think that it was. It's called ">:". > isPrime =. 1&p: In this case it does not, although I'd argue it's not so much about "isPrime" not being a useful concept worth naming on its own, as that J is a dense language working with a limited character set and there are a bunch of related concepts around "primeness" that need to packed into the "p:" verb -- accomplished in this case allowing the left argument to access a bunch of different verbs worth naming. Said another way, "1&p:" just happens to be the way J names this concept, for reasons of economy. For the prime case in particular, it will be a named function in most math libraries that deal with such things, or languages where such math is central to the domain: https://reference.wolfram.com/language/ref/PrimeQ.html https://reference.wolfram.com/language/ref/PrimeQ.html I am still unclear what your claim is: that such functions are always an example of "too much abstraction"? If so, I don't think that claim is tenable.
- geocar 7y ago
  > The J authors did think that it was. It's called ">:". So did CL. I still disagree though: >:/ is different than (1+])/. 1++:i. is the same number of characters as >:+:i. I feel like there are many more valuable functions more deserving than this one. > I am still unclear what your claim is: that such functions are always an example of "too much abstraction"? If so, I don't think that claim is tenable. Sorry it's so difficult to figure out; You're not asking really constructive questions, so maybe one of my other replies will help. I'm not saying anything is always one way or another because I think the only absolute is that it always depends!

by geocar 7y ago

jonahx 7y ago

> addOne =. 1+[ The J authors did (correctly imo) think that it was. It's called ">:". > isPrime =. 1&p: In this case it does not, although I'd argue it's not so much about "isPrime" not being a useful concept worth naming on its own, as that J is a dense language working with a limited character set and there are a bunch of related concepts around "primeness" that need to packed into the "p:" verb -- accomplished in this case allowing the left argument to access a bunch of different verbs worth naming. Said another way, "1&p:" just happens to be the way J names this concept, for reasons of economy. For the prime case in particular, it will be a named function in most math libraries that deal with such things, or languages where such math is central to the domain: https://reference.wolfram.com/language/ref/PrimeQ.html https://reference.wolfram.com/language/ref/PrimeQ.html I am still unclear what your claim is: that such functions are always an example of "too much abstraction"? If so, I don't think that claim is tenable.

geocar 7y ago
> The J authors did think that it was. It's called ">:". So did CL. I still disagree though: >:/ is different than (1+])/. 1++:i. is the same number of characters as >:+:i. I feel like there are many more valuable functions more deserving than this one. > I am still unclear what your claim is: that such functions are always an example of "too much abstraction"? If so, I don't think that claim is tenable. Sorry it's so difficult to figure out; You're not asking really constructive questions, so maybe one of my other replies will help. I'm not saying anything is always one way or another because I think the only absolute is that it always depends!