
Getting Started with APL (2017) - lelf
https://www.sacrideo.us/getting-started-with-apl/
======
shrubble
The Gnu APL interpreter is free, installs easily and the author is not only
very responsive on the bug-apl mailing list but very knowledgeable about APL.
Recommend you check out this interpreter.

~~~
arcfide
Dyalog APL is also free (as in beer) and easy to install now that distribution
has been streamlined. While I am biased, I consider Dyalog APL to be the
premier APL interpreter and getting it is a matter of a few clicks on Dyalog's
download page:

[https://www.dyalog.com/download-zone.htm](https://www.dyalog.com/download-
zone.htm)

~~~
jodrellblank
Nars2000 is also free as in beer and opensource, and is easy enough to
install, and is nowhere near as comprehensive as Dyalog but interesting in its
own ways (ball arithmetic, combinatorial functions, pi/prime number functions,
simpler GUI)

~~~
arcfide
NARS2000 is always doing some interesting stuff. Morten has said before that
if he had to recommend an open-source APL, it would be NARS2000.

------
pmoriarty
A big hurdle for me is that there's no APL interpreter available in my Linux
distribution's (Gentoo's) package manager. So I can't easily install it as I
can most other languages, using my distro's package manager. That means I'm
going to have to search out how to get an APL interpreter -- something not
even mentioned on in the _Getting Started_ article linked to in this HN post,
nor on the _Getting Started_ article on dyalog.tv that the former article
links to. That alone is just way too much trouble already.

Then there's the issue of typing in all the weird APL symbols. I've
reconfigured my keyboard to type special symbols a long time ago, but I don't
even remember how to do that now so it'd be nice if there was some
straightforward documentation on how to do that for APL on a typical Linux
system -- or, better yet, some easy plug-and-play way to do that. That would
eliminate yet another major hurdle.

~~~
smabie
Just try kdb+/q instead. It’s really the only APL derived language that is
used in industry. It’s blazing fast and if you get good at it, you can make
more money than maybe any other programming language. It’s a very nice
environment and the language (q), comes with a great time series database
(kdb+). It’s proprietary, but the 32-bit version is free to use, I believe.

~~~
7thaccount
I don't have lots of money and my company passed on it as too proprietary,
else I'd be all over it.

~~~
srazzaque
Did you actually see a quote from Kx before making that decision?

I've first-hand seen the cost/proprietary argument thrown into the face of
KDB, to then see companies proceed down a path of other technologies, with a
10x spend in hardware and dev effort.

KDB is insanely tuned.

~~~
7thaccount
There are other costs. It is hard enough to find people in my industry with
domain knowledge, ability to dig into problems, and SQL skills. Finding enough
people to use an array language would be difficult as others in my industry
have found. I'd personally be super pumped, but I'm an outlier here. Also,
there are costs to getting kicked into something like this instead of
something like tsdb or influx.

------
7thaccount
Unfortunately I don't think Aaron has made any progress on coming up with an
APL beginners book yet. I'd certainly be excited to buy a copy though. The
only book I've read is the free one on Dyalog's website which is good, but
doesn't really help me think in terms of arrays for everything.

~~~
arcfide
Actually, there is movement in this general direction. My Thesis is now out
and available publicly in its final version and should be indexed in the
databases shortly entitled "A data parallel compiler hosted on the GPU." This
provides a bit of an introduction to some aspects of APL, and includes a
background on some of the ideas I've talked about before. Additionally, it is
a "handbook" of sorts for doing tree transformations in APL, which is, to my
knowledge, the first of its kind.

As for the beginner's book, I've come to the general feeling right now that a
online video course will be a better fit for APL beginners than a textbook.
This is an active project of mine that I anticipate completing some time
within the year 2020.

You may also want to see my presentations on design patterns for APL and the
upcoming videos at FnConf 2019 this year. I am not sure if the APL Training
Wheels session was recorded, unfortunately, but the content from that work
will be going into the video course.

~~~
dragonwriter
> As for the beginner's book, I've come to the general feeling right now that
> a online video course will be a better fit for APL beginners than a
> textbook.

Other than generating emotional responses, I don't find video better than text
at anything, and most especially not technical education.

~~~
arcfide
Thanks for the thoughts. While I am sympathetic to your position (and I don't
necessarily disagree), I'm not sure that the education problem with APL is
strictly technical in nature. Nor am I convinced that what needs to be learned
in order to use APL is strictly technical in nature.

Part of this is a question of what the stamina level is for the current
computing student. With a lot of technical documentation that people are
learning, they're essentially consuming either thorough reference materials or
walkthrough/how-to materials.

We can characterize both of these materials as efficiently transferring a
certain sort of information about how to do things by virtue of a very wide
base of shared prior knowledge. This is what allows reference materials and
walkthroughs to work.

But this shared base of knowledge does not exist for most people learning
about APL. Target audiences include non-computing students who are just
learning computing, programmers who want to learn APL, and technical
professionals who have little or limited prior computer science knowledge (but
perhaps cursory programming knowledge) who need to learn APL to accomplish the
work they want to do in their domain. In the cases of the technical
professional and the uneducated student, reference materials and most tutorial
books are wholly inadequate.

