Hacker News Reader

Comment by kinleyd | Hacker News Reader

Recently I've been dabbling in q and kdb+. Would there be any benefit to dabbling in J instead?

J is probably the best language in the world to craft native GUIs (something k could never do very well, and now doesn't do at all).

It also has a wonderful amount of books on it, most of them Creative Commons-licensed now (as all/most of Iverson's books are, I believe). It's significantly easier to learn for someone new to array languages yet who doesn't have the sort of hands-on training you can get with APL & k; you could go into the woods with nothing but the J interpreter tarball for a week and come out pretty having internalized the language, and it's even easier with some of the other books available.

It's, of course, free software.

> J is probably the best language in the world to craft native GUIs

How is that the case? I don't really see a grid system or anything like that. I much prefer delphi or wpf or something.

> J is probably the best language in the world to craft native GUIs

Erm, jqt is nice, but it ain't that nice! It isn't exactly native either.

I was kinda thinking the exact same thing with regards to J.

Btw Scott, I've been meaning to ask you about what tools you're using for your work for awhile, but don't see an email address anywhere on your blog.

It seems like you've tried Lush, Clojure, Lua (Torch 7), J, R, and a bunch of other technologies. I've had the chance to try some of these for hobby purposes, but nothing for work yet, so I would trust your evaluation more than mine. Have you given up on array languages all together?

I use R for most data science, J and C for hobby/future development on the rare occasion I have time. Never touch the others.

Ah, so Clojure and Lush didn't stand the test of time. Good to know.

Lush is worth people's attention for its design, but I didn't feel like getting involved with language maintenance: my strengths are elsewhere. J also solves all the problems Lush did and has a larger user community.

Clojure was cool, but JVM is basically worthless to me.

Same concepts for the most part. I think K is a bit easier to understand and if you're lucky enough to work with a kdb+ system, I'd focus on k & q to be honest.

Thanks. I downloaded the 64bit "on demand" version of q, kdb+ and have been toying around.

q and kdb+ would be the better choice in my opinion. I feel as if there is better documentation, books, and resources for q than J/k

q and k are both part of the kdb+ database software suite. K is the language and q is a DSL wrapper over k with SQL primitives.

J is an entirely different language and I think the doc is actually pretty decent. There are free books and tutorials and books you can buy on Amazon.

I know I can escape into the k interpreter with a \ (backslash)

I don't know how to find the documentation for the k version that is shipped with kdb+ (free non commercial download). I only find broken links (it seems they removed the k documentation from kx.com website?)

It seems to be deliberately undocumented.

This might help a bit:

https://code.kx.com/q/basics/exposed-infrastructure/

http://kparc.com/k.txt

(Look up Q docs for monadic K operators by their english name)

There is no built-in help with that interpreter? I know Shakti K has built-in help.

I downloaded Shakti too but found no instructions. How can I access the built-in help?

I found \h by trial and error

Shakti seems to be the new flavor

The creator of kdb+, the k language, and the q-sql DSL sold his share of Kxsystems (company that makes kdb+) to start a new venture called "Shakti" with a new version of his "k" language. Kdb+ is still around and developing, so I'd say they're forked at this point.

When a q like language is implemented for Shakti, I'll definitely switch. I personally find q a lot more comprehensible than k.

I've taken a look at that as well. It seems to be heavily in development at the moment, though I'm keeping my eye on it.

Reply on news.ycombinator.com