Interesting article. I'm playing with J currently and it is one powerful, yet difficult to learn language. Simple things are simple, but being able to efficiently chain trains of verbs together and think not in terms of loops and normal data structures, but arrays and math/matrix operations takes some training and time to get used to. I'd like to keep it up to obtain a powerful data analysis tool in my arsenal, but I want to make sure there are enough J & APL developers to make sure it is worth it. The language itself is amazing, but if there aren't enough developers you start to suffer from lack of libraries and you end up back in JS/Java/Python/Perl land.

J is a beautiful, beautiful language. It is quite hard to learn -- as a benchmark, I'd say Haskell is easy by comparison -- but once you reach a critical mass of knowledge it can more addictive, and more fun to program in, than anything else I've tried.

While J is fast, and can be practical, I would never recommend it for that reason, if only because it's so niche. But if you want to glimpse what a small sliver of all possibility the world of your day to day programming is, you will love J.

The problem I've seen with these languages is they are tough to debug syntax and semantics errors. A typed array programming language would be interesting. When are J or APL expressions well-formed and would some kind of type system help incrementally build and compose expressions?

> Function inverses are the kind of construct that changes how we view code.

> [..] For example, consider pairs of malloc/free, acquire/release, and open/close.

> All of them follow the pattern captured in the Under idiom: We do something to

> create a context, apply some functions in that context, and then leave our context

> by undoing the initial effects with a logical inverse like free, close, etc.

How do function inverses interact with error handling? What happens when a file cannot be opened because it doesn't exist? Or when the file can be opened but subsequent reads fail because the file is empty?

How do you typically work with errors in programming languages like APL / J / K? (I don't mean how do you work with errors in the REPL but how do you catch and handle/report errors in your program and recover/continue gracefully?)

I had a similar experience when I first started learning machine learning; thinking in terms of, and manipulating data as, matrices and vectors was not easy at the beginning -- even if the rest of language (Python) was 'classic'.

I guess pushing the envelop with a language like J, where everything is an array, plus the unusual function manipulation, would make it even more alien; it's like touring another planet. At least that's what I felt while reading this.

---

That said, it's really boggles me that every time someone tries to explain a new paradigm or idiom, they feel obliged to make it look as superior way of doing things. (Such as in : "J helps us get better at expressing that universal pattern.").

Can't we just express difference just like that; a different new thing. It doesn't have to be better, or worse.

Otherwise, I really enjoyed the article.

To me the most interesting part of this article is the part that nobody else seems to be commenting on: the ability to automatically invert a function, even a programmer-defined function. That seems magical! What if I define a hash function? How can it possibly invert that? Clearly there's something interesting going on behind the scenes, and I wish the article discussed what it is, and how (and when) it works.

Everything else in the article seems like plain old functional programming to me, with a little syntax sugar here and there.

There is the basic programming language, which provides a set of instructions that computer would do; then there is the meta-language (e.g. macros, templates) that provides instructions to compose instructions. I have come to realize that the functional programming essentially is the latter part.

For example, I have a meta language in which we can define a box and unbox:

    subcode: box_a
        instructions that un-boxes a type ...
        BLOCK
        instructions that boxes a type ...

    subcode: box_b
        instructions that un-boxes b type ...
        BLOCK
        instructions that boxes b type ...

    main_code:
        &call box_a
            &call box_b
                your code

That is a verbose version of J's under adverb with my meta-layer that I can use in any languages (C, Python, ...).

What's the advantage of using array programming versus using list/array types in other languages? Nothing I saw in this article seems particularly unique to J except the syntax.

The only other language where I’ve seen this is Factor, with its “undo” word. I presume they work similarly, so I can speak to the general idea.

It’s not that the compiler can invert a hash, or automatically derive a logarithm function from an exponentiation function, or anything like that.

Essentially, if you have a composition of functions in a “pipeline” (h ∘ g ∘ f):

    [ f g h ]   

Then to get the inverse of the composition, you just invert each function and reverse the whole thing (f⁻¹ ∘ g⁻¹ ∘ h⁻¹):

    [ f g h ] undo
    [ \ h undo \ g undo \ f undo ]

“undo” is defined for a set of primitive words. If there isn’t an inverse defined for some function you used in the composition, then it fails; however, you can just define a custom inverse for your function. And obviously this relies on having some kind of reified representation of functions available.

“undo” can be used for things like pattern-matching: a destructuring function, which takes some value and produces its fields, is the inverse of a constructor, which takes the fields and constructs a value.

You could do something similar in "normal" functional programming languages, but you usually won't get the nice syntax.

Basically, you can represent each invertible function by a pair of functions (pseudo-Haskell, because I don't use it very often and can't test on mobile):

  data Invertible a b = Invertible { forward :: a, backward :: b }

  apply :: Invertible (a -> b) (b -> a) -> a
  apply f a = forward f a

  invert :: Invertible (Invertible a b -> Invertible b a) (Invertible b a -> Invertible a b)
  invert = Invertible { forward = invert', backward = invert'}
      where
      invert' :: Invertible a b -> Invertible b a
      invert f = Invertible { forward = backward f, backward = forward f}

Then you can for example invert invert itself by

  apply invert invert == invert

But because there is no built-in language support, you'll end up doing lots of parallel construction of the standard library before you can even think of using it productively. Apparently someone already did that for Haskell (https://hackage.haskell.org/package/invertible), but it likely doesn't cover everything.

Probably the built in support for vectorization, which reduces the amount of code you need to write, and allows your code to be closer to mathematical expressions. Of course there are other languages like R, Julia and Fortran that also have built-in vectorization, and Python adds that with the Numpy library. It makes certain operations much easier to express than with your normal lists/arrays. That's why the Python scientific stack is built on top of Numpy arrays, and not the builtin data structures.

You can compare it to regular expressions for manipulating text.

Parallelization automatically, special constructs for sparse matrixes, complex manipulation of multidimensional arrays without need for making sure they are constructed correctly. Not to mention never having to worry about an indexing error, unless you are specifically asking for an index, in which case the bug is in your design, not the program. Built in methods for sorting and searching that are very efficient, as well as filtering. Also, J is faster when you give it all the data you can at once, rather than moving through index by index. A lot of these advantages take time to really be aware of, much like Erlang's bread and butter often hiding behind much more than one article.

I think the advantage is that you end up with much terser programs because you don't have to explicitly declare everything as an array.

I'd take this a step further and say the website for J language doesn't move a finger to entice anyone to learn the language or use it.

I don't know if it's academia or what - but if I spent the effort on creating a whole programming language that I believed was actually good - I'd have a very different front page.