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

K, by Arthur Whitney (2005)

archive.vector.org.uk

Post reply on HN
Print view View original

21–30 of 31 posts

Re: K, by Arthur Whitney (2005)

#21

Post by beagle3 »

soup10 wrote: post #16
beagle3 wrote: post #14

Earlier quoted context omitted.

It doesn't do much for you, true - but after using K for awhile I came to the conclusion that the vast majority of what other languages give you is not required. Sort of like realizing that a lot of lawyers, finance people and even doctors do not actually provide society at large and even their direct customers any benefit (though having nontrivial cost), and the world would be a better place if there were fewer of t…

I came to a similar conclusion when programming using a hex editor and the x86 instruction set manual. Without having to clutter my mind with the abstractions other languages introduce I found I had a ton of free memory to reason about my code and handle much larger portions of code than I usually do. Also, by typing in data directly I avoided having to do the mental translation of thinking about what a compiler or i…

I'm sure this was supposed to be funny. But unlike x86 hex coding, people actually get stuff done in k/q - in fact stuff that runs faster and better than equivalent systems in C++ and Java. So the reduction ad absurdum does not, in fact, add to the discussion.

Re: K, by Arthur Whitney (2005)

#22

Post by beagle3 »

paddy_m wrote: post #10

NumPy is an array oriented library/language too. Idiomatic NumPy usage is quite terse too. I can see how you can start with NumPy like syntax and then want something still more terse, but starting from K/Q seems quite hard.

It's more than just terser notation for numpy-style operations. Q (verbose K) reads cleaner than numpy code - closer to English, in fact, without giving up any speed. K is the terse mathematical notation for that language.

K has 3 types: atoms, lists, and dictionaries. (atoms can be int, char, float, symbol, time or function). No objects, no strings, not even files. And yet, it is enough to express many algorithms concisely and efficiently, with bugs largely reduced to the class of off-by-one family.

The syntax is not just a superficial aspect of the language - it is fundamental to its evolution.

Re: K, by Arthur Whitney (2005)

#23

Post by beagle3 »

keithpeter wrote: post #3
fidotron wrote: post #2

I had to write a lot of K at university (thus disclosing where I went to, and confusing people that have written any K with the idea you could possibly write a lot of it). Get by the symbolic confusion (Arthur himself used to respond to confused students on the mailing list about such things) and it's really quite inspired. I can appreciate how an APL with proper symbols would be properly productive. Your code ends u…

Is Kona good enough for dabbling with do you think? https://github.com/kevinlawler/kona

Mostly. Mona is k2/k3 (described in this post). K4/Q is much much cleaner - so it is easier and preferable in my opinion. You can get a free(gratis) 32-bit interpreter of that to play with; but if you insist on free(libre), kona is acceptable to dabble in. There's also J, which I think prefers purity and mathematical aesthetics to practicality, that you may like.

(J is a different language; both J and K can be traced back to the origin of A, a 20 C line implementation of an APL dialect)

Re: K, by Arthur Whitney (2005)

#25

Post by soup10 »

beagle3 wrote: post #21
soup10 wrote: post #16

Earlier quoted context omitted.

I came to a similar conclusion when programming using a hex editor and the x86 instruction set manual. Without having to clutter my mind with the abstractions other languages introduce I found I had a ton of free memory to reason about my code and handle much larger portions of code than I usually do. Also, by typing in data directly I avoided having to do the mental translation of thinking about what a compiler or i…

I'm sure this was supposed to be funny. But unlike x86 hex coding, people actually get stuff done in k/q - in fact stuff that runs faster and better than equivalent systems in C++ and Java. So the reduction ad absurdum does not, in fact, add to the discussion.

What are you talking about. I assure you we get a lot done at the office doing x86 coding in hex, and even more in MIPS due to the simpler instruction set.

Re: K, by Arthur Whitney (2005)

#26

Post by eddie_the_head »

beagle3 wrote: post #24
eddie_the_head wrote: post #20

I have a fear that the problem with these APL family languages is that they ruin coding in any other language for you.

That, in fact, sort of happened to me. But would you rather remain blissfully unaware?

I want to reach Satori, but the Iversonian enlightenment may be too powerful to bear for a mere ALGOL-like accustomed mortal.

⍝

Re: K, by Arthur Whitney (2005)

#27

Post by alexcash »

