Performance depending on your use case. APL/J/K can be very fast for an interpreted language, but they won't beat C, C++, Fortran, and Java in most cases.
Also, think about distribution. With most of the array languages, it is commercial, so I'd be cautious about building a business around it. With other languages, it is free to use and deploy as you see fit and some have binary executables that don't need a runtime. K is very expensive. Dyalog APL is pretty reasonable, but still costs money to use and royalties in certain situations.
I think any decent developer can pickup array languages, but many won't want to as they'd rather have something more mainstream (Java, JS, C++, Python...etc) on their resume. So it might be difficult to hire.
> 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.
> With most of the array languages, it is commercial, so I'd be cautious about building a business around it
K/Kdb/q seems very happy with this state of affairs, which is really strange: if they O/S'd it I could see a lot of goodwill/mindshare going their way, but I think their Morgan Stanley roots view O/S as commie nonsense. Meanwhile, it's definitely viewed as legacy in the bulge-bracket banks that use it b/c it's so hard to hire for, not to mention its limited applications for teams (kdb is NOT a good multi-user database). However elegant it may be, it's doomed to be a COBOL if this is where its main userbase stays.
J is open source, but I can't get a handle on how battle-tested it is. It always seemed like Kdb was the real product that got used in anger.
Personally I think array-heads should spend more time with Haskell, since it has the ability to be massively terse and point-free, has type inference, loves infix gobbledygook, can be tuned for great performance, and is thoroughly open-source.
K/Kdb/q seems very happy with this state of affairs, which is really strange: if they O/S'd it I could see a lot of goodwill/mindshare going their way
It's not too hard to grok: if they freed it, they'd lose money. $200,000,000 in revenue last year from Kx alone. Goodwill compared to cash, executive picks cash every time.
I have no idea what Shakti's doing, but they, too, are probably making a substantial amount of money.
> I have no idea what Shakti's doing, but they, too, are probably making a substantial amount of money.
I'd think AW would be more concerned about legacy and impact than just $$$ at this point -- tradetech has long stopped being a significant source of innovation in computer science as it's essentially iterating on the same problemset from the 00s.
OTOH I suppose having a small cult has its benefits, as opposed to actually giving something to the larger world, O/S isn't exactly a cakewalk.
This is the annoying thing about this software niche. I have zero information on Shakti. Their website just says some buzzwords and has a contact link. You can download it as an anaconda package or something, but I don't understand the license.
I'm not an expert in either language, but have played with both and APL is much easier to experiment with and less hard for me to grok than Haskell. Both have REPLs, but there is a lot of additional ceremony with Haskell (for good and bad). I don't see a huge amount of the APL crowd going to Haskell. Yeah it has terse operators and points-free, but it is more the sum of the whole kind of thing.
I agree and don't mean to imply Haskell has an out-of-the-box K/APL experience. More that with it's syntactic flexibility, one can imagine offering a k-like DSL/library in Haskell which would then give you access to its ecosystem, freely distributable apps, etc.
No problem and I like you're thinking, but honestly just want a free and open source APL or K language that is part of a lightweight download (a few MB) that can also create zero install executables that bundle the interpreter. There are a lot of toy projects out there, but nothing really close to what I want. I'd build it myself if I had the time and was significantly more talented :).
Also, think about distribution. With most of the array languages, it is commercial, so I'd be cautious about building a business around it. With other languages, it is free to use and deploy as you see fit and some have binary executables that don't need a runtime. K is very expensive. Dyalog APL is pretty reasonable, but still costs money to use and royalties in certain situations.
I think any decent developer can pickup array languages, but many won't want to as they'd rather have something more mainstream (Java, JS, C++, Python...etc) on their resume. So it might be difficult to hire.