Hacker News new | comments | show | ask | jobs | submit login

Exactly, you could replace APL with lisp or OCaml (well, except that OCaml wasn't around in the 60') and all these points would still be true. I wonder if there are any APL users on HN who could provide more detailed information on merits of this language?

A lot of the ideas in APL were eventually transplanted to J [1] and K. K was eventually subsumed by Q [2]. (There's an open-source clone of K called Kona [3].)

The common "hello world" app of APL-derivatives is sudoku. Here's a an example, using K [4]:

Terse, right?

In addition to the productivity gains from not using loops, array programming has performance benefits since memory management tends to be more efficient, from a compiler optimization standpoint. That's because everything is stored contiguously and operations are mapped to cache-effiencent iterations. In addition, some implementations can take advantage of vector processing (SSE, etc.) quite easily, since the programmer expresses all actions at the array level.

[1] http://www.jsoftware.com/

[2] http://kx.com/Developers/software.php

[3] https://github.com/kevinlawler/kona

[4] http://thesweeheng.wordpress.com/2008/11/30/more-sudoku-solv...

I'm not too familiar with OCaml, but afaik one of the appealing features of APL is that it makes it easy to work with multidimensional collections in addition to one dimensional list-like collections (well, "easy" once you can grok the syntax). Do lisp and OCaml have those facilities out-of-the-box too?

No - neither Lisp nor OCaml makes looping over collections with an arbitrary number of dimensions implicit.

No; I am no lisp/ocaml god and not sure what do you mean by easy, but it seems they lack feature you are thinking about.

Having done extensive work with APL (including using it in robotics) I can tell you that I wish the language was more widely adopted.

The power of notation cannot be easily understood unless you have something to provide context. I find that music is good for this. Musical notation, to a trained reader, communicates with great efficiency what a musician needs to know in order to reproduce a piece. It would be unimaginable to write music using words or ASCII symbols. Yes, there are things like tablature for guitar, but they simply can't compare to real musical notation (if you've ever seen an orchestral score you'll know what I mean).

How do you relate if you are not a musician? Perhaps you know math, at least at an advanced casual level. Symbols such as the integral sign, root and others convey ideas that would require many words to describe. The integral of an integral is just two symbols. It takes two to four words to say the same thing.

Beyond this, notation is independent of spoken language. A Russian musician can read Mozart just as well as a French musician.

And so, what APL offers is the power of notation applied to telling a computer what to do. This is incredibly powerful. And, this is why I reject and abhor the APL derivatives (such as J) that sought to eliminate the symbols in favor of ASCII-fying the language. As much as I respect Ken Iverson (APL and J creator) I think he missed the boat by a grotesque margin with J. Notation is a huge part of what makes APL so powerful. Ken himself wrote a paper titled "Notation as a Tool of Thought" while at IBM. I found it here:


I should note that engaging in counting words, bytes or characters as a measure of the effectiveness of a language is probably silly. I have seen such comparisons:


For the most part they are meaningless. What matters to me is the power of expression and the ability to navigate from the problem domain to the solution domain without the mechanics of programming a computer getting in the way.

In my opinion, a perfect example of a language gone wrong is Objective-C. I program and have programmed in machine code, assembly, FORTH, APL, FORTRAN, C, C++, Basic, Visual C++ (MFC), Visual Basic, Lisp, Java, Javascript, PHP and a few others. I can't remember a moment when I said to myself "this is absolute crap". I find myself in that position every day now that I am touching Objective-C. The basic premise here is that, in my opinion, O-C does not provide me with a better way to do anything. You can name that tune with C, C++ or something like Visual Basic with much less pain and no difference whatsoever in the quality, content and capabilities of the resulting applications. A further indicator is that I firmly believe that virtually no programmer would freely choose to use Objective-C if it wasn't forced upon them. It's a pain in the ass.

Going back to APL. A lot of the comments about APL (going back decades) go something like (paraphrasing) "it looks so strange" or "it's hard to read", etc. The problem with this approach to the language is that it ignores that, in APL, notation has a purpose. And that, in order to understand this purpose and the advantages offered you have to learn the notation. An opinion does not count unless the person issuing that opinion has taken the time to study the language and gain some perspective. Going back to the musical example, it would be like a non-musician complaining that musical notation is "strange" and "hard to read". Well, yeah! It is! If you don't study it. And, without learning this notation you can't be in a position to appreciate what it does and how useful it is.

We need better tools. That's a given. Higher levels of computing cannot be achieved if we are all typing for-loops by hand. We need programming languages that are far more like music is to musicians. Most of today's languages are almost tantamount to describing music by listing spectral outputs and durations in a mechanical manner. With good notation a musician can thing in terms of music and not in mechanical terms. We need to reach the same level of thought abstraction with programming. APL was a huge step in that direction. Probably too far ahead of it's time.

If anyone wants to try out APL after reading that, NARS2000 is a pretty good free option: http://www.nars2000.org/

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact