Hacker News Reader

Comment by kick | Hacker News Reader

GNU APL is pretty slow and makes some controversial design decisions. Fun to play with, though, and remarkably polished.

View on HN

I'd be very interested in reading more about the differentiating features of GNU APL. There is a great big announcement at the beginning of the GNU APL docs that talks of a decision needing to be made around a gap in the ISO specification. Is that the primary source of controversy or is there more discussion I could read somewhere else?

I've been looking for a good "diff" of the language differences between Dyalog APL and GNU APL, as much as to understand the extent of the progress since 'APL2' (or whatever the ISO standard name is considered equivalent to it) as any for any specific list of what GNU APL can't do relative to it's modern commercial compatriots.

(EDIT: Fixed final sentence to be a complete thought/sentence).

dyalog has a few more operators. for example @ & ⍠. It lets you use statement separators in lambdas. In gnu apl you can simulate that with '⊣'. It allows multiline lambdas. Dyalog uses ⍺⍺ & ⍵⍵ for operators vs ⍶ & ⍹. Dyalog lets you use ∘ as a composition operator. Dyalog generally has better performance, which becomes noticeable with large arrays. It has a lot more libraries available. Gnu APL behaves more like a traditional unix based interpreter. Gnu APL has erlang, python, lua, and C interfaces.

I admit, GNU APL gets sluggish when dealing with values with more than ~100k elements. For most ad-hoc work it is satisfactory and can let you sketch out ideas before attempting to push the performance characteristics.

Reply on news.ycombinator.com