Hacker News Reader

Comment by lolinder | Hacker News Reader

I listened to the first ~5 episodes of The Array Cast wanting to be persuaded, but I just couldn't buy in.

They downplayed the terseness and non-ASCII symbols of the array languages as something you get used to and something that's worth it to get the benefits of array languages, but the benefits they listed were mostly ones that I'm already very familiar with from working with higher-order functions in most mainstream languages today.

It felt like the hosts had missed that map/filter/reduce have gone mainstream and are now available ~everywhere without having to learn a whole logographic writing system first.

View on HN

As an array language fan I also feel like a lot of the reasons people give for why array languages are powerful are outdated, and sometimes (not all the time) that's because someone tried both APL and C in the 1970s and their opinions haven't changed since.

However I still find them useful (and fun!) because of the terseness, not in spite of it. Terseness means array languages are very mathematical in nature + can be really ergonomic to write, especially with the repl. If someone said "learn an array language, they're easy to write on paper" everyone would think they were insane... but there is something to it, in certain cases. The idea of "fearless refactoring" is popular in the FP world, but it can also be true in the array language world too.

> "learn an array language, they're easy to write on paper" everyone would think they were insane... but there is something to it, in certain cases.

Indeed, and sometimes not needing a computer to quickly splash out an idea you're thinking/talking about is extremely useful!

Over Christmas, I showed my brother {+⌿⍤2(∘.≤)⍤1⍨⍵} as a small expression to explore attribute to pick playing Top-Trumps admist a discussion. Not something you'd be able to do in many other languages!

Could you explain the expression to us?

Sure - idea is you've got a 6×30 matrix of the 6 card attributes for each of the 30 cards, and want to know for each attribute how many other cards they'd beat.

  {+⌿⍤2(∘.≤)⍤1⍨⍵}

  {            ⍵} ⍝ single argument (monadic) function with argument ⍵
  {           ⍨⍵} ⍝ "selfie" - ⍵ f ⍵ where f is (∘.≤)⍤1
  {         ⍤1⍨⍵} ⍝ on each row (1 dimensional element)
  {    (∘. )⍤1⍨⍵} ⍝ cartesian (outer) product of each row with itself
  {    (∘.≤)⍤1⍨⍵} ⍝ ≤ comparison of those elements - produces 6 30×30 boolean matrices
  {  ⍤2(∘.≤)⍤1⍨⍵} ⍝ on each of those matricies (2 dimensional element)
  {+⌿⍤2(∘.≤)⍤1⍨⍵} ⍝ sum the columns

leading to: {+⌿⍤2(∘.≤)⍤1⍨⍵} ⍝ compare each row (⍤1) to itself (⍨) and count (+⌿) how many cards that beats

That make sense?

That's great and you have sent me down the rabbit hole.

So, usage would be something like:

CardPower ← {+⌿⍤2(∘.≤)⍤1⍨⍵}

CardPower cardMatrix

Yep, or even apply inline as {+⌿⍤2(∘.≤)⍤1⍨⍵}cardMatrix

Thinking about your comment further (and having read TFA and some of the comments) inline usage does seem to make more sense as it's only a few more characters. In that way it's transparent. Decreasing indirection (assuming that the operators always function simply and plainly.

Thanks for that follow up comment.

Array languages come up a lot on HN so I’ve looked into them a few times. I think it’s a hard thing to gauge without trying to use them in anger for a while. One of the core arguments for them that resonates with me is that once you understand the operators, many patterns become so terse and repeat so often, you can refactor large portions of code very rapidly. I use a lot of F#, and can see the beginnings of this where translating from C# to F# often shrinks the code size to the point where I see patterns that weren’t obvious before. I believe APL, K, J, Nial, BQN, etc all have more extreme versions of that happening.

It also makes differences stand out so logic bugs are more visually obvious.

I can corroborate: That same feeling of as simple and terse code as possible happens in Haskell too.

However the most popular professional style of Haskell code is far too verbose for me to be able to "see the essence" in many cases without a round of refactoring.

Its far worse and far more grating for Java code that makes you do so much for so little.

Sometimes the benefit of shorter codebases is that you can actually see the code.

Understanding that your logic bug is obviously somewhere within a handful of lines of K/Q/etc that fit neatly on a single screen vs scrolling through 200 lines of logic in Python/Java/whatever is focussing.

Sure each line is more compact and may take more time to digest, but that is a reasonable trade-off in most cases.

For me, 10 lines you need to read carefully beats 100 lines of having your eyes glaze over and repeatedly skip over the bug because you are so dulled to all the boilerplate.

Map/filter/reduce are just primitives. The composability built on top of them and coherent system of using these higher level combinators is where other languages fall short.

Other languages support regex for example, but perl takes it to a different level that changes the language experience.

I am often in these threads on HN arguing in defense of the underdog (array languages); I do tend to agree with you here. I think the early days of APL (and Prolog) were that they were high level casually-typed REPL based interpreted languages, in a world of Fortran, PL/1, COBOL and C, and the amazing nature of them back then is stuff we take for granted writing items=[1,2,3] and lookup={'key':'value'} in Python and not worrying about allocating and freeing memory or pre-declaring the variables and their types, the string length, and compiling, and whatever.

Still, there is a fun about a desk calculator on so many steroids that it's a Turing-complete programming language. One of the ArrayCast podcast guests said array languages were "like a Domain Specific Language (DSL) with an enormously wide domain". How many mainstream languages will let you fork and hook and have inverses and over and under and recursively descend into anonymous functions, without ceremony or boilerplate code? You could have that now to play with, without waiting for it to go mainstream, just by learning a two or three dozen unfamiliar glyphs - compare that to the effort of learning a whole new framework for making web applications and it's much smaller.

Reply on news.ycombinator.com