k vs kona

[sohagan857]

What will k bring us that kona won't?

Look at windows vs linux. Look at ios vs android. Make your own mind up which is better and then answer the question above.

Obviously open source has its benefits as well as several downfalls, but bring in the cost factor and should kona be considered as a big future player? Apparently it has "seen success among small, elite Wall Street teams-http://kevinlawler.com/about". Whether that's true or not, I don't know. 

It's based on k3 and I know k4 brought with it several enhancements and changes, probably for the good, but could kona catch up and begin to be trusted by bigger institutions?

Does anyone use/or has used it?

Links:

k4 vs k3:http://www.math.bas.bg/bantchev/place/k.html

kona: https://github.com/kevinlawler/kona/wiki

Hope to hear your opinions.

Sean

[Ryan_Hamilton1]

Hi Sean,

Interesting questions, my personal opinions would be...

>>"What will k bring us that kona won't?"
1. A program with a core that has been tried and tested over many computer/man-years. The KX team have fixed 1000's of edge cases, optimization issues and OS specific bugs. Any similar system would have to replicate a lot of that work. Possible but it would take time and teams actually using it.
2. A corporate entity to provide support and timely bug fixes together with long term guarantees of availability (not a few part-time committers on github).

As you said, the latest language is k4 not k3. k4/Kdb is both a database and a programming language and it's that combination which I believe gives kdb it's unique power:

- There is no open source database that provides the speed kdb provides for the particular queries suited to time-series analysis / finance.

- k4/q is much more approachable than k3 for most people and reduces the (already steep) learning curve. Despite kdb supporting k3 code very few people actually use it, a languages success depends on a large group of people being able to understand it.

- Combining kdb/k4/q into q-sql means queries require fewer lines of code. I believe this expressiveness combined with longer term use of kdb/q changes how you think and allows easily forming queries which many people couldn't begin to write in standard sql. This is an area I believe kdb+q delivers a lot of value. Kona currently only supports a very limited "sql" but it's ugly and doesn't support large (on-disk) datasets.

The language on it's own is good but as Kona currently stands (in-memory computing language) why would I chose it instead of Python/R/J/A+?
Existing (similar languages) that offer a larger existing user base, more libraries and a proven/stable platform.


>>"bring in the cost factor and should kona be considered as a big future player?"
If kdb can solve problems that other platforms� can't or in a much shorter time, it often adds enough value to easily cover the cost. Kdb's target markets are not particularly price sensitive. In fact many large firms are happy paying a pricey support agreement for free open source software so that they have someone to call (blame) to resolve an issue quickly.��


>>"but could kona catch up and begin to be trusted by bigger institutions?"
I consider it unlikely. To catch up any time soon will require much more project activity than github currently shows. To be trusted will take even longer. Kdb is entrenched and for its target use case it is currently unbeatable. Some people may have use cases that don't need the full power of a time-series database and language combined or have other important factors. I think those use cases have viable open source solutions.�


On a side note, at one time I actually preferred writing k code rather than q code, shorter code and fewer concepts that once learnt are strictly adhered to. Most my colleagues would have disagreed.

Regards,

Ryan

[Ryan_Hamilton1]

On a somewhat related note, an idea I hacked up, was getting q commands to run in java/JVM:
http://www.timestored.com/b/jkdb-java-kdb-functional-library/

[tavmem]

Kona is not attempting to compete with q or with KDB+.

Kona is simply an open source implementation of k3.2.

[AlexB]

"Kdb's target markets are not particularly price sensitive."

Depends on what you consider target market. A few bow-tie engineers in global trading firms - yes, this market is not price sensitive at all. kdb+ license fee is well below daily rounding error for them. But if you look at kdb technology separate from the trading aspect - it is a fascinating piece of software. A language (a damn good one), a database, a built in remoting. It could be a great educational and research tool (timeseries are not exclusive to trading world, you know). It also could be a great tool for small time traders, who want to move beyond Excel. The possibilities are numerous. Not all of them can be directly monetized, but are very important in keeping the technology alive.

Alex Boudarov

[tavmem]

The quote was taken out of context:

Kevin leads the open-source K project Kona. K is a programming language that's seen success among small, elite Wall Street teams. Programs written in K are short and shockingly fast.

Kevin was talking out K from Kx Systems and the success it has had on Wall Street and that K is shocking fast.  I know of no one that is using Kona for production applications, and Kona has a long way to go before it even comes close to the "shockingly fast" speed of K on test applications such as the ray-tracer script from http://nsl.com/k/ray/ray.k.

On Wednesday, March 26, 2014 6:47:03 PM UTC-4, Sean O'Hagan wrote:

What will k bring us that kona won't?

Look at windows vs linux. Look at ios vs android. Make your own mind up which is better and then answer the question above.

Obviously open source has its benefits as well as several downfalls, but bring in the cost factor and should kona be considered as a big future player? Apparently it has "seen success among small, elite Wall Street teams-http://kevinlawler.com/about". Whether that's true or not, I don't know. 

It's based on k3 and I know k4 brought with it several enhancements and changes, probably for the good, but could kona catch up and begin to be trusted by bigger institutions?

Does anyone use/or has used it?

Links:

k4 vs k3:http://www.math.bas.bg/bantchev/place/k.html

kona: https://github.com/kevinlawler/kona/wiki

Hope to hear your opinions.

Sean

[sohagan]

Sorry for delayed reply:

Ryan thank you for your detailed response, the point that did not cross my mind was "kdb+'s target markets are not particularly price sensitive."...I think this closes the issue. I also did not know kona can't handle large on disk datasets. Moreover, I think some of my questions have been answered by the release of a free version of 32bit, but only time will tell if it kicks off. 

I have not done much k yet, but the reason why this question arose is because I have recently begun looking at k and beginning to learn it. Thus I could soon be in the same boat as you and prefer k to q. 

TavMem, I did indeed take this out of context...that's what you get from flying through websites. Apologies...but at least it got your attention.  

Ryan your JVM running q looks interesting. I will have to take a look in more detail.

Good luck to you both,

Sean

[tavmem]

Ryan said:

> "Kona ... doesn't support large (on-disk) datasets."

I'm a bit mystified ... What leads you to that conclusion?