
Fear and Loathing in APL (2015) - jxub
http://theburningmonk.com/2015/06/fear-and-loathing-with-apl/
======
Inetgate
I got 500 error. Here is cache:
[http://webcache.googleusercontent.com/search?q=cache:9IikFjT...](http://webcache.googleusercontent.com/search?q=cache:9IikFjTvgXsJ:theburningmonk.com/2015/06/fear-
and-loathing-with-apl/+&cd=1&hl=en&ct=clnk&gl=jp)

------
Volt
I'm seeing a lot more APL-related submissions in the past few months. What's
going on?

~~~
coldtea
One APL-related submission reminds people on HN of the existence of the
language. Others begin reading about it, some even try it, and a few of them
post subsequent links on HN. Repeat.

------
vesinisa
I was much confused by this example:

> AND and OR semantics are represented by ∧ and ∨ respectively.

> (1 3 5 > 6 2 4) ∧ (1 3 5 = 6 3 1)

> => 1 0 1

This is an error in the article. If you type the expression in TryAPL.org, it
produces 0 1 0 - as logically expected.

------
craigds
While it's interesting (pretty funny) that this language exists, it looks
downright _awful_ to program in. Has anyone ever programmed anything sizable
in it?

~~~
wenc
Kdb+ [0], a very high-performance and very expensive proprietary time-series
database, was written in a dialect of APL.

I've seen demos of Kdb+ and it is very impressive. It is the top ranking non-
GPU database in this benchmark [1].

It is however not the easiest of databases to use -- it uses Q (another APL
dialect) as a query language. There was an HN discussion a while back about
its maintainability and long-term prospects. [2]

[0]
[https://en.wikipedia.org/wiki/Kdb%2B](https://en.wikipedia.org/wiki/Kdb%2B)

[1]
[http://tech.marksblogg.com/benchmarks.html](http://tech.marksblogg.com/benchmarks.html)

[2]
[https://news.ycombinator.com/item?id=11561573](https://news.ycombinator.com/item?id=11561573)

~~~
arnon
I wouldn't trust Marksblogg's tests. They focus on single-table "NYC Taxi"
rides which don't represent most database use-cases.

He also claims he takes the fastest runtime of the queries over several runs,
which is not how real tests are performed.

~~~
jerf
"He also claims he takes the fastest runtime of the queries over several runs,
which is not how real tests are performed."

It isn't, but it should be. For any non-randomized run of the exact same work
[1], by definition of non-randomized, any noise that appears in the results of
multiple test runs can only be due to factors unrelated to the test being run,
such as the OS decisions and such. Taking the minimum is the most honest way
to factor those out. A possible exception for the first run, before CPU caches
are warmed up.

[1]: Ponder that closely; a lot of the knee-jerk reactions to what I just said
is handled by that; e.g., if the second time something is cached by the
algorithm itself that was not cached the first time around, that's not the
same work. Conceptually you can imagine that I'm shooting for the exact same
sequence of CPU instructions being run on the exact same data values, though
in practice that can be a tall bar to leap even before considering
concurrency; as with almost everything in life if you look closely enough the
boundaries get fuzzy.

