Comment by desine | Hacker News Reader

Comment by desine | Hacker News Reader

For those in the comments just wanting a quick rundown:

Python3 based programming language for "golfing" (I had to double check it was code golfing, there's probably actual golf scorekeeping or course design DSLs by now).

I'll never hate on esoteric programming language concepts, even with minimal usecase. A brainfuck compiler was the second I ever installed, after a borland C++ IDE student license at age 15. But I don't see much use case, or even justification. Code golfing by macro-ing common math operations in python is nifty - and like many projects, inevitable in the "infinite monkeys with typewriters" sense, but altogether not that interesting. I guess it's in the OG spirit of HN, high concept nerd shit only programmers care about, but if someone beat my python code golf submission only because they used some obscure Unicode character that I don't know how to type that combines 3 math operations into one, I'd mentally call them a try-hard and move on with my life.

edit: but I'm also a hypocrite because I've been obsessed with Lisp (mostly just R7RS scheme) for the past year and what is that other than over-macro-ing your code

Code golfing is a game, and golfing with Jelly (Husk, etc.) is a version of it that some people find more fun. Most of the time it's not just a matter of picking the one crazy function that obviously solves the problem, although that does happen. I'd say there's usually more room for creativity when using a golfing language, because more strategies can be competitive instead of some being ruled out because the syntax for them is awkward. A typical golf is [0]. The components aren't complicated, and you can probably see there are a lot of ways to approach the problem.

Designing golfing languages is a game as well. Code golf uses byte counts, not character counts, so that there's a limit on the number of 1-byte operations (users of unicode-based languages count in UTF-8, or define a custom encoding to fit every character used in a byte). At that point it becomes important to pick out more useful operations, something that Jelly is known for being very good at.

The convention is that only programs in the same language compete with each other: everyone knows that it's nearly impossible to use fewer characters in Python than Jelly. Although most code golf is casual with no prizes. If you come up with something clever you can show it off and maybe people will appreciate it.

[0] https://codegolf.codidact.com/posts/281956#answer-281962

This makes sense. I've done some code golf challenges but never fell into the culture. Anywhere in computer science that there is a culture, development of culturally specific tools comes into play. Perhaps I commented too quickly as an outsider, but perhaps @singlow is also correct that the title needs a bit more explanation. I thought I was going to get either jealous or sweet treats from a github repo

Seems then you'll probably dislike apl - here's the full implementation of Conway's Game of Life in 53 characters:

    life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

And the explanatory video behind it (quite approachable!) https://www.youtube.com/watch?v=a9xAKttWgP4

Probably not. I've heard of it, never looked too in depth.

As mentioned I've become a fan of Scheme. The definitive text for learning it is probably SICP, in which Sussman and Ableson call programming a form of magic - calling out certain incantations, knowing their meaning, use, and producing data manipulation from them. I find this accurate, but as an English speaker, I think I just prefer the Latin Vulgate versions, and not the runespeak of the forgotten gods. I guess maybe I was a bit harsh to say there is no use case. Perhaps there is, for someone with a deeper cognitive and memorization pool than I. For me, though, interpreting such an incantation would be the equivalent of breaking down each operation into it's C-like forms. If it were broken down for me on the screen, I could back-reference each step, and view each incantation within the framework of the larger piece. Mentally interpreting the above would require me to do the same, but with each step stored in my own mental stack memory allocation, which would quickly overflow and crash.

Perhaps not, as mentioned I never tried APL, but I doubt I have the capacity to keep it all straight.

That's fair! It's just a DSL with all the tradeoffs that implies (and what lisp is generally quite good at).

It's just a programming language. Like natural languages, what once seemed foreign and inscrutable before you learn it becomes natural and (not quite) effortless after.

I'm sure you can handle it.

desine, learning J, which is in the APL family of languages, is good with "J for C Programmers" https://www.jsoftware.com/docs/help807/jforc/contents.htm - you don't need mental superpowers, Henry Rich gently adds a few new things when you're good with the previous ones.

I've always wondered about code like this and what inspires people to write it. How is this any different from just directly writing machine code?

Or is this the exact opposite, operating at the highest level of abstraction?

Closer to a very high level of abstraction in a quite restricted language. Array-based languages have lots of advantages for certain problems for those who have put in the requisite time (certainly not me!). They're one of the languages that'll expand the way you think of programming.

Array languages (Jelly is one of them!) work at a high level of abstraction, since programming consists of applying operations to entire immutable arrays. List comprehensions are probably the closest the mainstream gets to this style.

It's not as abstract as possible or anything. Most directly, there are abstractions like algebraic datatypes or macros that APL doesn't have at all. And there's a sense in which APL is very concrete: it tends to use first-order functions instead of higher-order ones like Replicate[0] instead of filter. For me the fact that an array oriented program tends to handle just a few arrays at a time makes it easier to understand what's going on. I think there are also ways in which APL programming is low-level. Going back to Jelly, it's actually a stack machine, same as Java object code, or Forth. Modern APL has tacit programming[1], which has a similar mix of mathematical purity and machine-like shuffling. I think the way APL handles array axes is similar. They are numbered, so to work with them you have to keep track of the ordering. Something like einsum that names them would be higher-level.

[0] https://aplwiki.com/wiki/Replicate

[1] https://aplwiki.com/wiki/Tacit_programming

As a commenter touched on above, these languages are purely for "golfing". Programming golf is when you challenge yourself to solve a problem in the fewest characters possible. Golfing languages therefore, are languages where the aim is to jam as much common functionality into single characters as possible. There is no real practical use for them.

One of the most memorable and interesting things I've ever seen on HN was an AMA from the creator of the Co-dfns parallel APL compiler. Here is co-dfns [0] and the AMA by the creator [1]. The video may give you some insight and at the very least may be extremely interesting to hear the APL code explained (jump to around 13:30 for the beginning of the explanation behind the structure + what the compiler is doing). He explains it very well - it's quite easy to follow along.

[0] https://github.com/Co-dfns/Co-dfns

[1] https://www.youtube.com/watch?v=gcUWTa16Jc0

As the author of https://staxlang.xyz/ for me, it's pretty far away from machine code. Golfing languages tend to be pretty impractical, as they optimize for program size above all else. That includes readability, performance, and consistency.

Machine code can be practical. To me, code golf is just pure programming, for no practical purpose. It's not for everyone, or even most people. It's more like art than practical programming. Except it can be competitive? Not sure really.

It can also be fun just to build something, without the risk that you might accidentally get a significant number of users.

Array languages are arguably more abstract. Rank polymorphism allows semantically the same program to work over various array ranks, where the execution meaning is derived from the context which is the shape of the argument. You can find these in some natural languages, which can have single phrases which you cannot know what it means unless you have the wider context.

Next, array languages abstract away the execution strategy of loops. You as a programmer do not pick whether you use an accumulator or divide-and-conquer in your loops. Some good parallel libraries like Rust's rayon arguably have this feature in the imperative model, but it's not exactly a language feature of Rust.

W.r.t. machine languages, array programs do not have typing information which I think is the case for all modern intermediate representations.

I came to APL looking for a compact code representation for a problem in hand (had to add transformations to data which was passed around over slow links). Not only APL is compact, it's different in an interesting way, which deserves learning by itself.

looks like script kiddies talk from the 90s

Reply on news.ycombinator.com