http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd... Where are APL and J? For the most part, dead. Sure there are people using them. If someone like me who used the language almost exclusively for ten years hasn't touched it for two decades I think it is safe to say: Great language to learn. Powerful and fantastic concepts. But, no thanks. Happy with C, C++ and Python.

The failure to open source a good APL didn't help either.

If J-Software wants to make a last valiant effort to bring this back my opinion is simple: Read the paper linked above and go back to the roots. Extend the language to make it object oriented and create interfaces to C, C++ and Python. That's a start. I could write a paper on how to improve APL. It has to start with a commitment to moving software engineering into the realm of communicating through notation rather than cryptic text.

Anyway, I'm not saying you have to personally like something such as J. If you're productive in C/C++ and Python, by all means create things in those languages. But please don't call J an absolute abomination, as I believe it merely calls coders with a different mindset/aesthetic desire to code in it.

Well, it is an abomination. Understanding my position on this might be impossible without significant real-world experience working with APL professionally.

I can offer the following analogy: Let's say I decided to replace musical notation with some kind of ASCII-based notation. Why? Because at the time I do this doing graphical characters on generally available computers is just-about impossible.

In the early days of APL you had to physically modify your computer's display card by swapping out a specially programmed ROM in order to be able to display APL graphic symbols.

Imagine that world, if you could, and imagine I want to display music notation and just can't without making hardware changes. So, I decide to transliterate every symbol into some combination of ASCII characters. Not because it adds to the language in some form. There is no valid argument whatsoever that could support breaking musical notation in such a way. It would purely be a lame attempt to design around, if you will, the limitations of the day.

Now present that ASCII-fied musical notation to an orchestra conductor. What would such a professional say about this "language"? I would not be surprised if they thought it was an abomination.

Learning APL, I was skeptical of its symbolry. But, by avoiding (verbal) mnemonics the symbol becomes its own thing, it has very specific meaning that is unique to APL. I can see the value in manipulating those very precisely understood symbols once a person knows the language cold.

J however remains above my pay grade.

"What attracted me, then, to APL was a feeling that perhaps through APL one might begin to acquire some of the dimensions in programming that we revere in natural language — some of the pleasures of composition; of saying things elegantly; of being brief, poetic, artistic, that makes our natural languages so precious to us."

http://www.jsoftware.com/papers/perlis78.htm

https://www.reddit.com/r/Compilers/comments/2m0fu5/using_lua...

However, I come from the FoxPro days, so I'm thinking more in tables and rows than in arrays. But I think could be great to do stuff like this:

subTotal = sum | InvoiceItem.Value * Orders.Qty

query = where(invoices, date.year > 2000)

1) Lack of spaces in the majority of code make it difficult to lex let alone parse, meaning I can't tell what the operators are. When people use spaces it makes a difference.

2) Every operator has at least two meanings. Some have three meanings. That's more than 100 operators to memorize and 50 share the same spelling as the other 50.

3) The parsing rules as described strike me as extraordinarily complicated.

The ideas in APL are worth learning. For example striping objects and using grade up to make a concordance or annotate any other data structure. Another example is having the primitives auto-sort collections when searching to get nlogn complexity. Almost any language can use these ideas. If Python is one step up from Standard ML because of dicts and out-of-the-box primitives, then APL is one step up from Python.

If anyone who knows APL well is around, can I ask some simple questions?

1) Do user functions and if statements vectorize? Meaning, if I write a recursive function to implement Euclid's GCD and then pass it two arrays, will it give an array of pairwise GCDs?

gcd(a,b) = if b=0 then a else gcd(b,a mod b)

where = and mod are both vectorized APL primitives.

2) Why do I see so few user functions being used? I would expect application code to consist mostly of specific functions but instead I see line after line of unbroken primitive operators.

(EDIT: fixed formatting.)

In J, user-written verbs have rank _ _ _ (infinite for both unary and binary cases) by default, but you can rerank them with the " operator just like any built-in verb.

Why do I see so few user functions being used? I would expect application code to consist mostly of specific functions but instead I see line after line of unbroken primitive operators.

Lots of purpose-specific functions can be built using composition forms on built-in verbs. The resistance to naming sub-pieces of these compositions is largely a cultural thing but still a point of dispute within the community -- some are very much in favor of giving descriptive names to intermediate results.

