Thoughts on APL

51 views
Skip to first unread message

Josh Marinacci

unread,
Oct 23, 2014, 1:48:55 AM10/23/14
to augmented-...@googlegroups.com
I was finally inspired to take a look at APL. It’s a crazy language but lots of interesting bits inside.

http://joshondesign.com/2014/10/23/thoughtsapl


Raoul Duke

unread,
Oct 23, 2014, 1:03:30 PM10/23/14
to augmented-programming
so... how do i get APL/Q/K/whatever in another language that i actually like?

Josh Marinacci

unread,
Oct 23, 2014, 2:12:49 PM10/23/14
to augmented-...@googlegroups.com
I don’t know. Something we need to work on.

It would certainly be possible to make a JS lib that lets you do this:

function dostuff(arr) {
return APL.eval(arr, “x[^x6?40]”);
}


> On Oct 23, 2014, at 10:03 AM, Raoul Duke <rao...@gmail.com> wrote:
>
> so... how do i get APL/Q/K/whatever in another language that i actually like?
>
> --
> You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
> To post to this group, send email to augmented-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/augmented-programming.
> For more options, visit https://groups.google.com/d/optout.

Raoul Duke

unread,
Oct 23, 2014, 2:18:00 PM10/23/14
to augmented-programming
> It would certainly be possible to make a JS lib that lets you do this:
> function dostuff(arr) {
> return APL.eval(arr, “x[^x6?40]”);
> }


ouch! :-)
i meant more like a library that gives the core features to a language.
http://lambda-the-ultimate.org/node/5075#comment-82764

Josh Marinacci

unread,
Oct 23, 2014, 2:33:33 PM10/23/14
to augmented-...@googlegroups.com
Okay. More serious answer. :)

In Node, at least, you can have JavaScript code backed by C++. I think we could implement the APL operators, or at least a subset of them, in C++ operating on Node Buffers (a kind of native C++ array accessible from JS).  You could then call it with some sort of chaining API like this:

list.deal(6).of(1,40).to(x).sort(‘ascending’).index(x).execute();

We could then layer some sort of inline language extension that is transformed into the above code, similar to how CoffeeScript and OMeta work.  

- J





David Barbour

unread,
Oct 24, 2014, 12:55:07 PM10/24/14
to augmented-...@googlegroups.com
Recently an article regarding the ShellShock vulnerability asserted "The average programmers writes 10x more code than they read. The only people where that equation is reversed are professional code auditors." [1] 

Granted, any such claim should be taken with a grain of salt. I haven't seen much evidence one way or the other how much code the average programmer reads. And I suspect the issue is more complicated, like most programmers all reading similar toy-sized example code. But, given the conventional unsubstantiated assertion is the opposite (read 10x as much as write), this was jarring enough to get me thinking:

Perhaps "reading code" really isn't the way we should comprehend code. 

Reading code has a lot of disadvantages. First, code is incredibly dry. If I'm going to curl up with something to read, I'd rather grab a Dresden book by Jim Butcher (← shameless plug ;). Second, 'reading' code is really asking us to 'simulate code in your head', which requires a great deal of codebase-specific knowledge and attention to detail. 

Of course, code maintenance is still important. 

If we abandon reading of code, other tools and techniques for comprehension and maintenance would need to step up their game. Possibilities include automatic debugging, property testing, automatic property discovery, live programming, history and animation, typing/linting, easy sandboxing and playgrounds, zero button testing. It would help, also, if our bedrock [2] languages allow us to rapidly isolate errors via composition and locality principles (via capability security, effect typing, etc.).

Anyhow, back on the topic of APL... 

It seems to me that 'write only code' would be much less an aspersion against a programming language (or program) if we weren't expected to read other people's code as a primary mechanism for comprehending and maintaining it. Further, avoiding the burdens and overheads of 'readable code' might be the better long term direction, and result in greater accessibility of programs to users.


Raoul Duke

unread,
Oct 24, 2014, 2:19:56 PM10/24/14
to augmented-programming
given the gulf between what the glyphs say, and what the code DOES, it
does seem like reading the static text is sorta rigged with land
mines.

Shaun Gilchrist

unread,
Oct 24, 2014, 8:22:09 PM10/24/14
to augmented-...@googlegroups.com
wrt apl in js/node https://github.com/ngn/apl

Reply all
Reply to author
Forward
0 new messages