Hacker News new | past | comments | ask | show | jobs | submit login

> APL/J/K can be very fast for an interpreted language, but they won't beat C, C++, Fortran, and Java in most cases.

Do APL/j/k/q work well for some performance-sensitive situations but not others? Some of the comments here by people who appear to be very familiar with the language make it seem like it performs quite well compared to the traditional high-performance languages.

Distribution is definitely something I hadn't considered; I guess I've been spoiled by the variety of free/open languages available these days.

I've always wanted to try to pick up an array language to expand my horizons a bit (e.g., that one bit of advice that programmers should learn one of the four main types of languages --- ALGOL-based, Lisp, functional, array-based), but I just haven't had the time.




Worth noting that most APL interpreters and the J interpreter are significantly slower than (most) k/q interpreters. I'm not sure if the performance argument is relevant for all of them.

Arthur Whitney's a biased source, of course, but the kparc site has a bunch of little programs in which he beats the equivalents from rather influential people (like the UNIX/Plan 9/Inferno authors http://www.kparc.com/z/bell.k ) for bragging rights.

k losing to some really nicely-written C and most Fortran seems plausible, Java and C++ not so much.


Is there publicly available information on what makes k/q interpreters so much faster? Or is that part of the secret sauce that the companies maintaining those interpreters sell? I assume it's the latter, but hope for the former, since good descriptions of the technical work that goes into high-performance systems usually makes for fascinating reading.


So the language isn't really amazingly fast from certain benchmarks I've seen like fibbonachi, but the entire integrated database solution for analysis purposes is very fast. I wouldn't do high frequency trading or high performance scientific computing in it, but data analysis is great.




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

Search: