The Jame of Life | Hacker News Reader

The Jame of Life

buttondown.email

46 pointsgbrown_13 comments

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#Compl...

I think you confused the program with it's first 100 bits of output.

Oops; you're right. The program is

    00010001100110010100011010000000010110000010010001010111
    11011110100100011010000111001101000000000010110111001110
    0111111101111000000001111100110111000000101100000110110

as shown in the top right of https://tromp.github.io/cl/cl.html (with colors showing its tokenization as lambdas, appplications, and variables).

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.

APL died? A large part of banking and heavy industry runs on APL, so I don't think so...

It's dead, just still decaying

No.

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.

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.

It doesn't. It says it is well suited for GoL, but not for slightly different problems.

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.

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=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.

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.

Reply on news.ycombinator.com