For the programmer, these tutorials and references work because most of the
time you are adding to your existing knowledge as a programmer and have
already trained numerous soft skills that enable you to navigate the sea of
potential directions to integrate the new knowledge.

I worked on my thesis to try to make it as accessible to the general
programming community as possible to teach a set of algorithmic concepts that
most programmers already have a vague notion about (but almost never use),
namely, SIMD/data parallel programming, using an extremely simple and easy to
explain syntax and vocabulary (APL). My thesis is already pretty detailed and
illustrative, with worked examples for every single programming statement in
the entire compiler going over examples and prose detailing everything that is
going on, a sufficient background introduction not only to the syntax and
semantics of APL, but also the design and stylistic questions, reference
material, and the architectural education necessary to understand the
structure of the compiler as a whole.

Even with all of this, presented to experts in the C.S. fields of PL and
parallel computation, who have seen this material multiple times over, there
was a general feeling that my thesis could have benefited from even more
exposition.

My thesis is around 70,000+ words and around 250+ double-spaced pages. For 17
lines of APL code. People wanted more. Had I added the additional exposition
desired, I imagine the thesis easily could have been 80 - 100k words.

A typical short novel is around the same size, and those often take about 8 -
12 hours to read through aloud. If you give me around that amount of time in
classroom time, I could easily have almost any programmer fully understanding
my compiler within that time, and probably with more thoroughness than if
someone were to take the same amount of time to read the thesis.

There is something about the higher bandwidth and richness of full video
content that contributes better to the transmission of data in some ways,
particularly to the understanding of certain ideas and concepts.

I began to think about what it would take to put together an introduction to
APL as a textbook. These have been done before and are out there, and they
would generally work, but I'm not convinced anyone would read them.

You can teach APL the language to a sufficient level in a very short document
(maybe a few pages) and in maybe 2 hours of classroom time. It's relatively
trivial to teach the language, as it's very, very easy to understand the
semantics and syntax. There's even a walkthrough of APL at
[http://tutorial.dyalog.com](http://tutorial.dyalog.com) already.

The challenge comes in its application, and that's where the real value of a
good education rests. But that part of the education is a lot harder to teach
in text, because there is an element of style, aesthetic, and practice that
goes into it. It's something that you gain by seeing, watching, and doing. You
have to bring your mind into the space and struggle, go in and out of
exploration mode and absorption mode.

How do you teach the exploratory process of APL? The design aesthetic? The set
of idiomatic patterns? How do you get people to intern those concepts into
their practice so that they are productive?

You could write a textbook to do this, no doubt. But thinking about it, I
think such a textbook would be very large. It would be not very "exciting"
emotionally. It would have very little of the emotional hooks that help a
person stay engaged in things. And moreover, it would be extremely
intimidating.

How many people effectively learn without any teacher in a totally "new" field
from a textbook that is devoid of any human feedback? You can do it. I've done
it before. But it's infinitely improved by the introduction of someone who can
help to inject energy and dynamism into the space.

I just don't think people will want to pick up a 400 page "introductory" book
and then have the motivation to stick with it when there are so many other
shiny things in this world today. The truth is that the world is filled with
distracted people who are very bad about putting the time into learning
things. I want APL education to be engaging, accessible, and satisfying, to
say nothing of effective. For most people today, a textbook is unlikely to be
that.

Another big challenge with the "experienced programmer" target audience is
that they are used to reference and tutorial materials. Very few programmers
actually sit down and _read_ such materials. They skim them to find what they
think they want to know, and then plug that into their existing framework.
That's great for efficiently extracting new information that is similar enough
to their old practices to work. If something breaks, they can just go back and
do a little extra skimming to clarify. That doesn't work really well when what
you need to learn is fundamentally conflicting with or altering how you think
about problems.

Getting good with APL at the beginning, before you've learned to intern it, is
about undoing or unwinding previous habits and thought patterns that worked
for you in past programming experiences, but that won't work for you in APL.
After you have interned the new methods, then you can switch back and forth at
your leisure, but until then, learning APL is as much about unlearning as it
is about adding new knowledge. For programmers who are used to just skimming
what they read to get what they want to know without actually listening to
what the author is saying (and that _is_ how most programmers read that I've
met), this makes textbooks a recipe for disaster. Either the information has
to be presented in such a dense way that most people will not be able to
figure it out, or it has to be presented in such a measured, hand-holding way
that most people will just ignore it, get bored with it, or skim it and still
have the issues.

It does little good to have a full, thorough textbook introducing everything
if no one reads it, though they think they've read it, and then they complain
about how hard APL is to learn because they couldn't just take what they
thought they wanted to know and leave the rest.

 _If_ you could get a programmer who was motivated, eager, and willing to read
from cover to cover, stopping at each point where a hard question is asked, do
the problems, quizzes, challenges, and exercises, in order, linearly, from
start to finish, and actually pay attention to what was said when, and then
take the points in the book that indicate one should think about this or that,
I would agree with you that a textbook could have some potential benefits over
the video format; but, I don't think that this is reality, based on my
experience.

Your typical APL workshop for technical professionals is 4 days about about 24
hours of work with probably around 12 of those hours being expository. After
that, people are quite solidly grounded in APL. But a lot of people have gone
through that same amount of time on their own with plenty of the same
resources available to them in terms of problems, documentation, and the like,
and they haven't been as successful. Guided, in-person education is hard to
beat, and video is the closest thing online.

I haven't given up on the hope of a great APL book, and I could be convinced
by someone that I should do a book first, but at the moment, I feel that video
courses are more likely to be more effective for more people and present a
larger ROI in terms of the difficulty in producing and creating them compared
to a book of similar effectiveness for the same range of people. If anyone has
an alternative, please do speak up, I'm all ears.

~~~
7thaccount
An interesting perspective. I personally didn't enjoy lectures in college when
it came to technical classes (engineering, math, physics) as I had trouble
keeping up. Videos help solve that though as you can go at your own
pace...pause and rewind. I'm sure it will be a lot faster and reach more
people faster with videos. There are so few in the APL/J world. The few ones
that exist are very popular though.

~~~
arcfide
Rest assured that I haven't given up on the textbook / tutorial approach just
yet, but I might have to "invent" my own publication technology to get the
"book" that I want.

~~~
7thaccount
Would it be hard to just create a Dyalog-APL notebook (I recall Dyalog added
support for that recently) and export as PDF?

I find Jupyter notebooks in Python and Wolfram's Mathematica to be nearly
perfect for explaining complicated content where you can easily format text,
images, and inline code snippets.

~~~
rikedyp
I have started something along these lines.

github.com/rikedyp/learnapl

It is currently very rough around the eges and also in the middle. Work will
continue in the new year.

There is also now a set of introductory problem sets that have been used in a
couple of schools on problems.tryapl.org

------
qwerty456127
AFAIK APL itself is easy and beautiful but bending you mind to interpret
complex logic in its model can be tricky.

~~~
arcfide
It's really no more difficult than learning recursion, pointers, memory
allocation, type theory, functional programming, iterative programming, OOP,
or any other of the myriad techniques that we use for computing. As I mention
in my talk on APL design patterns, it's largely a matter of what we have been
trained to understand, and there is some evidence to suggest that APL is
actually arranged in a manner more natural for the human faculty than most
computing languages:

[https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be](https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be)

~~~
qwerty456127
> It's really no more difficult than learning recursion, pointers, memory
> allocation, type theory, functional programming, iterative programming, OOP,
> or any other of the myriad techniques

You don't really need anything of this to solve a problem with Python and
Pandas.

I always feel like I wish I'd solve it with APL (because it's beautiful) but
end-up just getting the thing done this way :-]