Long time HN lurker...I've worked with kdb+ / k the last few years, it's in every major bank and is great for storing and querying market data. If you're looking for a nice GUI I use qStudio, it helps make it a little more friendly.

Then there are great tutorials on the code k website. It's a beautiful language full of unique original ideas.

Re: K, by Arthur Whitney (2005)

#28

Post by juliangamble »

I didn't 'get' K until I read an interview with Arthur Whitney in the ACM Queue. Apart from performance, you're also getting craftsmanship.

http://queue.acm.org/detail.cfm?id=1531242

It turns out he rewrites the whole compiler from scratch in C every four years.

This is a snapshot from the source code of 'J' also by Arthur Whitney - the precursor to 'K'.

http://keiapl.org/rhui/remember.htm#incunabulum

This is it described by Ken Iverson:

"The final impetus that got J started was the one-page interpreter fragment that Arthur wrote, recorded in Appendix A of An Implementation of J [29] and also reproduced in Appendix A below. My immediate reaction on seeing the page was recoil and puzzlement: it looked nothing like any C code I had ever seen. (“Is it even C?”) However, Ken counselled that I should reserve judgment. "

http://keiapl.org/rhui/remember.htm

Re: K, by Arthur Whitney (2005)

#29

Post by vorg »

gruseom wrote: post #15
swannodette wrote: post #5

For a real eye opener compare the length of these K versions of the Alioth benchmarks to their more verbose brethren http://kparc.com/$/z/comp.k . I found these on the K OS project page - http://kparc.com/os.htm . There's a great description of Arthur Whitney building a Notepad like text editor (1K) in 30 minutes or so using this system here - http://coding-is-like-cooking.info/2013/09/an-introduction-t... . Personal…

http://coding-is-like-cooking.info/2013/09/an-introduction-t... . Thanks, I enjoyed that article. It gives a vivid picture of the gap between the array languages niche and mainstream programming culture.

> Despite my head start with J, by the end of the conference I found APL code easier to grasp – J seems more extreme to me. Roger calls J “executable mathematical notation”, and I’ve always been a bit more of an engineer than a mathematician.

I found this too, when I tried them both, first J then APL, perhaps because:

* APL uses () [] and {} in their pairs to parenthesize things, just like other languages, while J uses the 6 symbols as standalones, harder to read the code.

* All verbs in APL are single characters, whereas J symbols might be more than one.

* J, unlike APL, uses the concepts of rank, and forks and hooks, which are both difficult to grasp and don't seem to add much to the array processing idea.

Re: K, by Arthur Whitney (2005)

#30

Post by beagle3 »

fennecfoxen wrote: post #6
swannodette wrote: post #5

For a real eye opener compare the length of these K versions of the Alioth benchmarks to their more verbose brethren http://kparc.com/$/z/comp.k . I found these on the K OS project page - http://kparc.com/os.htm . There's a great description of Arthur Whitney building a Notepad like text editor (1K) in 30 minutes or so using this system here - http://coding-is-like-cooking.info/2013/09/an-introduction-t... . Personal…

a quick Internet also reveals: life:{3=a-x*4=a:2{+(0+':x)+1_x,0}/x}

Explantion: x is a 0/1 matrix of live cells.

    0+':x  -> "sum each element with one to the left
               (0 left of the first)"
    1_x,0  -> "drop first, add zero at the end"
    
    (0+':x)+1_x,0 -> "sum each element with the one
                      to the left and the one to the
                      right (sum of previous expressions)"

    a:2{+...}/x -> "do that; transpose; do that; 
                    transpose again, and assign to a.
                    2{}/ means 'do twice'"
At this point, "a" has the same shape of "x", but in every element is the sum of the elements of x from that location, one above, one below, one left, and one right.

    4=a     -> "1 where a=4, 0 otherwise"
    x*4=a   -> "1 where x is 1 and a=4, 0 otherwise"
    a-x*4=a -> "decrease a from 4 to 3 if x=1 in the 
                that place"
    3=a-x*4=a -> "1 where one has 3 neighbours"
So, if x is a 1/0 matrix "life x" does one iteration of Conway's game of life. And "1000 life/ x" would seek convergence or return to first state (but no more than 1000 iterations).

There is code golfing here; It would have been purely readable K code if it wasn't golfed. But it would also have been two to three times as long.

Post reply on HN