Comment by michaelfeathers | Hacker News Reader

Comment by michaelfeathers | Hacker News Reader

Parent Full thread

michaelfeathers

> Not sure where to go from here.

For the past few years I've been telling people about the APL family of languages. The clincher for me was seeing the video of an APL version of Conway's Life mentioned in the submission. The impressive part wasn't its brevity, it was how they approached the problem.

In APL you have a 'rotate' operator that shifts data in a particular direction. If you have a vector and you rotate it once, every element moves to the next position and the last element then becomes the first.

The nice thing about APL is that most operations work on data regardless of its dimensionality. So, to do Conway's Life, you take your 2D matrix of cells and produce rotations of it in eight directions (N,NE,E,SE,S,SW,W,NW). You then take those rotated versions of the matrix along with the original and conceptually stack them. Then, for each grid point, you sum downward, producing a new matrix that contains the neighborhood count of the original matrix. From that you can create the next Life generation.

This sort of problem doesn't come up everyday, but the thing that I think is profound is that the existence of these operations allows us to think about problems in different, possibly simpler ways. They are untapped potential and they could be as well known as map and fold.

APL and its derived languages are hard to approach but there isn't much that keeps us from importing the data structures and operations in more approachable languages.

Hey Michael, been a fan since reading 'Legacy Code'.

Do you believe that refactoring a large APL codebase would be inherently easier than something like, a large legacy C++ codebase?

What is the relative complexity of comparing, say 1000 lines of APL to 10K lines of C++?

I remember reading an interview between Arthur Whitney and Bryan Cantrill where they mentioned something about recognizing idioms in the dense code much more easily in K than in something like C because it took so many less characters. Do you see any sort of refactoring advantage to that?

I've also recently seen work on the Co-dfns compiler in APL where the author mentioned that APL allowed him to easily refactor compared to traditional codebase, and looking at the github library, there is something like 3 million edited lines over the span of several years in a codebase this is a few thousand lines of code. I find this fascinating because my hope is to eventually start a small software business and I think reducing complexity in the number one priority in order to make it sustainable in the small (the goal isn't to have a team of 50 developers).

Thoughts?

Nick, I think that the primary win is referential transparency. APL idioms raise the level on that base. The tradeoff, though, is the same as we have for functional but further along the road: if you develop a codebase that doesn't use common idioms it's harder to hire people to work in it.

I think array languages, or at least their operation set and idioms, will move into the mainstream in the same way that functional is, but it will take time. Sustainability for your business would be more an issue of hiring and retaining talent.

Reach out if you want to talk about this more: @mfeathers

Exactly. Hence the idea of notation as as tool for thought.

APL makes you see and envision computational problem solving differently than, say C. Use it enough and your brain starts thinking in patterns, shapes, vectors and matrices being "zippered" together or apart, contorted and distorted.

Take a matrix of values and hit it with another matrix of 1's and 0's to select elements and then flip it, slice it, convert it to a vector and combine it with another vector to form a new matrix, then scale every element and apply a polyphase FIR filter across the rows using another matrix for the coefficients to then arrive at a vector containing your answer. This is made-up, of course, but that's how you start thinking, you start seeing parallel computing in your head and you can reach for it instantly with a notation that allows your hands to describe what you just imagined with a few well-selected symbols. No other language sends you on these flights.

It is truly seeing and approaching computational problems from a very different perspective. And the notation makes it comparable to composing music rather than going through the ugly mechanics of text-based programming languages.

I find it hard to explain to those who have never experienced this revelation of sorts. Watching a few videos and playing around with APL isn't enough. If I had to guess I'd say someone would have to work with it on a daily basis for about a year to achieve that mental shift.

Again, no different from musical notation. It is impossible to explain or experience how you see music once your brain can look at a page full of funny symbols and your mind starts to hear the music. The relationship with the piano, guitar or other instrument changes once that mental connection requires no thought at all.

Getting there with APL takes time. For example, you need to be able to sight read idioms like thee following much as a musician learns to read a two hand chord and instantly place their fingers exactly as required on the piano, without though.

http://docs.dyalog.com/14.0/Dyalog%20APL%20Idioms.pdf

or a large enough subset of these:

http://aplwiki.com/FinnAplIdiomLibrary

Back then, a lot of us used to walk around with a small pocket-sized FinnAPL idiom book in our pocket and had the FinnAPL idiom library book on our desk.

Your comparison to musical notation is insightful. I think that I can expand upon it a bit. I can read both western notation and Byzantine notation. Byzantine notation is very different from western notation: it describes a melody using symbols indicating how many steps to take from the current pitch in a given scale. There are also rhythmic symbols added to the notes that generally require reading ahead of what you are currently singing.

For people interested in Byzantine music, the notation can seem imposing at first -- especially to people who already know western notation. Much effort has gone into translating Byzantine music into western notation, but some problems arise. First, some Byzantine scales use very different pitches compared to a western equal tempered scale. Second, the rhythms in Byzantine music can involve syncopation or other rhythms that can be difficult to notate using western rhythmic symbols. Finally, Byzantine notation is optimized for depicting melody, while western notation is focused on harmony. There is simply more unnecessary visual noise in writing Byzantine music in western notation.

That last point resonates with your talk of idioms. While Byzantine music may seem to have many neumes for a given musical phrase, there are many idiomatic combinations of pitch-changing and rhythmic neumes together. As such, what would be read in Western notation with many individual notes and rhythmic markings, becomes in Byzantine notation a single "word".

If you're interested in seeing how these systems of notation compare, look at the following hymn: http://www.cappellaromana.org/wp-content/uploads/2014/04/Che... The neumes are in red at the top, with a simple western interpretation on the first western music staff and an ornamented interpretation on the bottom staff. Comparing the neumes to ornamented western interpretation (which represents the full Byzantine ethos, or style), we can see that significantly more information is contained in the sparser Byzantine neumes.

Anyway, you've convinced me to learn APL because I now see how similar the arguments for this notation are to my own arguments for using Byzantine notation. Thank you for your insight.

This is very interesting. I sight read western notation but never learned anything else. To be honest, I didn't even know Byzantine notation existed. Time to go learn something new. Thanks!

I would really love to read an expanded version of this explanation, as it's not clear to me why or how stacking or summing rotated matrices would work for this problem.

Take a look at this explanation on the APL wiki: http://aplwiki.com/GameOfLife

Reply on news.ycombinator.com