Thanks for your response.

    f1a=: 3 : 0
     {. y f1a 0 1x
    :
     if. *x do. (x-1) f1a +/\|.y else. y end.
    )
 
    f1b=: {.@($:&0 1x) : ((<:@[ $: +/\@|.@])^:(*@[))

http://progopedia.com/example/fibonacci/452/

http://dfns.dyalog.com/n_fibonacci.htm

This is a nice introduction into APL:

https://www.youtube.com/watch?v=_DTpQ4Kk2wA

And this is how APL is applied in the right way:

https://www.youtube.com/watch?v=a9xAKttWgP4

  /first n+2 numbers of fibonacci sequence

  fibonacci:{{x,sum -2#x}/[x;0 1]};

  q) fibonacci[10]

  0 1 1 2 3 5 8 13 21 34 55 89

http://www.jsoftware.com/jwiki/Essays/Fibonacci%20Sequence

This:

f0b=: (-&2 +&$: -&1) ^: (1&<) M.

is probably the most elegant solution. It's recursive ($: stands for "self-reference"), memoized, and it works:

f0b&.> i.20

│0│1│1│2│3│5│8│13│21│34│55│89│144│233│377│610│987│1597│2584│4181│

To give an example, / is like fold in a functional programming language, so +/ would be fold (+) in Haskell, there fold (+) :: Foldable t, Monoid m => m t -> t. However you would have a hard time implementing J like arbitrary rank arrays in Haskell efficiently and supporting all the operations it does.

The philosophy of J and K is to isolate the essential operations and laws the data structure you are trying to manipulate has and to implement an interpreter for those operations that is as efficient as possible. This is in contrast to a conventional general purpose language that tries to implement a sufficiently smart compiler and primitives to create new data types from a set of primitives ones. The problem is that it is quite hard and sometimes impossible to teach the compiler retroactively about all the nice properties your newly defined data structure has.

I believe several such domain specific interpreters/compilers could be "stitched together" into a general purpose language, maybe integrated by a system specialised in symbolic computation. Instead of compilation to machine code the top level system would compile down to the base operations for each data structure and simplify according to the laws the base operations satisfy. Haskell and many other do that by compiling down to a Core language and then applying a huge number of simplification passes on that intermediate language.

Just the most basic stuff is pretty nifty: http://www.jsoftware.com/help/learning/01.htm

Haskell is different, the concepts of monad, category and so on allow you to obtain a higher order view of your ideas, to frame them in a different concept, that is experience that expand your concept of programming, I don't experiment that feeling with J, I paid the price to learn the vocabulary and grammar, but I don't think the language is worth the effort.

My hypothesis based on a few conversations: the "burst of enlightenment" is treating problems like "applied math" rather than computer science. I.e., "first represent as a vector, then do linear algebra, iterate this process until < epsilon". Since I already do this in Python/Julia/Mathematica, J just feels like a variant with esoteric syntax.

Possibly my problem is that I'm simply programming Python in J. Can anyone with deeper knowledge of J confirm/deny this?

In J it's much more natural to load a whole dataset into memory and then work with it as a whole. To make it easier, you're strongly nudged to design your data structure simply and uniformly. Thinking about clarity of data structures has many advantages - e.g., clearly seeing the algorithm as a whole, being able to pinpoint (and question) exceptions, optimize on the high(est) level...

That doesn't mean J can't do sequential processing - but if you choose that, you want to understand why: is it the nature of the problem or is it a (questionable) implementation detail?

Some start learning J by using it as a calculator. Indeed, what could be easier in the beginning - typing 2 + 2 <Enter> produces expected result, same for 3 * 4 and 5 - 1, then you have built-in exponent (^3 produces 20.0855), logarithm (^. 20.0855 - kinda easy to remember, an inverse function), factorial (!6 makes 720)... Gradually it becomes less conventional - order of operations is always right-to-left (as in sqrt(sqrt(sqrt 2))) - that would be %: %: %: 2), negative numbers look like _1, _2, _3, sine and cosine are in the family of o. functions - 1 o. 1.5 gives 0.997495, 2 o. is 0.0707372 - and you're also allowed something like 5 + 1 2 3 which returns 6 7 8. A few more iterations - and you can use moderately complex expressions with infix notation, typing quite economically. Then vectorization gradually grows in more complex expressions...

In numpy:

    data = cumsum(bernoulli(p).rvs(1024*16))
    test_statistic = special.xlogy(data, p) * ... other stuff...
    first_pos = where(test_statistic > b)[0][0]

If we translated this code to J, would it be idiomatic?

(Incidentally it does happen to be wildly inefficient - a simple for loop (in C) with no arrays is about 100x faster.)

How are your Blub projects going these days?

Approximate quote from a C textbook: "Besides, C is actually the language made for programmers. Pascal is for students, Basic for housewives, Lego for schoolchildren, Fortran for scientist, APL for martians... Only C is for programmers." First time I saw APL I was suspicious - can it do anything in addition to matrix manipulation?

I do understand your concerns.

P.S. BTW, Dijkstra ones was asking Iverson if APL is actually Turing-complete, or something like that. Iverson produced a typical APL answer for a problem - which wouldn't say much to anybody who doesn't know the meaning of symbols. Just like reading in foreign alphabet.

J works along the same lines: First, you had to accept a "widened" set of mathematical operators with arrays as the core. Which is APL with its funky fonts and keyboards. And J then takes away your more readable, but inconvenient to type notation and replaces it with ASCII. It's a bit like learning calculus with lisp as your first notation...

That's the syntactical hurdle. Then you've also got to get used to the array-centric programming model. Just like stacks for forth, functions for functional programming or lists and recursion for lisp.

As opposed to lisp, I think the syntax is the bigger issue here for a change. You don't just have to change the order in which you read things and ignore some parens, you've got to get over some very deeply ingrained habits, not just from other programming languages, but from normal writing itself. No scanning, neither horizontally nor vertically. The closest analogy for me were regexes, where you can't just skip ahead, either.

Take that with a grain of salt, I'm just trying to get into it myself. Two things that I might want to try out to really grok it are programming in that style in other languages (like the infamous Whitney C example) to adjust my reading style without having to adjust to other paradigms at the same time, and to edit APL with ed, so that focusing on a single line becomes potentially easier.

edit: replaced asterisk with, well, "asterisk". How does one escape that in HNews? backslash didn't work.

Productivity, I think, stems from close connections between program and the thought process.

If this holds for J, K, APL we should all be doing that.

Well, actually, I use for-loops for that, thank you :)

"foreach"-style loops with iterators in many languages eliminate the need for knowing how many element you exactly have, but you still have the code for explicit "take the next element" operation.

Vectorized operations are the next logical step, where the code for iteration ("visiting each one") is completely hidden. So instead of explicit for-loop, or equally explicit map function, you just apply the operation directly to the list and get a list as a result. This is nice, because it eliminates A LOT of syntactic and semantic noise from the code which mainly works with collections.

Such vectorization is available in many languages as a library - for example in Python via NumPy, where you can say "numpy.array([9,6,7]) + 4" and get "array([13, 10, 11])" as a result. In J and APL support for this is built in.

Not so.

I only need to write down 2 lines of code: one line for the for-loop, and one line for the actual instruction(s).

Personally, I prefer explicitness instead of increasing the amount of overloaded meaning of existing operators.

Of course, that's one way to look at it, and a valid one. Most of the time I do too, but I can accept some degree if implicit behaviour if it's consistent and (conceptually) simple enough.

> the amount of overloaded meaning of existing operators

But this is not true in regards to J. In J and other array-based languages the number of overloaded meanings for operators is actually less than in "normal" languages. That's because in J all the operators work on arrays and only on arrays. No operator ever deals with things other than arrays, and in basic J there's just one thing other than array anyway (a box).

In Python this:

2 + 2

and this:

[1, 2, 3] + [1, 2, 3]

are two different operators, but in J (ignore syntactic differences) this:

2 + 2

and this:

1 2 3 + 1 2 3 NB. resulting in 2 4 6

are both applications of the same operator.

There is a certain appeal to languages built on "turtles all the way down" principle - one of the benefits is that they tend to be compact, simple and consistent. On the other hand, when you're not dealing with turtles, they tend to be irritating at best and completely unusable at worst.

Anyway, I'm not trying to convince you to adopt J right now and start using it for writing web apps, I just want to say there are some interesting concepts in J which, while being unfamiliar, are not necessarily worse than the things we're used to. And they're not useless either: a week of learning J made my NumPy code much better, for example.