4 ms·

The Jame of Life

46 points by gbrown_ 5y ago

inimino 5y ago
This is an interesting post, but I think it should have mentioned the point that GoL is a tour-de-force to show off what is possible in the language, but it's not what the language is mostly used for. Most people using J or APL will just be getting some statistics out of large tables of numbers, or simulating something. So it's a little unfair to criticize the language for not being well suited to the problem. It's an extreme example of something well beyond what you would normally see written in that style.
- jaggirs 5y ago
  It doesn't. It says it is well suited for GoL, but not for slightly different problems.
  - inimino 5y ago
    I think the implicit criticism is that it is not suited for similar real life problems, because you never know if you have some problem for which it is well suited or some nearby problem for which it's not until after the fact. This is surely true, but I think as criticism it misses the mark because nobody seeing a problem of similar complexity to GoL should say "I know! Let's write a one-liner in APL!" The fact that it's possible at all is what is impressive. It's a little like if someone wrote a post criticising Ruby on Rails by writing a game engine in it, and then pointing out that it's slow.
narrator 5y ago
I worked translating APL into C. APL died for the same reasons Perl died. Nobody wants to read your code. APL had the niche back in the 70s that it was a very productive language for 110 baud teletypes where you could watch the characters coming back from the timesharing system print out line by line as you waited. In that age, conciseness was a killer feature.
- rscho 5y ago
  APL died? A large part of banking and heavy industry runs on APL, so I don't think so...
  - donkarma 5y ago
    It's dead, just still decaying
    - rscho 5y ago
      No.
  - omnicognate 5y ago
    Can't speak for "heavy industry" but a small part of banking uses kdb+, mostly in spite of the crazy APL-derived language it insists on using.
tromp 5y ago
Sometimes a simpler language beats one with problem specific primitives. For instance, Haskell is well equipped to do a short prime number generator with nubBy(((>1).).gcd)[2..] where nub removes duplicates from a list according to some notion of equivalence, which in this case is having a greatest common divisor greater than one. That's just 23 bytes. Can we beat that with a language with no such arithmetic and list support? It can in fact be beaten with a language that has no built-in numbers, let alone arithmetic. This 167 bit Binary Lambda Calculus [1] program 0011010100010100010100010000010100000100010100010000010000010100000100010100000100010000010000000100 produces the infinite characteristic sequence of primes. [1] https://tromp.github.io/cl/Binary_lambda_calculus.html#Complexity_of_Sets https://tromp.github.io/cl/Binary_lambda_calculus.html#Compl...
- contravariant 5y ago
  I think you confused the program with it's first 100 bits of output.
  - tromp 5y ago
    Oops; you're right. The program is 00010001100110010100011010000000010110000010010001010111 11011110100100011010000111001101000000000010110111001110 0111111101111000000001111100110111000000101100000110110 as shown in the top right of https://tromp.github.io/cl/cl.html https://tromp.github.io/cl/cl.html (with colors showing its tokenization as lambdas, appplications, and variables).
draw_down 5y ago
> ⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵ I don't agree that this is beautiful or elegant. It just looks like line noise to me, which is a bad thing. In terms of implementation details, it's nice that it doesn't need temp variables and such, but as the author points out, that has to do with the consonance between the language and the problem. I dunno, maybe I'm just a philistine but give me the dumb-guy 200-line blub-language code any day. Even at the worst it will be slightly more readable than that stuff above.
vok 5y ago
There are at least two excellent 32-byte x86 machine language Game of Life demos: https://www.pouet.net/prod.php?which=85485 https://www.pouet.net/prod.php?which=85485 https://www.pouet.net/prod.php?which=88201 https://www.pouet.net/prod.php?which=88201 The article expresses disappointment that a <40 character APL program mostly just demonstrates "why Game of Life is perfectly suited to solving in APL". But it seems harder to argue Game of Life is "perfectly suited" to solving with low-level x86 machine language.
- asdfasgasdgasdg 5y ago
  I think the point is rather in the opposite direction. He's not trying to argue that APL and the GOL problem are somehow uniquely matched. The idea is that yeah, APL makes a pretty solution, but it wouldn't be nearly as impressive if the parameters were changed. The point is that the APL solution people like to toss out is not flexible. Probably true of the 32b ASM demo too.

