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?)
K, by Arthur Whitney (2005)
11–20 of 31 posts
Re: K, by Arthur Whitney (2005)
#12* 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)
#13You 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)
#14Q (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…
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)
#15For 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…
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)
#16Q (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…
Re: K, by Arthur Whitney (2005)
#17I 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…
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)
#18I 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…
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)
#19I 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…