Hacker News Reader

Some additions:

The major difference separating j from k is that the former is optimized for multidimensional arrays (_i.e_ math), while the latter is optimized for vector processing (_i.e_ financial data) and uses lists of vectors when working with higher dimensions.

J is also fast, but not for the same things as k. It's interpreter is also designed to fit in the cache.

Dyalog APL has been experimenting with bytecode compilation, although I don't know whether it's implemented in the current version. It also has a gpgpu extension with restrictions on the language (Co-dfns). Unlike j, APL does not implement operations such as matrix multiplication by calling to BLAS, so if you're doing matrices on the CPU, use J. As an aside, j also shines for graphical output with its opengl bindings and its 2d/3d Matrix viewer.

BTW Jd is indeed commercial, but is free to use in non-commercial applications.

Personally, I think that k is much more popular on hn because they're aggressively promoting it. J is better if you're not doing financial work.

> j's interpreter is also designed to fit in the cache

  $ du -sh /usr/lib/j9/bin/libj.so
  3.2M    /usr/lib/j9/bin/libj.so

Might be a tight fit...

Kdb k is only 771kb, and shakti k is 120kb.

On K - there are now two "real" implementations, one by Kx Systems (i.e. the version under the hood of kdb+) and one by Shakti (new company from Arthur Whitney, original author of k). The Kx one is k4, Shakti is k9. Having said that, k9 is still quite a "work in progress", don't think it's considered production ready yet.

May also be worth nothing that k4 is essentially "undocumented" and Kx encourage to use q instead of writing any code in k directly. Most functionality can be pieced together using docs from other versions of k (I think k2 manual is floating around online) & the docs from q.

I thought Shakti started at k7, and k5 and k6 have also a Kx implementation. BTW, https://ngn.bitbucket.io/k.html is a great overview of K implementations and which version they are implementing.

edit: k5, k6, k8 were apparently never released (https://aplwiki.com/wiki/K)

Yep, for a while Shakti was k7, but then Arthur started over & it became k9. Not sure what happened with k8

k5 was also known as "kOS" and was to be a version of k as a full OS that could run directly on hardware - I believe that got abandoned due to the pain of writing drivers

http://archive.vector.org.uk/art10501320 - article about kOS before it was abandoned

How does q relate to K? I dabbled a little but the distinction was never clear to me.

The main difference is the introduction of qsql (SQL-ish statements can be treated as expressions) and some utility functions that are defined in K. QSQL is mostly for business analyst folks, and is just syntax sugar over the K-native `?` and `!` functions (which is more powerful than qsql).

Q is K syntactic sugar to make the system easier and more "traditional".

q is k with all of the monadic verbs being replaced by English words: `+` is `flip`, `=` is `group`, `-` is `neg`, and so on. It also has q-sql, a SQL like sublanguage for conveniently working with tables. k has the verbs that implement it, but they're not really as convenient.

J came along particularly to fix the ASCII problem, but it took some design decisions for things that were bugging Ken Iverson from years of APL work, that var[4] style indexing is really a function application, that all functions should have configurable “rank”, that tacit programming with trains of functions should be a focus, among other things.

Many of those choices have been added to Dyalog APL since then, SQUAD indexing function, trains, rank adjustment operator.

Dyalog APL has traditional APL functions and keywords which looks a lot more procedural than the golfed symbols mostly shown - for loops, if statements, etc. which GNU APL has not, IIRC; and has an object system :Class and a bridge to the .Net framework and C# interop both ways, GUI support possible through that (Windows Forms I think).

> APLers hate the successors, because "notation is tool for thought" and ASCII is a poor representation.

I'm perplexed by this one. I'll concede that the APL symbols are prettier but why does it magically stop being a notation just because you use combinations of ASCII symbols. Especially when many APL symbols are composed of units themselves.

⍲ vs *: One is 'notation' because it has the two units stacked on top of each other and the other is not because they are stacked horizontally?

At least one person [1] has played with using APL symbols in J, at least at the display level. I gave it a try, but was surprised to find that I preferred the ASCII version. Perhaps if J had its own custom symbol set (extended from APL?) it might have been better -- not all of the APL symbols have exactly the same meaning in J, and I remember finding some of the differences to be a bit jarring. For example, conjunctions like '&>' and '&.>' are heavily used and deserve their own symbols -- just putting a little-circle before a '>' feels like a hack. (No disrespect intended to the author, though, this was a great experiment.)

[1] https://wjmn.github.io/posts/j-can-look-like-apl/

If a symbol is made of multiple side-by-side ASCII characters, are there any problems telling where one symbol ends and the next starts?

In ordinary text, we separate words with spaces, and add punctuation at the end of sentences to further make the structure apparent. (Well, now we do...a lot of pre-modern writing would justwritethewordssmushedtogetherlikethis [1]). In most of the sample programs in APL successors I've seen there usually didn't seem to be space between symbols.

[1] https://www.bbc.com/culture/article/20150902-the-mysterious-...

Yes, at least for me, trying to learn it. For example, / in many examples is an "adverb", modifying the previous operator, although xx/ is frequently introduced as a single thing. (Are all built-in verbs one or two characters?)

'xx/' is a single thing -- in the sense that 'xx' is a thing, and '/' is a thing that modifies other things. By applying '/' to 'xx', you get a new, standalone thing.

Re: one-or-two characters, there are a few exceptions, like the folds ( F.. F.: etc.) which are new to J9. Also some older ones like {:: (Map) and &.: (Under) where `x u&.:v y` means `v^:_1 (v x) u v y`. Some of these aren't verbs but conjunctions, adverbs, etc. For the most part they stick to one or two. There are parsing rules that dictate what the second and third characters can be (that's why you see so many colons and periods), and these rules are actually discussed in the JforC book.

Reading J can be tough, as a fellow learner I feel your pain. :) The one that usually gets me (in my own code, even!) is

    5 myverb \ n

