Hacker News Reader

Comment by pavlov | Hacker News Reader

APL is fundamentally cool and I'd like to think it will make a comeback. But it seems that most modern APL-derived languages focus on trying to squeeze everything into ASCII as concisely as possible.

The following is an example of quite readable ELI with only a handful of symbols:

    c,[1.5]32+1.8*c<-$_10+5**!10

It's not bad, but when all you have is ASCII, dense notation will inevitably look like line noise.

APL's graphical notation was one of its original inventions, but custom keyboards weren't a viable solution in the PC era... But today the situation is different again. High-DPI displays and touch screens are becoming standard.

Would it be possible to reinvent APL notation to take advantage of high-res graphics and natural input methods? I'd love to see a tablet-only reinvention of APL that doesn't have a keyboard at all, just a number pad and painted gestures.

View on HN

Not all APL-like languages do the conciseness thing. Numpy doesn't. Recently a colleague had some imperative code for computing a specific random variable (average revenue given a certain product selection process). Roughly speaking, the for-loop you expect. In code review I changed it to:

    revs = dot(dirichlet(alpha, NUM_SAMPLES), rev_by_category)

Net result - this draws NUM_SAMPLES dirichlet vectors, dots them with the rev_by_category vector, and generates a list of NUM_SAMPLES of the corresponding random variable.

Or:

    total_variation = var(data.flatten())
    first_axis_var = var(mean(data, axis=0))
    second_axis_var = var(mean(data, axis=1))

From what I understand, this is definitely idiomatic J translated to Python. In general, idiomatic numpy code will always be array oriented since that's (until recently) the only way to shell out to C.

So from what I can tell, APL isn't dead. It's just spelled out in easy to read executable pseudocode.

Honestly, we need a programming language, any language, that is genuinely designed around the limitations of touch input while sticking to a textual style. I can find lots of interpreters for various languages on my phone, but all rely on stock text editing controls to make me peck away at whatever I want to write - even the MIPS assembler I downloaded made you edit a text file. If we just embraced denser notational style, we could do a lot better without being particularly more elaborate in how the code is displayed or parsed.

I dream of a programming language that would bring coding closer to Japanese brush painting. APL's terseness would make it a suitable foundation for that.

Imagine you're handed a tablet that shows such a program. At first glance it's a unique calligraphic image, but when you know the language you can also parse the data flow and manipulated types intuitively upon seeing the shapes. And since it's a dynamic digital document, you could zoom in, isolate parts, or even run "live coding" style experiments to see what the painting actually does.

Amateur ShoDo practitioner here: not sure that "Japanese brush painting" is actually a good idea for programming. Maybe you mean something like the Korean writing system: Hangul (http://en.wikipedia.org/wiki/Hangul)?

For what I know, Hangul "glyphs" provide consistent encoding (see also: http://en.wikipedia.org/wiki/Featural_alphabet).

In Japanese Kanji the "elements" (Radicals, or Bushu, see here: http://en.wikipedia.org/wiki/Radical_%28Chinese_characters%2...) do _often_ work as semantic indicators (see for example Radical 85: http://en.wikipedia.org/wiki/Radical_85 which usually implies some connection with water or other liquids) but the connection may be obscure, or even look random - as an example (among hundreds) see 淋 where the radical for water, followed by two "tree" radicals means: "lonely, deserted, abandoned".

Yeah, my idea is pretty vague. I didn't mean actually using any particular Japanese/Chinese/Korean writing system for programming, but rather something more abstract where elements of the calligraphic aesthetic would be adopted to serve algorithmic notation.

Something like "this large brushy swoop here is the part where all those matrices on the left are reduced, and then on the right we have these leafy things that map them into coordinates"...

Ok, well - maybe I'am going offtopic now but what I'd like to have is a _query language_ based on gesture. I.e. something to analyze data with. This video https://www.youtube.com/watch?v=jbkSRLYSojo gives an idea of what I'd like to have, but of course in this case the data "transformation" are pre-scripted and the speaker goes through a sort of coreography. Imagine being able to play with data interactively by moving stuff around in space around you.

+1.

Most text editors operate text substitutions (like "<-" turning to "←" automatically), so ASCII doesn't seem inevitable anymore (and I believe it's even truthier with virtual keyboards).

I worked in a company where APL used to be very strong (large french truck manufacturer) and they even had lots of programs written in Scheme for assembly-line optimisations in the late 90s. Most of those have been rewritten (should I say... painfully rewritten, and now buggy) in Java in 2005.

I feel like APL/CLisps/etc. were the right solutions but developers/managers were/are scared when they saw some of the mathematical/proof concepts they had to use, and were afraid of when they learned about them at the university.

We had an APL implementation and it was replaced 5 or so years ago.

It wasn't because of scared management. It was because they were paying for language knowledge not business knowledge. What replaced it, mostly C++ and Python, had better tooling and a wider pool of subject expertise to draw from.

Honest question: if I know J, what can I get from learning APL? When first looking at array based languages the symbols used by APL scared me off and I decided to go with J, now I wonder if the very same symbol set wouldn't be better than pure-ascii.

I did otherwise when interested in the APL/J/K world: the ASCII use of J scared me and I decided to learn some APL first and then, go through J's ASCIIness (I'm still early in the APL part, though.) I find APLs symbols nice and terse, for some of the basic things it's like learning a good editor's shortcuts (be it emacs or vi[m].) You no longer think about how to do X, but what you want to achieve and your hands do it. Of course, I guess with J it's exactly the same once you know enough of it, I just took the other route.

IMHO learning about a new language (without becoming proficient with it) is always good as it makes you think about the one(s) you're proficient with.

> learning about a new language (without becoming proficient with it)

Mostly true, but there are languages which are completely useless without becoming proficient with them. In my experience Forth and J are such languages: you can "learn about" them, but you won't really understand them without using them for some time. So I suspect APL, K, Q and Eli here are similar; the question is what will I gain from becoming proficient with one of them or alternatively is it worth becoming proficient in one of them if I'm already proficient with another.

Reply on news.ycombinator.com