Live data from Hacker News

K, by Arthur Whitney (2005)

archive.vector.org.uk

11–20 of 31 posts

Re: K, by Arthur Whitney (2005)

#11
post #7

I have a really hard time understanding what APL-likes are useful for. I guess I don't do a lot of stuff with big vectors, but I feel like it would be hard to structure code (maybe you don't need to?)

Well, it is very different - but if you have for loops anywhere, then K is probably useful for what you do. It's like reading/wriing Japanese kanji for an English speaker - it looks foreign, but it is equally capable and much terser.

Re: K, by Arthur Whitney (2005)

#12
Q (post-K) is really fast. However, the arrogance of the language design is really irritating. It's quite enjoyable to write Q as every working line of code makes you feel very clever. That's the biggest problem with it, though.

* Disclaimer: I maintained/wrote Q programs for years in a production environment. I'd never choose Q as a production platform again. It's fast but not because it's cleverly written, it's fast because it does not do anything for you.

Re: K, by Arthur Whitney (2005)

#13
Compared to how different k/j/apl are from mainstream programming languages, c/c++/c#/java/pascal are all dialects of the same language.

You have to think differently when using them - an exercise well worth the effort. Much like Lisp, if you grok them, your code in any language will be much better.

And they are not new - APL goes back to the 1950's. K is the refined-for-practicality version, J is the refined-for-purity-and-mathematical-beauty version (but it IS practical; in fact, it drops APL's special graphic symbols which made APL more beautiful but less useful)

Re: K, by Arthur Whitney (2005)

#14

Q (post-K) is really fast. However, the arrogance of the language design is really irritating. It's quite enjoyable to write Q as every working line of code makes you feel very clever. That's the biggest problem with it, though. * Disclaimer: I maintained/wrote Q programs for years in a production environment. I'd never choose Q as a production platform again. It's fast but not because it's cleverly written, it's fas…

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 them.

Re: K, by Arthur Whitney (2005)

#15

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.

Re: K, by Arthur Whitney (2005)

#16
post #14

Q (post-K) is really fast. However, the arrogance of the language design is really irritating. It's quite enjoyable to write Q as every working line of code makes you feel very clever. That's the biggest problem with it, though. * Disclaimer: I maintained/wrote Q programs for years in a production environment. I'd never choose Q as a production platform again. It's fast but not because it's cleverly written, it's fas…

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 interpreter would do to my code. Additionally, working directly with the data allows plenty of opportunity to write self modifying code to minimize memory usage and optimize program execution to avoid cache misses. I do all my programming in hex editors now and encourage junior developers at my company to do the same.

Re: K, by Arthur Whitney (2005)

#17
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…

> the idea you could possibly write a lot of it

Presumably it’s one of those things where if you find yourself writing a lot of code, you really ought to question what you’re doing?

> Your code ends up super dense, with non-trivial stuff easily fitting on just a few screens, so you can keep track of what's going on.

I have found it really difficult to convince people that the latter follows from the former—that denser notations actually make code easier to grasp, as long as you know the notation. The farthest I’ve gotten is: “Look, in a language that rhymes with Slava, you often have to write an enormous amount of code in order to accomplish anything and keep it maintainable, right? Well, there are languages even better about that than the ones you use.”

You may be interested in concatenative programming, a cousin of tacit programming. Factor (http://factorcode.org/) is a good dynamic language with a great environment and helpful (though quiet) community in #concatenative on Freenode. I am working—alas, very slowly—on a statically typed concatenative language and hope that it will one day help take these ideas to the mainstream. :)

Re: K, by Arthur Whitney (2005)

#18
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…

> the idea you could possibly write a lot of it Presumably it’s one of those things where if you find yourself writing a lot of code, you really ought to question what you’re doing? > Your code ends up super dense, with non-trivial stuff easily fitting on just a few screens, so you can keep track of what's going on. I have found it really difficult to convince people that the latter follows from the former—that dense…

I see what you did there.

ps: just in case here's a very enjoyable talk, not about, but by Slava http://www.youtube.com/watch?v=f_0QlhYlS8g Beautiful and impressive.

Re: K, by Arthur Whitney (2005)

#19
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…

Having mostly only seen each, I am unsure how K and J compare.

http://www.jsoftware.com/

Post reply on HN