...which runs the verb over 5-element slices of 'n' at a time, and joins up the results. The '5' is too far away from the '\', and it can be hard to see the connection right away. I understand why it's so (it's really running the modified verb 'myverb\' with arguments 5 and n) but I still find it hard to read.

When writing my own code, I often leave extra spaces between the multi-character words, and anywhere else that helps legibility. J might be a terse language, but there's no point being crazy about it (unless you're golfing).

No idea about APL languages but it sounds similar to asking whether the code is uniquely decodable:

https://en.m.wikipedia.org/wiki/Variable-length_code#Uniquel...

I've wondered that myself, because the zoo of symbols doesn't speak to me, like iota, but maybe the mathematical use has something to do with the APL use.

So I simply assume there is something deeper going on than "it looks ugly". Maybe someone here is in that camp and can tell us. At least the argument was made on HN in some earlier APL or J thread.

There is something I call "the whiteboard test". I work in research, and I spend a good part of my time working with formulas in whiteboards and discussing about them with my colleagues. I am constantly confronted with the irregularities and limitations of standard mathematical notation and see APL as a huge improvement, I would really like to use it more, and I have even taught some basics to colleagues so we can use +/ for sum and ×/ for prod, or ⌈ and ⌊ for max and min, for example.

Iverson solved some remaining inconsistencies in J, and it includes some elegant concepts as tacit programming (+/ % # for the arithmetic average is beautiful) that were not in the original APL, but I do not see myself writing J in the whiteboard or a notebook.

But ASCII may not be the main problem. Curiously, I find that K performs much better in my whiteboard test than J, perhaps because the set of symbols is much smaller. And if you think it may be a matter of getting used to it, I have worked with APL far less than with J and still find the APL symbols more appealing.

There are many things I like about J, and I do not have a very rational explanation to give you, but I agree with those that say that APL is a better tool of thought.

Are you really saying that non-ASCII is notation and ASCII is not? When I read your first comment, I understood it to mean that better notation is better than worse notation.

I'm not saying that. Some APL fans say that ASCIIfication of APL is a bastardization, because notation matters. (search through earlier HN threads)

Notation is obviously a shorthand for "sensible notation" or even "better notation" there, because obviously just about anything can be notation. Including laying out pebbles on a beach.

But further than that, I don't know.

The usual argument is that "one should APL like one reads music", meaning that with experience you immediately recognize specific patterns which help you understand what is going on. As for why ASCII can't do that, only the critics know their true reason, which I suspect amounts to "it's different from what I'm used to". I've done both, and I found J notation no more obscure. Critics should also note that (Dyalog) APL departed from APL2 to copy many J patterns, so it appears difficult to argue that J was such a mistake to begin with.

Some people hold prejudice against parentheses and prefix notation, for others it's ASCII...

ASCII is a much smaller space of possible operators, so an ASCII-based language is always going to end up significantly more verbose than one that allows non-ASCII symbols. I don't use APL but I definitely appreciate being able to write ≤ or ⊆ or ∀ if that's what I mean, rather than having to expand those out in ASCII.

≤ "expands" in J to <: Definitely not more verbose.

J uses . and : as modifiers to a base operator to create a pretty big set of primitives. See https://code.jsoftware.com/wiki/NuVoc

> ≤ "expands" in J to <: Definitely not more verbose.

I mean, in a fixed-width font (as people tend to use for programming) it's literally twice as long. That adds up.

Actually, J is often less verbose than the equivalent APL, hence its use for code golfing.

This is less true since APL has begun integrating J semantics and operators, but still..

I should have used the full sentence. Why does it stop being "notation as a tool of thought" See comments like this one https://news.ycombinator.com/item?id=20732924

https://i.imgur.com/sJJWBtq.png

> J: ... slower than K

This is debatable. Given the clause in Kdb+ on demand license [0], it is healthy to give all the published performance figures the benefit of doubt.

[0] "1.3 Kdb+ On Demand Software Performance. End User shall not distribute or otherwise make available to any third party any report regarding the performance of the Kdb+ On Demand Software, Kdb+ On Demand Software benchmarks or any information from such a report unless End User receives the express, prior written consent of Kx to disseminate such report or information." -- https://ondemand.kx.com

J is a general-purpose language. It is oriented toward math and data handling far more than K.

Speed relative to K, for example, is largely dependent upon what operators are used, with what size and shape of data. Certain operations in J are highly optimized, comparable to C (or exceeding) what you'd find in matrix math libraries.