paliilap

I take your point that these are two separate concerns, and we do certainly see a) without b) with Numpy, Julia, Matlab, R and the like. Using these languages is a very productive experience, and I agree that a) is definitely the main driver.

With J and APL, one pragmatic benefit I do see of the symbols over the words is the ability to see and use patterns if one is familiar with the language. This is harder to do with the words, which spread concepts thinner. I think Iverson expresses these ideas very nicely in Notation as a Tool of Thought.

The APL/J/K family strongly assume that readers of the language are familiar with their parsing and semantics, so idiomatic usage of each language makes no concessions for what is felt to be unnecessary. It's a different mindset for sure. When the users of the language share an understanding of what the symbols mean though, they no longer think it's obfuscated.

J takes such strong inspiration from English (to the point that it calls functions "verbs", operators "adverbs" and "conjunctions", and arrays "nouns"), that I once thought J would be better written entirely as English words instead. After having made such attempts, I actually found it harder to read and maintain the English versions. I couldn't attach strict behaviour and meaning to the words like I could with the special symbols. Perhaps I didn't entertain this idea long enough, but the words felt considerably less malleable.

I had the same concern as you regarding the readibility of APL and J. But there is a wonderful quote in an interview with Arthur Whitney (0) of kdb+ fame in relation to this:

BC To ask a slightly broader question, what is the connection between computer language and thought? To what degree does our choice of how we express software change the way we think about the problem?

AW I think it does a lot. That was the point of Ken Iverson's Turing Award paper, "Notation as a Tool of Thought." I did pure mathematics in school, but later I was a teaching assistant for a graduate course in computer algorithms. I could see that the professor was getting killed by the notation. He was trying to express the idea of different kinds of matrix inner products, saying if you have a directed graph and you're looking at connections, then you write this triple nested loop in Fortran or Algol. It took him an hour to express it. What he really wanted to show was that for a connected graph it was an or-dot-and. If it's a graph of pipe capacities, then maybe it's a plus-dot-min. If he'd had APL or K as a notation, he could have covered that in a few seconds or maybe a minute, but because of the notation he couldn't do it.

Obfuscation is not the goal of this style of programming, even though it looks like it's been deliberately golfed. Being able to express complex operations in terse but well-defined ways makes the intention clear. If you know the meaning of the primitives in +/ . * then there's little to debate that the combination is the matrix product. Whereas, if you have this operation expressible only with multiple explicit loops and intermediate variables, there are greater opportunities for error and a greater reading overhead.

I don't think J/APL are suitable for every sort of programming, and the sort of domains where J/APL excel are array-focused. J/APL's notation are a poor fit for writing a frontend single-page application (SPA), for example, and I would never want to maintain a SPA that merged all their functions into one line. I would not write complex integrals in English, and equally I would not write a medical document in mathematical notation.

But the goal of these languages is to improve the readibility of array manipulation by using composable and well-defined operations, not to obscure it. There is a large upfront cost to learning the notation, no doubt about it, and this is a necessity before you can use the language at all. But the intention is not for it to be harder to read - it's for it to be easier.

(0) https://queue.acm.org/detail.cfm?id=1531242

That 1975 APL demonstration is lovely. Much has been preserved in Dyalog and GNU APL - it's very interesting to see how timeless the core APL functions are.

I'm very fond of a number of videos by the late John Scholes narrating APL solutions step by step, including the well-known demonstration of Conway's Game of Life in APL (0). His videos on depth-first search (1) and solving sudoku (2) are also brilliant.

(0) https://www.youtube.com/watch?v=a9xAKttWgP4 (1) https://www.youtube.com/watch?v=DsZdfnlh_d0 (2) https://www.youtube.com/watch?v=DmT80OseAGs

You're pretty much spot on, and this is exactly the type of thinking we're looking for during our puzzle hunt. There's a slight difference between our system and what you've specified, but the overall picture is the same and I think it's awesome how you've reasoned through it.

You're on the right track! I think it's great how you're thinking about this.

Without spoiling too much, it's a cellular automata that you're manipulating parameters for as it runs - so the genome itself doesn't specify how the pump will beat, only how the state will change in the next generation (which will depend on the current state). That's why a genome doesn't give the same output every time - they only define how it will change, not what it will be.

There are multiple genomes that will give you the "ordered" pump, but we can guarantee there's only one Havoc codon that fulfils the criteria we specified. The solution is revealed after you submit a correct answer, and it definitely sounds like you're close (if you haven't found it already).

Thanks! We're a student group running an open puzzle hunt for medical/biomedical students who want to learn or practise coding. This is one of our puzzles based on a simplified cell automata model of a single heart ventricle.

We use Elm on our frontend and plan on using it to make other interactive puzzles like this one - we originally got into Elm from HN and it's been a joy to work with, so we wanted to share it back!

There's a constructed language called Solresol which works on this idea. It uses the 7 notes of the major scale (or the solfege system) to communicate, and this simple fact makes it quite flexible because it could technically be projected onto any 7-unit system (e.g. colours of the rainbow, hand symbols, pictographs).

I don't know how practical it is and it seems to be quite obscure nowadays, but it's got some interesting ideas. Antonyms, for example, are constructed by a phrase performed in retrograde. Its a very minimal system which makes the vocabulary somewhat constrained, but flexibility of it is pretty neat since you can vary the method of communication once you know the basic system.