Impending kOS • Hacker News Board

Re: Impending kOS

#151

Post by cbsmith » Sun, Oct 19, 2014, 5:42 AM UTC

beagle3 wrote: post #128

bastawhiz wrote: post #123

Earlier quoted context omitted.

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)) assuming a definition "scan" (which is like "reduce", except it gives you all intermediate values), an example of which is: def scan(f,x0,x): r = [x0] for x1 in x: x0 = f(x0, x1) r.append(x0) return r Note that the K is idiomatic whereas the python is (arguably) not. Of course, it could be worse; the advantage is that, much like math, the…

Oh goodness... don't do scan like that. Way easier (and more efficient) to use a generator:

    def scan(f, iterator, initial=0):
        yield initial
        yield from scan(f, iterator, f(initial, next(iterator)))

Even with python2, you could make a non-recursive version that'd be still shorter than your scan and faster. Alternatively, you could pair a coroutine with that reduce function....

But always be suspect of your code if you are iterating and appending to a list. Likely there is a much better way.

Re: Impending kOS

#152

Post by cbsmith » Sun, Oct 19, 2014, 5:43 AM UTC

Torn wrote: post #72

sohagan857 wrote: post #52

Earlier quoted context omitted.

Qfan. Very good comment....I would advise all to read this comment and then follow this link... http://www.firstderivatives.com/kx_training_new.asp

Your account was created one day ago, and qfan's 1 hour ago. Your comment chain is at the top of article linking to a $1800 training course on kdb+, run by the owners of the language. The article was a good read, if dramatic, but this smells like astroturfing to me.

The kdb+ folks have no need to astroturf, and if they did it wouldn't get them anywhere.

Re: Impending kOS

#153

Post by burntsushi » Sun, Oct 19, 2014, 5:45 AM UTC

icsa wrote: post #150

burntsushi wrote: post #120

Earlier quoted context omitted.

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…

/ http://shootout.alioth.debian.org http://kparc.com/z/comp.k

Ok... Now how do I run those programs such that they are comparable to the ones on the benchmark game?

Re: Impending kOS

#154

Post by dragonwriter » Sun, Oct 19, 2014, 5:46 AM UTC

Widdershin wrote: post #134

tinco wrote: post #112

Earlier quoted context omitted.

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, a…

Regarding find_all_with_index, you can do: .find_all.with_index { |item, index| ... }

except .find_all.with_index passes the index to the predicate block, but still only returns a view of the matching elements from the list.

What I think is being sought is more like:

  module Enumerable
    def find_indices
      each.with_index
          .find_all {|x,_| yield x}
          .map {|_,y| y}
    end
  end

Re: Impending kOS

#155

Post by icsa » Sun, Oct 19, 2014, 5:49 AM UTC

mwcampbell wrote: post #76

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.

So would k be even faster if it were compiled to machine code rather than being interpreted? Would that involve an unacceptable speed versus space trade-off? Or am I missing some crucial reason why k code has to be interpreted?

I don't think so. Many of K's primitives operate on arrays using stride 1 access. Being cache-friendly accounts for much of the performance gains.

In addition, K is written in ANSI C to maintain portability.

Re: Impending kOS

#156

Post by lafar6502 » Sun, Oct 19, 2014, 5:54 AM UTC

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?

Re: Impending kOS

#157

Post by icsa » Sun, Oct 19, 2014, 5:55 AM UTC

burntsushi wrote: post #153

icsa wrote: post #150

Earlier quoted context omitted.

/ http://shootout.alioth.debian.org http://kparc.com/z/comp.k

Ok... Now how do I run those programs such that they are comparable to the ones on the benchmark game?

Make a request at kparc.com for the research version of k (k5).

If that doesn't work download q/kdb+ from kx.com (Windows/Linux/Mac OS X). It can runk4.

/ k4 implementations of the Bell Labs benchmarks are available http://kx.com/a/k/examples/bell.k

Re: Impending kOS

#158

Post by avmich » Sun, Oct 19, 2014, 5:57 AM UTC

bastawhiz wrote: post #127

klibertp wrote: post #117

Earlier quoted context omitted.

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 variab…

One reason for one-character names is the habit of these languages to sidestep naming problem. Naming things is one of the hardest problems in software. APL programs are ideally read as "variable X is ...", not "do this, then this, then this" - so appropriate names of variables could be something like "max of reduce by difference..." - hence the hardness of coming with good names.

Another reason is the same as in math. When you write equations on a whiteboard - the long-sought golden standard of expressiveness - you don't use long names - at best you encode names with subscripts, indexes etc. But names themselves are usually pretty short. APL languages use the same rationale.

Just like you need to read carefully every line of a math equation to understand what's going on, you have to read carefully each symbol of programs in APL family languages. It's unusual for programmers who got used to more help along the line - but the vocabulary of all such languages is quite short and doesn't extend that often. Another reason why APL could be used for teaching math.

I don't agree that this style of naming is not good for anything. Somehow majority of programmers in these languages agree with that. Regarding much more useful things -

"If you are interested in programming solutions to challenging data processing problems, then the time you invest in learning J will be well spent." (http://jsoftware.com/)

Re: Impending kOS

#159

Post by icsa » Sun, Oct 19, 2014, 6:00 AM UTC

losvedir wrote: post #109

geocar wrote: post #87

Earlier 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…

Wow, that was fascinating. K looks utterly mind-expanding, thanks for breaking this down. You obviously have some experience working with K, and it sounds like at least Javascript, too? K is so foreign I expect it has a lot of interesting thoughts locked up in there that maybe don't get the attention they deserve. Would you say there are any "killer features" of the language / environment that you miss when working w…

Killer feature --------------

Not having to write:

for(int i=0; iwhich generally obscures the fact that I'm trying to do a map or fold (e.g. - reduce) operation :).

Re: Impending kOS

#160

Post by icsa » Sun, Oct 19, 2014, 6:08 AM UTC

dragonwriter wrote: post #142

geocar wrote: post #87

Earlier 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…

> A view is a concept in k that is unusual in other languages: When "a" gets updated, then "c" will automatically contain the new values. Its actually not at all an unusual concept; its well known from SQL, for instance, but also Scala has them (Scala views aren't views in the sense that you use the term, but the lazily-implemented transformers they implement produce views of the type under discussion) as does Ruby (…

A view can be thought of as a dependency expression. In version 3 of K there was a data driven GUI. The dependencies allowed one to to Functional Reactive Programming (FRP) quite easily.

Unlike SQL, views in k are not limited to queries as dependency expressions. The expressions can be arbitrary.