Live data from Hacker News

APL – a Glimpse of Heaven (2006)

archive.vector.org.uk

11–20 of 47 posts

Re: APL – a Glimpse of Heaven (2006)

#11
From a PL standpoint:

1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able.

2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages.

3) I see a whole lot of MATLAB in there.

4) Did... this article actually define any functions at all? Perhaps I missed this.

5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

Re: APL – a Glimpse of Heaven (2006)

#12

From a PL standpoint: 1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able. 2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages. 3) I see a whole lot of MATLAB in there. 4) Did... this article actually define any functions at all? Perhaps I missed this. 5) It looks you coul…

re. 4) Yes it did, about 1/3 in:

    ∇ R ← Average V
[1] R ← (+/V)÷(⍴V) ∇

Re: APL – a Glimpse of Heaven (2006)

#13

From a PL standpoint: 1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able. 2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages. 3) I see a whole lot of MATLAB in there. 4) Did... this article actually define any functions at all? Perhaps I missed this. 5) It looks you coul…

3) More correctly would be to say that MATLAB has a whole lot of APL. APL is one of the oldest languages, being developed in 50's.

5) You'll perhaps lose some power. Notation is important - check Ken Iverson's Turing lecture.

Re: APL – a Glimpse of Heaven (2006)

#14
I've dabbled in J, and it's left me with a permanent sense of slight disillusionment with regards to every other numerical programming language I've used. It seems mind-boggling that NumPy, MATLAB, and even Julia lack the versatile broadcasting rules of APL family languages. In J, if you write a simple function that composes several built-in operators, your function is fully vectorized and can act on lists and arrays properly, and even arrays of arrays. In MATLAB, the same function stands a pretty good chance of only accepting scalar inputs unless you put extra effort into making it vectorized, and almost certainly won't do the right thing when given higher-dimensional arrays. Julia seems to likewise default to being mostly scalar-oriented, and only makes it less painful by having efficient JIT, but still lacks the expressiveness advantage.

Re: APL – a Glimpse of Heaven (2006)

#15
I did quite a bit of APL programming when I was younger.

When describing APL, people talk about the strange symbols, the mathematics, etc... but I have never seen anyone describe something I only realized after some time: APL makes you approach problems quite differently, when you are familiar with it.

I stopped thinking in 'steps' applied to the individual data points, but rather I solved the problem in my head (and writing the line along the way) by aggregating the data points into larger data objects, and then letting the data objects expand in a many-dimension universe, always larger and larger... and then I simply looked at the resulting mega-thing from a different angle, and started crushing it back along different dimensions until I finally got my answer (and my line completed). The resulting one-liner was very hard to read ... but gave me the correct result.

Inflation, Change of view-point, Big Crush. That is the core of APL.

Yeah I know... sounds crazy. But that was how APL programming felt to me, and I bet I am not alone. No other language I worked with ever triggered in me that kind of mental problem-solving process.

Re: APL – a Glimpse of Heaven (2006)

#16

From a PL standpoint: 1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able. 2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages. 3) I see a whole lot of MATLAB in there. 4) Did... this article actually define any functions at all? Perhaps I missed this. 5) It looks you coul…

[deleted]

Re: APL – a Glimpse of Heaven (2006)

#17

From a PL standpoint: 1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able. 2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages. 3) I see a whole lot of MATLAB in there. 4) Did... this article actually define any functions at all? Perhaps I missed this. 5) It looks you coul…

5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

I'm working on something along these lines, but not planning on keeping the APL/J-like syntax (the many meanings of juxtaposition makes parsing a line depend on the run time values attached to names). You can get more of the core idea of APL out of prop:procedure than out of extensible parsing.

Re: APL – a Glimpse of Heaven (2006)

#18
post #3

"To believe that “plain language” programming would be more readable is Utopian, even intellectually dishonest. For if I say, “a linear function of a variable is equal to the sum of a constant and of the product of a variable and a second constant”, it is incontestably English but completely obscure, even incomprehensible!" This is absolutely true. People try to make a big deal out of natural language for both progra…

Of course you wouldn't write it all out like that in any programming language. But instead of writing code like this:

  y = a * x + b
You could write code like this:

  height = slope * run + ground
It may not be helpful to write out simple math using colloquial language, but it can be helpful to future maintainers if your variables have meaningful names. Calling it "a variable" instead of "a" is not useful, but calling it "slope" can be.

Re: APL – a Glimpse of Heaven (2006)

#19
post #15

I did quite a bit of APL programming when I was younger. When describing APL, people talk about the strange symbols, the mathematics, etc... but I have never seen anyone describe something I only realized after some time: APL makes you approach problems quite differently, when you are familiar with it. I stopped thinking in 'steps' applied to the individual data points, but rather I solved the problem in my head (and…

So what I'd like to know is how that "quite different" approach to problems differs from the standard mathematician approach?

I've been playing with J lately. I've also been a longtime numpy user, going back to the days when it was still numarray. Maybe I'm just writing numpy in J, but I find that my approach in both languages is more or less identical: set up a vector, do some matrix operations, maybe some statistical aggregates, write down the answer.

Can you provide an example for which the APL approach is significantly different from what one would normally do? It might help me understand what insights I'm supposed to gain.

Post reply on HN