Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


All 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?


Hyperbolically, 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.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: