Earlier quoted context omitted.
I tried cleaning it up a bit: https://gist.github.com/lukechampine/f54fce8fd756254cefb2 But the actual meaning of the program is still lost on me. I can only guess it has something to do with parsing files (note the checks for curly braces). Feeding it its own source code produces some output, but I have no idea what it actually modified.
The original is 404ing, do you have a mirror?
Impending kOS
121–130 of 242 posts
Re: Impending kOS
#122Earlier quoted context omitted.
It is a fun environment and the community is very friendly and smart too. Its widespread adoption in finance is because it is a proven tool for processing the huge datasets that other systems cannot. If you have a business case for that, clearly it can be a worthwhile investment. Other industries are beginning to see value in leveraging their data sets and that's probably why after being in the business for 20+ years…
can someone please give example on how the pharma industry is using this?
This might be what you're looking for..http://kx.com/_papers/Kx_Pharma-Vertical_Markets-140502.pdf
Re: Impending kOS
#123Earlier quoted context omitted.
It almost sounds like kdb needs an alternative syntax that is more human readable.
It has one: q. But once you get over the syntax, you realize that you also need to grok different semantics that you are used to. Some q is readable english - e.g., an expression like sum price where size>3 is (to the uninitiated) more readable than the equivalent k +/price@&size>3 but that only works for simple stuff. The (idiomatic!) computation of maximum-subarray-sum[0] |/0(0|+)\ becomes max over 0 (0 max +) scan…
The q in your latter example is the same complexity in my book as a dense Python list comprehension. Could be worse.
Re: Impending kOS
#124Earlier quoted context omitted.
I'll give this a shot. I'll try to explain what's in my mind as I read it as well. First, get out the reference manual: http://kparc.com/k.txt and we'll do the first couple lines. The sequence that goes f x applies x to f. this f is unary. The sequence that goes x f y applies x and y to f. this f is binary (and just labelled verb). Some things (adverbs) go f a x and apply f in some special way to x. Last hint: You re…
I have one question. I learned some J some time ago, but never really talked about it with anyone, and so my programs - a few lines' scripts, really - were always written with long, meaningful variable names. I read your explanation and every time you wrote "we don't know what it is yet" I wondered "why the heck isn't it just appropriately named?". I mean, why is 'c' better than something like 'nl_pos' for example? I…
My guess is that the language's "day job" uses many similar-but-ever-so-slightly-different intermediate variables which are difficult to descriptively name in any manner that facilitates understanding faster than just re-reading the definition. Long descriptive names have a concrete cost: they impair your ability to recognize visual patterns / turn common compositions into "pictographs" and they don't refine well: instead of gaining an index and adding a bit to the definition the author has to come up with a bundle of new similar-but-slightly-and-meaningfully-different names from which someone else (including their future self) will be able to reverse-engineer the definition.
The shortcut of using descriptive names just doesn't have the same ROI in all kinds of code. The first time I was forced to abandon my descriptive-naming ways was when I started writing finite element solvers. I don't think it's much of a stretch to believe that (some areas of) finance have the same cost/benefit profile. Since this is a desktop programming example it's relatively easy to come up with good descriptive names, so the short names are almost certainly a holdover.
Or it's just a macho thing. There's enough pixie dust floating around this press release that I wouldn't be surprised.
Re: Impending kOS
#125Earlier quoted context omitted.
How much are you planning to opensource? I realize you have a thriving commercial software company and that's cool. But...wow. This is exactly the sort of thing Alan Kay's team has been working on for the past five years, and you guys seem to be beating them to it, with a completely different approach. It would be pretty amazing to be able to dig into it, find out how the whole system works, and contribute.
I'm not actually employed by kx, so I can't say for certain. I don't think Arthur's opposed to open sourcing bits though.
Would it run under Kona? [1]
Re: Impending kOS
#126Earlier quoted context omitted.
Yes, the research literature on software development has consistently found that code size is the best measurement of complexity and predictor of error rates. (Sorry I don't have citations handy but we've discussed this many times on HN, and there's a recent study in the book "Making Software" that adds to it.) What's interesting is how strongly this goes against what most people think they know about good programmin…
If someone produces smaller and faster code than me, then I should want to learn from it. I wonder why other people have the exact opposite reaction. Why do you think that is?
I do enjoy learning about such things, but, for most of the work I do, performance is nowhere near at the top of the list of things I care about. Also in the past I've been burned by code that's small/fast but is otherwise utterly unmaintainable. I'm not saying that's the case here, but... past experience, and all that tends to color perceptions.
I think with a language like k or q, which appears to be purpose-built for certain types of problems, people look at it and get easily confused and discouraged because it's so different from all the more mainstream general-purpose programming languages they're used to. And it's a lot easier to put down something you don't understand than to admit you don't get it, or to spend lots of time learning something that may not be of much use to you. Kinda sucks, but it's often human nature.
Re: Impending kOS
#127Earlier quoted context omitted.
I'll give this a shot. I'll try to explain what's in my mind as I read it as well. First, get out the reference manual: http://kparc.com/k.txt and we'll do the first couple lines. The sequence that goes f x applies x to f. this f is unary. The sequence that goes x f y applies x and y to f. this f is binary (and just labelled verb). Some things (adverbs) go f a x and apply f in some special way to x. Last hint: You re…
I have one question. I learned some J some time ago, but never really talked about it with anyone, and so my programs - a few lines' scripts, really - were always written with long, meaningful variable names. I read your explanation and every time you wrote "we don't know what it is yet" I wondered "why the heck isn't it just appropriately named?". I mean, why is 'c' better than something like 'nl_pos' for example? I…
> why and what is this style of naming good for, and what one needs to do to master it?
It's bullshit. The letters are not letters, they're symbols. Replace them with JPGs of pokemon if you want. It's just as well if they were ancient hieroglyphs. If you forgot what they all meant, you have to read the code and keep track of what variable name contains what. Or make a note on some paper.
This is why one-letter variable names are an antipattern: when there's no rhyme or reason to what value is associated with what symbol (why is `c` the index of the newline and not `n`?), your brain isn't going to remember it, and you've instantly forgotten what that code does. And everyone after you needs to do the same thing: you need to re-remember how each line of code works each time you work with it. And more importantly, looking at one dense line of code provides no context as to what the code around it does, compared to C or Python where one function can give you a decent idea of what its use is.
It's even more of a nonsense issue because the actual name of the variable is just a number: every one-letter variable name maps to an integer. Why not support proper identifiers and replace them with unique integers at runtime? The same goes for whitespace: it doesn't need to be kept in the program at runtime, but makes the application infinitely more readable because units of logic can be grouped on their own line.
So to answer your question: no, this is not good for anything and no, you shouldn't try to master it because there are much more useful things that you could be doing with your life.
Re: Impending kOS
#128Earlier quoted context omitted.
It has one: q. But once you get over the syntax, you realize that you also need to grok different semantics that you are used to. Some q is readable english - e.g., an expression like sum price where size>3 is (to the uninitiated) more readable than the equivalent k +/price@&size>3 but that only works for simple stuff. The (idiomatic!) computation of maximum-subarray-sum[0] |/0(0|+)\ becomes max over 0 (0 max +) scan…
The q in your latter example is the same complexity in my book as a dense Python list comprehension. Could be worse.
The equivalent python is:
mss = lambda x: max(scan(lambda a,b: max(0,a+b),0,x))
def scan(f,x0,x):
r = [x0]
for x1 in x:
x0 = f(x0, x1)
r.append(x0)
return r
Re: Impending kOS
#129Earlier quoted context omitted.
Yes, the research literature on software development has consistently found that code size is the best measurement of complexity and predictor of error rates. (Sorry I don't have citations handy but we've discussed this many times on HN, and there's a recent study in the book "Making Software" that adds to it.) What's interesting is how strongly this goes against what most people think they know about good programmin…
If someone produces smaller and faster code than me, then I should want to learn from it. I wonder why other people have the exact opposite reaction. Why do you think that is?
It all depends on how you define "small and fast".
Comments obviously are not code, so it's reasonable to complain about lack of comments.
You suggested wordcount, I think wordcount is good, so it's reasonable to complain about single letter words rather than descriptive words.
uberalex's suggestion for reformatting wouldn't change the algorithm or speed. It would simply spread operations across more lines. That also seems like a reasonable thing to ask, to me. They can learn your method either way.
Edit: I mean, I'm sure fitting more on the screen is valuable, but people already know how to fit many times as much code onto a screen. They avoid it on purpose for whatever reason.
Re: Impending kOS
#130Earlier quoted context omitted.
I'll give this a shot. I'll try to explain what's in my mind as I read it as well. First, get out the reference manual: http://kparc.com/k.txt and we'll do the first couple lines. The sequence that goes f x applies x to f. this f is unary. The sequence that goes x f y applies x and y to f. this f is binary (and just labelled verb). Some things (adverbs) go f a x and apply f in some special way to x. Last hint: You re…
That was awesome, thanks for explaining that for us. It makes a lot of sense the way you explain it, and I quickly got the idea that you can make some powerful expressions this way. The smooth creation of lists is I think one of the most important language features higher level languages have over lower level languages like C. Just this thing: c::a$"\n" That's all I needed to be convinced that modern languages should…
that seems overly complicated for ruby if a is a file.
c = []; a.lines{c