Not really sure... people started talking about it on the mostly dead /r/apljk subreddit last week which caught my attention. It appears Arthur Whitney left Kx Systems and started his own company again. I'm immediately suspicious when I see "blockchain" in something, but Arthur is a bit of a legend. I don't fully understand why it is bundled as an Anaconda (scientific and data analysis oriented distribution of Python), but I assume a library is utilized there for machine learning or something like that (hopefully someone can comment and tell us what). You can type in "/" in the REPL to bring up the help menu showing the various symbols and what they mean monadically (when taking one argument) or dyadically (taking two arguments). As usual though, their website seems to have virtually zero documentation like they want to stay obscure. I'd love if someone in the industry that can afford to use these products can tell me what Shakti looks like it would be used for. Is it the same as kdb+ mostly with a few added features?
Haha. Same here for Red. I understand why they did it (it seems like they wanted blockchain and crypto currency to be their killer app), but I'm worried it was just a costly detour. That is their decision of course though and best of luck. The other thing they're doing (if I understand correctly) is creating a second code optimizer that is a paid product. So the default compiler created slower code than the commercial one I think.
I'm also still waiting on kOS, but I'll never be able to afford it, so not sure why I'm waiting on it.
Anaconda (scientific and data analysis oriented distribution of Python)
While that was the original and still by far most common use case of Anaconda, it has greatly expanded over the past couple of years into a more general purpose software environment packaging tool.
I think the reason it's in anaconda is they're trying to go after the python crowd? Regain some of the data analysis market share that stuff like numpy took from APL.
I see a lot of niche languages like Dyalog APL doing the same thing (building bridges to Python), but if I really have to use Python, I'll just use Python. Not a hybrid of the two. Maybe that's just me though.
Think about it as an extension to e.g. K/Q's strengths. What if you would like to visualise certain aspects of quote/trade data? It could take a very long time to process the data in Python and it is difficult to visualise data from within kdb+. Seems to be a good match.
I know what you're getting at, but how hard can it be for a software company that makes millions (my assumption) to add a charting library as a native option with a verb for linechart, scatterplot, barplot...etc? They could just bundle the C++ JUCE library and then their users could create all sorts of GUIs and charts. I've seen other commercial products do this and it seems to work well, but I can understand them not wanting to include 3rd party code and pay a licensing fee. Still...I'd rather have a native way to do charting within a language rather than spin off a Python interpreter with Matplotlib. It just doesn't sound like a rapid prototyping process if you have to do that. I think I read before that they used to have a simple chart library, but removed it to keep the product tiny. I assume they know best, but don't know their reasoning. Thanks for the discussion though.
This reminds me of using F# to call out to R. If I have to do all that work, I might as well just use R :). I realize there are some edge cases where that is nice though and that not everyone is as bothered by that as me. It seems like the context switching is inefficient.
They used to have it years ago in K2, a dynamic GUI that updated as the values updated. Arthur's brother wrote it.
It used an interesting idea that exapanded on the ideas of dependencies and triggers to also include GUI updated. There were some special attributes that described the layout of the variable, and you did `show$val to display it. As the value of val changed (and all other values it touched or included), the GUI would updated for you.
Well, I think you guessed the reasoning already correctly: The use cases of kdb+ all are so much concerned with performance, that it even matters if the whole binary fits in the CPU cache. That's certainly the reason why the GUI stuff was removed after K2. Similarly was the removal of almost all system calls in the pre-kOS prototypes. It must be very interesting to work on such a system, squeezing every possible bottleneck.