[scottyelich]

... and can you use the 32bit version in commercial use? (Last I checked, no...)

The license already changed once (for the worse, IMnsHO), so what's to say that won't happen again. Too risky to touch.

No, can't use it (32bit version) for commercial, so this is a non-starter. Sorry.

kOS? really? https://news.ycombinator.com/item?id=8475809

[beagle3]

You can purchase a license if you want to be unaffected by future license changes. It might not be the right price for you, but it is for some. They are, in fact, courting only rich customers.

Some languages are worth learning to expand your horizons. Lisp is one of them, even if you never use it, and the APL family (of which K/Q are members) is another. My C code has become faster, simpler, shorter and less buggy after I dabbled in K. YMMV, but using it in a commercial setting is not the only reason to look at it.

> kOS? really? https://news.ycombinator.com/item?id=8475809

Really. What exactly is your "really?" question?

[vram22]

>My C code has become faster, simpler, shorter and less buggy after I dabbled in K.

Interesting. Can you explain why you think that has happened?

[beagle3]

Several things:

1. K (and the entire APL family) eschew many of the layers upon layers of abstraction that modern software engineering uses, whether they are justified or not. It turns out, that they are mostly not justified. K gently pushes you toward thinking in a lower level of "what's really happening here?"; I'm not sure I can give a good example here - but the world looks different after taking the red pill. e.g., it is not uncommon in K to represent a tree as an two arrays, one of data, and one of parent pointers. Once you shake the "but I must abstract this!" feeling, you realize it works better.

2. K gently encourages doing work on batches of data. That is, it is idiomatic (and easier) to write functions that operate on arrays, and return arrays of processed data, then writing functions that operate on one element at a time. In turn, this means that the resulting program more often than not works in stages where each stage processes its entire input before going to the next stage (which uses the output from this stage as its input). In the "old" C/C++/C#/Java/Python world, it is idiomatic to push each element through a pipeline before going to the next one.

3. K encourages building a set of orthogonal, non trivial operations and combining them in various ways, rather then building layer upon layer of abstraction. It gives an example by giving an extremely useful basis of functions. E.g. http://nsl.com/k/t.k implements a very fast, reasonably capable in memory database with aggregation, joins, projects and more. It takes all of 14 lines, all quite short. While you can't implement it in 14 lines of C, using the same principles you can probably do that in less than a hundred. Achieve the same in idiomatic C is going to be much harder and longer.

4. Finally, K gently encourages solutions which work well with modern memory and storage hierarchies. E.g., it encourages linear scan operations that touch all elements of an array over random access ones that touch only 1/10 of the elements. Instinct and idiom in other languages will guide you towards the latter, but the former is often much faster.

[hoosieree]

This is my experience as well, especially with respect to the "layer upon layer of abstraction". Abstraction isn't bad, but it's notoriously hard to do well.

[vram22]

Also, I had been looking at J (again) recently, and noticed that it has a similar concept of composing operations as K does. I guess it is because both are from the APL family of languages, as shown in the "Influenced" section here:

https://en.wikipedia.org/wiki/APL_(programming_language)

[beagle3]

Yes, APL is the ancestor; Arthur Whitney wrote A, a miniature APL interpreter which inspired Roger Hui’s implementation of J (designed by Ken Iverson who previously designed APL).

J optimized for purity, K for practicality.

I remember reading a commentary from Iverson that, despite J’s beauty and theoretical niceness, at least two practical choices made by K turned out to be better:

1. Doing left-to-right scan and fold; this is inconsistent with parsing, but turns out to be significantly more useful

2. K’a minimalistic currying (juxtaposition) is not as nice theoretically as J’a trains and forks, but turn out to be much more useful in practice.

However, I don’t remember where I read that and cannot find the source now.

[vram22]

Got it, thanks. Agree about the layers of abstraction. In fact, a similar example, though from BASIC: way back I had read a very good book on it, in which the author showed the creation and use of many data structures and algorithms using nothing but arrays, and indexes as pointers to other elements (in other arrays). It was not difficult to follow, either.

[greglindahl]

I'm confused what the relation is between alt-right ideology ("red pill") and the usual things one does for high performance.

[megaman22]

Red pill is originally a Matrix reference...

[greglindahl]

Yes, and just like Pepe, it has been adopted by a community and no longer means what it originally means.

[scottyelich]

Don't get me wrong... I love kdb+/q ... I want kOS. I love forth (bare metal forth + tcp? win!). I just don't really do much with them, though, other than play.

> Some languages are worth learning to expand your horizons. Lisp is one of them, even if you never use it, and the APL family (of which K/Q are members) is another.

Exactly.

I have more than one hammer.