46 points by gbrown_ 5y ago

This is an interesting post, but I think it should have mentioned the point that GoL is a tour-de-force to show off what is possible in the language, but it's not what the language is mostly used for. Most people using J or APL will just be getting some statistics out of large tables of numbers, or simulating something. So it's a little unfair to criticize the language for not being well suited to the problem. It's an extreme example of something well beyond what you would normally see written in that style.

jaggirs 5y ago
It doesn't. It says it is well suited for GoL, but not for slightly different problems.
- inimino 5y ago
  I think the implicit criticism is that it is not suited for similar real life problems, because you never know if you have some problem for which it is well suited or some nearby problem for which it's not until after the fact. This is surely true, but I think as criticism it misses the mark because nobody seeing a problem of similar complexity to GoL should say "I know! Let's write a one-liner in APL!" The fact that it's possible at all is what is impressive. It's a little like if someone wrote a post criticising Ruby on Rails by writing a game engine in it, and then pointing out that it's slow.

narrator 5y ago

I worked translating APL into C. APL died for the same reasons Perl died. Nobody wants to read your code. APL had the niche back in the 70s that it was a very productive language for 110 baud teletypes where you could watch the characters coming back from the timesharing system print out line by line as you waited. In that age, conciseness was a killer feature.

rscho 5y ago
APL died? A large part of banking and heavy industry runs on APL, so I don't think so...
- donkarma 5y ago
  It's dead, just still decaying
  - rscho 5y ago
    No.
- omnicognate 5y ago
  Can't speak for "heavy industry" but a small part of banking uses kdb+, mostly in spite of the crazy APL-derived language it insists on using.

tromp 5y ago

Sometimes a simpler language beats one with problem specific primitives. For instance, Haskell is well equipped to do a short prime number generator with nubBy(((>1).).gcd)[2..] where nub removes duplicates from a list according to some notion of equivalence, which in this case is having a greatest common divisor greater than one. That's just 23 bytes. Can we beat that with a language with no such arithmetic and list support? It can in fact be beaten with a language that has no built-in numbers, let alone arithmetic. This 167 bit Binary Lambda Calculus [1] program 0011010100010100010100010000010100000100010100010000010000010100000100010100000100010000010000000100 produces the infinite characteristic sequence of primes. [1] https://tromp.github.io/cl/Binary_lambda_calculus.html#Complexity_of_Sets https://tromp.github.io/cl/Binary_lambda_calculus.html#Compl...

contravariant 5y ago
I think you confused the program with it's first 100 bits of output.
- tromp 5y ago
  Oops; you're right. The program is 00010001100110010100011010000000010110000010010001010111 11011110100100011010000111001101000000000010110111001110 0111111101111000000001111100110111000000101100000110110 as shown in the top right of https://tromp.github.io/cl/cl.html https://tromp.github.io/cl/cl.html (with colors showing its tokenization as lambdas, appplications, and variables).

draw_down 5y ago

> ⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵ I don't agree that this is beautiful or elegant. It just looks like line noise to me, which is a bad thing. In terms of implementation details, it's nice that it doesn't need temp variables and such, but as the author points out, that has to do with the consonance between the language and the problem. I dunno, maybe I'm just a philistine but give me the dumb-guy 200-line blub-language code any day. Even at the worst it will be slightly more readable than that stuff above.

vok 5y ago

There are at least two excellent 32-byte x86 machine language Game of Life demos: https://www.pouet.net/prod.php?which=85485 https://www.pouet.net/prod.php?which=85485 https://www.pouet.net/prod.php?which=88201 https://www.pouet.net/prod.php?which=88201 The article expresses disappointment that a <40 character APL program mostly just demonstrates "why Game of Life is perfectly suited to solving in APL". But it seems harder to argue Game of Life is "perfectly suited" to solving with low-level x86 machine language.

asdfasgasdgasdg 5y ago
I think the point is rather in the opposite direction. He's not trying to argue that APL and the GOL problem are somehow uniquely matched. The idea is that yeah, APL makes a pretty solution, but it wouldn't be nearly as impressive if the parameters were changed. The point is that the APL solution people like to toss out is not flexible. Probably true of the 32b ASM demo too.