Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Impending kOS

archive.vector.org.uk

Post reply on HN
Print view View original

111–120 of 242 posts

Re: Impending kOS

#111

Post by tree_of_item »

MichaelGG wrote: post #107
tinco wrote: post #105

Earlier quoted context omitted.

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…

Certainly you could wrap up the $ operator into some Ruby method?

Yes, Ruby is Turing complete, but that's missing the point.

The value K provides is the collection of operators like `$` that implement a high level language for the sorts of problems K programmers face.

If you went through and implemented all of those operators in Ruby and only used those instead of things like loops, your code would be "unreadable" to the standard Ruby programmer; essentially you'd be programming in a different language.

Re: Impending kOS

#112

Post by tinco »

MichaelGG wrote: post #107
tinco wrote: post #105

Earlier quoted context omitted.

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…

Certainly you could wrap up the $ operator into some Ruby method?

Sure, simply do:

    module Enumerable
      def dollar(c)
        map.with_index{|a,i| a == c ? i : nil }.reject{|i| i.nil? }
      end
    end
And then you could do:

    c = a.dollar("\n")
There is of course a reason this dollar method is not a part of the standard library. Its name makes no sense and it's oddly specific, how often would you want the indexes of matches to a character? Most modern languages don't like to work with indexes a lot, and in my day to day work I don't need indexes very frequently either. This I guess is just a thing that these finance/apl people do more often, so they have a specialized standard library.

(So when I said 'a neat way to do $' I meant it has no find_all_with_index method, which would make my implementation much cleaner)

Re: Impending kOS

#113

Post by kencausey »

sohagan857 wrote: post #44
zokier wrote: post #5

Googled around, Kuro5hin (that's a name I haven't seen for some time) has a tutorial for K from 2002: http://www.kuro5hin.org/story/2002/11/14/22741/791 The download link at http://www.kparc.com/ asks for password, so I'm not sure whats going on with that.

You have to have a personal invite to download the code atm. The whole article is telling you it is not available yet, but "if coming".

I may be mistaken but I believe zokier is referring to a download link for k whereas you are referring to a download for kOS. No?

Re: Impending kOS

#114

Post by selimthegrim »

beagle3 wrote: post #55
geocar wrote: post #34

Earlier quoted context omitted.

If I am from another planet, and say I don't know why programs are so big and slow and buggy, and the most complicated program you see I've produced is a glorified calculator, it's too easy to be patronising and say well, that's because you haven't done anything complicated . However if I then show you a programming language, a database engine (similar in capability to SQL but around 1000x faster), a graphical deskto…

I think Douglas Adams' SEP[0] field is a good description of this. Most people ignore what doesn't fit with their logic - doubly so if fitting it in would show them that they have been wrong/wasted money/wasted time in the past. (The Upton Sinclair quote about "it's difficult for someone to understand something when their salary depends on not understanding it" is also relevant). It's that way with religion, paradigm…

Nothing encapsulates PNAS' worthlessness as a journal more than that fiasco.

Re: Impending kOS

#115

Post by nemo1618 »

ah- wrote: post #36

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: http://kx.com/q/cs107/a.c

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.

Re: Impending kOS

#116

Post by Torn »

nemo1618 wrote: post #115
ah- wrote: post #36

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: http://kx.com/q/cs107/a.c

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?

Re: Impending kOS

#117

Post by klibertp »

geocar wrote: post #87
tlrobinson wrote: post #33

Earlier quoted context omitted.

Could someone who can parse (reverse engineer?) this write up an explanation? (if you exist)

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 get it that reading J, K or APL programs requires some serious work and I'm ok with that, but why would I need to burden my short term memory with one- or two-letters identifiers on top of that?

This is a honest question and I feel like there is some upside to those names I just keep missing. As I said, I'm not fluent in J, but while learning it I wrote and read quite a bit of it, and I only made it through some longer (like, longer than half a line!) examples thanks to a sheet of paper and sheer determination. I often was going through a fairly complicated expression and was starting to see what is it about, only to be stopped by an 'x' or 'c': I then had to go back a couple of lines, read 'x' definition again, and retry parsing that line from the beginning, hoping that I will remember what 'x' is this time. I started taking notes for this reason (it worked quite well I think).

Anyway, you seem to have no problems reading such code, so I figured I'd ask you: why and what is this style of naming good for, and what one needs to do to master it?

Re: Impending kOS

#118

Post by kodisha »

qfan wrote: post #65
sz4kerto wrote: post #54

Earlier quoted context omitted.

I've worked with and later run the kdb/q stack for a couple of years at a financial services firm. I certainly enjoyed it but I've also seen the downsides of it, and according to my experience it does not worth the investment, and the biggest reason behind its adoption is A.W.'s relations with the financial industry. By the way, I really don't want to go into anything personal but your comments represent the attitude…

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?

Re: Impending kOS

#119

Post by [deleted] »

burntsushi wrote: post #69
geocar wrote: post #51

Earlier quoted context omitted.

What you're actually seeing is testimony: people saying they are seeing something amazing, and they aren't very good at explaining what they saw. Btw: k doesn't translate to C. It's actually a quite simple interpreter. The fact that it outperforms other languages so easily should be saying more about those languages than it should be saying anything about k.

Well, does there exist a technical analysis written by someone who understands k that explains why it is so much faster than X languages?

[deleted]

Re: Impending kOS

#120

Post by burntsushi »

geocar wrote: post #94
burntsushi wrote: post #69

Earlier quoted context omitted.

Well, does there exist a technical analysis written by someone who understands k that explains why it is so much faster than X languages?

As I said, I think this is the wrong question. The real question is why is X language so slow? This is not intended to be glib: but I do not think I can put it more simply than that. X language is slow because it uses lots of library code that it doesn't actually use (to get a friendly interface), it has a lot of redundancy (because of the wrong abstraction level), and because it wastes memory (in order to have an AP…

It's not the wrong question. You just rephrased it. And in the process of doing so, you missed the point of my question. I emphasized the word "technical" because I was trying to politely ask for evidence. Evidence should be some combination of code, benchmarks and analysis.

The code should provide isomorphic samples from the languages (or implementations of languages) that are being tested. Ideally, the code samples should be idiomatic.

Benchmarks should test the aforementioned code such that performance comparisons can be made. (With some degree of accuracy.)

Analysis should summarize and draw tempered conclusions from the code and benchmarks. Trade offs should be documented.

The Computer Language Benchmarks Game[1] is a first approximation of this. It provides the first two things but has no analysis in prose.

Does such a thing for k exist? Even if it's a very rough blog post somewhere from 5 years ago?

I ask this because there's a lot of lofty claims being made in this thread, and the closest thing to evidence I've seen is, "trust us, it's made a lot of money doing [financial things]. oh, and it can update a million records in a second." Since I don't believe that a free lunch can exist, I am naturally inclined to reach the truth of the matter. I see that k is supposed to be wicked fast---at what cost? Where are the examples? Where is the analysis documenting this?

[1] - http://benchmarksgame.alioth.debian.org/

Post reply on HN