Hacker News Reader

Comment by feelin_googley | Hacker News Reader

There is a third freely available ASCII character APL in addition to K and J.

I have not seen it mentioned on HN before.

Have I missed the discussion?

It is called ELI.

I find it very sad that bloggers and commenters who are presumably employed as software engineers are continuing to discount the value of these languages simply because someone finds them incomprehensible. Failure of someone to comprehend is not the fault of the language. Persons having no prior knowledge of programming do not make complaints about APL versus more verbose languages. It is all the same to them, all incomprehensible in the beginning. To learn, work is required. And generally, more volume means more to learn. More work.

View on HN

> The proper way to critique these languages IMO is to do benchmarks. For example, the author of the blog post could state specifcially the problem he is trying to solve and then perform the solution in two languages or more languages, including an APL, including both the code size and the timings.

Here's the hobby thing I'm doing with this. I have an initial investment in Vanguard and contribute X additional per year. I'm at 90/10 stocks/bonds ratio and plan to, between now and retirement, gradually shift to a more conservative ratio. I have a rough distribution of RoR for both stocks and bonds. With all of these constraints in mind, I want run a few thousand simulations of expected savings at retirement. I want to easily compare these simulations to more pessimistic RoRs.

(No real reason, just seems fun.)

I'm pretty far along with the J. I've also written a bit of this of python as comparison, and from what I can tell so far it's an order-of-magnitude difference. I don't know numpy, though, which probably makes a big difference.

In the end, though, the benchmarks don't matter as much to me as the sheer delight in snapping my brain in two.

I don't program in J, but I breathe numpy. I can tell you that numpy broadcasted operations are probably an order of magnitude faster than explicit for loops in python...simply because numpy is of course written in C.

Reply on news.ycombinator.com