3 ms·
Just to add, because J is an array-oriented language, it makes some kinds of column-oriented access patterns easier. For example, it's trivial to sort one arra
by hoosieree 5y ago
Just to add, because J is an array-oriented language, it makes some kinds of column-oriented access patterns easier.
For example, it's trivial to sort one array by the values of another array:
x /: y
To me, it's much easier to read than the equivalent in NumPy:
x[np.argsort(y)]
Or get pairs of (unique value; count) from an array using the key operator (/.):
(~.;#)/.~ y
Column db's make sense for array-oriented languages, because there's much less of a mismatch compared to OOP with relational.
- legalcorrection 5y agoAll of that syntax is awful. Why not just x.sortBy(y) ? Did all of the advances in software legibility fail to make their way to the modern scientific computing world?
- moonchild 5y agohttps://www.jsoftware.com/papers/tot.htm https://www.jsoftware.com/papers/tot.htm
- avmich 5y agoHyperbolically, because you don't write math with variables in camel case. J traces its roots from a notation for math, used on whiteboards. That awful syntax you see - it's the same as in some formulas in, say, general relativity, only J is Turing complete and not a Turing tarpit. When you work on a formula, in case of J you have ability to execute it, and if you see it's wrong you can update the formula and try again. This could also be done in other languages, but in J (I mean, APL family of languages) it's more focused. In defense of J, I had a professional example of a problem which wasn't clearly specified, which needed some experimentation - that took, if I remember correctly, some 45 minutes of attempts in J, and then the prototype was re-written in C#, when if was already producing desired outcomes. Rewriting took somewhat longer.