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.
Didn't know that. Thanks! Does Shakti not have the same problem with Python? Or is Python only mostly for visualization once you get back your dataset?
