>Kdb+ has sharp elbows.<p>No shit. I used to work as a quant, and while I was an okay quant and mediocre trader at best, I survived for three years in the industry because of my kdb+ proficiency: the firm I was at spent a couple of million dollars on kdb+ only to find out that most people could not wrap their heads around kdb+ let alone debug it effectively.<p>My (former) colleagues were definitely smart people. In many ways, they were way smarter than myself. But I somehow could get a much better handle of kdb+'s idiosyncrasies, and my ability to stare at dense k/q code (usually no more than a dozen lines) and figure out what's wrong with it earned me the reputation as the "q guy" - and some level of job security.<p>The firm eventually phased out kdb+ completely after my boss and I left (the two proponents of kdb+).
The last line of TFA reads like the beginning of some sort of movie in the drama/thriller category. "kOS is coming. Nothing will be the same afterwards."<p>That's what irritated me most.<p>What I'd like to understand is - what led the author to this particular conclusion? Is it the fact that this language is super expressive and concise? Is it that it routinely [1] outperforms its C counterparts even if it ultimately translates to C? Is the Z graphical interface so superior that it'll blow the pants off Cocoa and Quartz and X.org or Wayland or what have you? Why would one rewrite emacs or vim on it? I don't want some basic 4 line text editor - I would like to be <i>productive</i>. Why would Mozilla spend energy porting firefox to it? Or Google, chrome? Or bash?<p>Simply talking about the history of K/kdb+ and how brilliant its creator is <i>simply</i> doesn't help the reader understand why they should be excited about it. If that was the intention of this article, then the real points to make should've started <i>after</i> that line.<p>That would've been much more interesting.<p>[1] - No pun intended, of course
The same story told again -- it's aim is to generate this magical atmosphere around a fast db engine and language that's deliberately obfuscated to make people who work in it feel smart, so they try to spread that it's the best. KDB/Q is a nice tool, not the holy grail how they put it. And it's not fast because they know something better - it's because it lacks almost any safety measure.
Here's the text editor they're talking about: <a href="http://www.kparc.com/edit.k" rel="nofollow">http://www.kparc.com/edit.k</a><p>The code is, well, not the easiest to understand.
The APL family was developed to think about math and linear algebra in particular. Iverson's "Notation as a tool of thought" f'rinstance:
<a href="http://www.jsoftware.com/papers/tot.htm" rel="nofollow">http://www.jsoftware.com/papers/tot.htm</a><p>If you've worked with such things for your day job, exposure to an APL language is mind blowing in the same way as exposure to Lisp is. You'll rapidly find out that an awful lot of the numerics world is an ad-hoc reinvention of an APL language. Leading thinkers in the numerics world have noticed. Have a look at the Tensor type inside Torch7, or -idx- class in Lush (the same thing): they are, in fact, a sort of APL with a more conventional, aka painfully wordy, notation.<p>Writing an editor in an array language seems crazy, but then, writing a parallel processing system in a language that was designed to run applications in your web browser also seems crazy. If people had stuck with APL style languages, well, databases, particularly distributed databases (Kx and 1010, both K based systems, scale to Pentascale, and have for a long time), would suck less, as would CUDA programming. Their revival could make life easier in these problem domains.
Googled around, Kuro5hin (that's a name I haven't seen for some time) has a tutorial for K from 2002: <a href="http://www.kuro5hin.org/story/2002/11/14/22741/791" rel="nofollow">http://www.kuro5hin.org/story/2002/11/14/22741/791</a><p>The download link at <a href="http://www.kparc.com/" rel="nofollow">http://www.kparc.com/</a> asks for password, so I'm not sure whats going on with that.
The language looks fascinating. Check out Kona, an open source implementation: <a href="https://github.com/kevinlawler/kona" rel="nofollow">https://github.com/kevinlawler/kona</a>
Interesting article. Found this (<a href="http://queue.acm.org/detail.cfm?id=1531242" rel="nofollow">http://queue.acm.org/detail.cfm?id=1531242</a>, submitted here <a href="https://news.ycombinator.com/item?id=8476120" rel="nofollow">https://news.ycombinator.com/item?id=8476120</a>) interview with Arthur Whitney (from 2009) which is also really interesting.
> “It is a lot easier to find your errors in four lines of code than in four hundred.”<p>Looking at his code on <a href="http://www.kparc.com/edit.k" rel="nofollow">http://www.kparc.com/edit.k</a> I'd like to disagree with that statement
There's a contradiction I always see in these pieces: they talk a lot about the importance of using the right data structure. But these languages get their incredible conciseness by not giving you any choice about your data structures; their array type is hardcoded into the language, and if you want to use something else then your code balloons.
k/q really doesn't have to be this unreadable, that's just Arthurs style. Here's some code in C by him for comparison: <a href="http://kx.com/q/cs107/a.c" rel="nofollow">http://kx.com/q/cs107/a.c</a>
I love K/Q and is using it in my startup. Thanks a lot for Kx's recent freeing up the 32bit version. To use APL-like languages I have to really shift the way of designing/modeling things. Most importantly K may not be best for lots of developers working on the same thing. Object oriented languages will fit better in that case. K projects often only involve one or two developers who model things in vector thinking (column based thinking in data domain), know exactly what to do and how to do it. Vector thinking is not suitable for all problems, but works really well if it does. Btw, new 3.2 version of kdb appears to be even faster than before. It also improves websocket integration and JSON data conversion. Very nice to integrate with nodejs/Qt.<p>We also use Forth which I think is a really another way of shifting mind.
I seriously thought that the article, and some of the code examples people are posting [0] was a joke! I need to go rethink my career.<p>[0] <a href="http://www.kparc.com/$/edit.k" rel="nofollow">http://www.kparc.com/$/edit.k</a>
So K is a general purpose programming language? If the claims are true, why don't they submit some entries to the Computer Language Benchmarks Game?
Does a good formal introduction exist for K, or Q, or APL, or J, or any other languages in this family? Something with, you know, a syntax definition at least, and any kind of formal definition of the semantics.<p>The closest I could find is this [1] but "The model is expressed in SHARP APL", so from the start, it's circular.<p>[1] <a href="http://www.jsoftware.com/papers/APLSyntaxSemantics.htm" rel="nofollow">http://www.jsoftware.com/papers/APLSyntaxSemantics.htm</a>
I wonder what K would look like with bit reader-friendly syntax. I tried running a program that supposedly "will take a K expression and produce its English translation" (<a href="http://kx.com/a/k/examples/read.k" rel="nofollow">http://kx.com/a/k/examples/read.k</a>), but either it doesn't work with kdb+/q or I can't figure out how to use it. Does anyone have some example output, or advise?
A language/kernel/db/ui to watch. Reading the comments here, it seems the language separates the wheat from the chaff; the average brogrammer won't he able to handle this, but many of us are very interested in exploring.<p>An OS this small is incredibly exciting to me.
Worked at Morgan Stanley's fixed income desk many years ago as my first job after grad school, programming A+. It was a decidedly acquired taste. The language and style were utterly alien to anyone coming from a background in C (and at that time an early version of Java.) While A+ was fast for manipulating arrays (much of what the trading floor needed), it seemed that doing GUI development with A+ was really pointless. The speed of the language didn't matter in GUI interactions, and it was very hard do understand other people's code.
So, I read about the fast interpreter and small language. How do something like this?<p>"Whitney’s strategy was to implement a core of the language – including the bits everyone thought most difficult, the operators and nested arrays – and use that to implement the rest of the language. The core was to be written in self-expanding C. As far as I know, the kdb+ interpreter is built the same way.<p>Unlike the tall skinny C programs in the textbooks, the code for this interpreter spills sideways across the page. It certainly doesn’t look like C."<p>This mean that the code is very unreadable C? Like a kind of code-golf?<p>How replicate it for built a speedy interpreter? And what if I use lua or python instead?
I hate to love KDB because its a very expensive closed platform. But if you understand some of the concepts and how easy it is to achieve those concepts with a few lines of q code you can do some brilliant things. Yes, KDB is a great data store and provides very quick methods for crunching that data with its vector-based approach.<p>However, whats really impressed me with KDB is that you can do so much more with it. In some banks it has effectively become the messaging middleware for connecting hundreds of disparate data sources. In addition to passing messages you get the data storage and analytics tools for free...
This seems to be a very fun language to write in, in the same way optimizing assembly code in the ancient times was fun; the age of skilled artisans. Unfortunately (for programmers - great for the rest) now is the time of a factory worker. Due to that, I don't think this language and its platform has a long future.<p>Its continued survival is rather a testament to excellency of marketing (as evidenced by this article!) rather than actual merits.
> kOS is coming. Nothing will be the same afterwards.<p>There seems to be this strange idea going around that if we just get the right tool, everything else is going to change forever. I see this a lot with people trying to create IDEs that let non-programmers create programs without really knowing how to code.<p>But the thing is, most people just don't have anything worth coding. The problem isn't that the tools don't exist. They do, even if they aren't perfect. It's that making something that matters isn't an easy thing to do. And no tool can change that.
I don't buy this story. Maybe kdb is fast and great, but the article attempts to describe it as a work of a genius, better than anything else because it's 100 lines of code, doing its own memory management and running on bare metal. But in fact many other programs do their own memory management and can run on bare metal. JVM or .Net do their own mem management, all database servers too, and many, many others. So what's left on the table? 500 lines of C code that's meant to change the world? I really doubt it (or, these guys arent using line breaks). We've read so many similar stories about Lisp and how it's one language that can do everything in 5 lines of code or how you can build an entire OS and all applications in Lisp, but where's that OS now?
Every ten years, some company comes around and claims that their functional/data flow/columnar/meta shortish is orders of magnitude better.
Usually, the one thing they have going for them is that they focus on only a small subproblem. That lets them be small. Every demo is one of no edge cases, no exceptions, and no I/O errors. (Or they cram all that into some "standard" library.)<p>The real challenge is that, 99% of the time, requirements and integration is what kills you, not raw performance.
For the cases where performance (or formal correctness, or whatever) matters, the main challenge is usually to convince the market that it's worth paying for, and then finding the right developer project match.