Thank you for the lecture, perhaps it is going to inspire me to actually learn
to solve real problems with APL.

~~~
arcfide
Except that you do. Python is a form of OOP/Iterative programming, involves
memory allocation, pointers, references, and the like. Pandas requires the
skilled application of a general purpose language coupled with a domain-
specific vocabulary for your problem space.

I maintain that APL isn't fundamentally more difficult. If there is something
that you have as an example that you think is just too "hard" to do in APL
that is very "easy" in Python and Pandas, please do let me know via email
(arcfide@sacrideo.us) as I would love to make sure APL has a good answer to
such things (I want to make APL accessible).

Since you are talking about statistics and data analysis type things, you may
find TamStat of interest:

[http://www.tamstat.com/](http://www.tamstat.com/)

Additionally, don't forget that Dyalog APL also has a full Chart/Graphics
system (two, actually), and a large suite of idiomatic expressions for
computing many classic analysis problems. There's a number of other
integrations that people seem to be unaware of often enough.

I very seriously would like to receive from you one example of something you
have done that you find too difficult in APL, because if it really is, then we
can do better and I'd like to make sure that we do.

~~~
7thaccount
Just seeing this. I'm not the original poster that you replied to, but their
point is somewhat valid as is yours.

Python certainly requires one to learn iterative programming which is
definitely not a walk in the park. I learned it over a decade ago, but vividly
recall how non-intuitive it was at the time (global versus local scope had me
scratching my head once upon a time). Then there is lists, tuples,
dictionaries, pass by reference, iterators, file I/O...just soo much to learn.

One interesting thing is that I used OO methods in Python for ages before
understanding how to write and use classes. To me, a = list.sort() was just a
weird way to read a = sort(list). You can almost write Python entirely in an
imperative manner and for short scripts I almost always do.

Learning all the OO aspects of Java/C# and all the fundamentals of FP (monads,
currying... etc) is much harder for me than APL which is basically just learn
what these symbols do and the very straightforward way to combine them and
you're done. The only harder part of APL is somehow learning to replace
imperative programming with array operations. Sure it is easy to do some
things like sum up an array (+/ array), but that is also easy in Python
(list.sum()). The idioms as APL people call them are not at all obvious to me,
nor is the path of enlightenment outside of stop talking and go write some APL
haha.

