10% as verbose as Perl, 3X faster: K is the best language you've never heard of

http://www.kuro5hin.org/?op=displaystory;sid=2002/11/14/22741/791

by byrneseyeview • 19 years ago

8 10 19 years ago

kuro5hin.org

byrneseyeview3• 19 years ago

Source for the speed/verbosity benchmarks: http://www.kx.com/a/k/examples/bell.k

nostrademons2• 19 years ago

I'd heard of K. Unfortunately, "APL derivative" disqualifies it for me: I don't like programming in line noise.

(For that matter, I try to avoid Perl too.)

byrneseyeview3• 19 years ago

http://www.bugbear.com/arc.html

http://www.paulgraham.com/indylangs.html

"The individual tokens should be short as well. Perl and Common Lisp occupy opposite poles on this question. Perl programs can be almost cryptically dense, while the names of built-in Common Lisp operators are comically long. The designers of Common Lisp probably expected users to have text editors that would type these long names for them. But the cost of a long name is not just the cost of typing it. There is also the cost of reading it, and the cost of the space it takes up on your screen."

I'd guess that if you want to be better at Arc than all the Arc-philes who know Lisp, K would be worth studying.

nostrademons2• 19 years ago

Why would I want to be better at Arc than Lispniks? I'm a Haskeller. We're better than them anyways. ;-)

Seriously, this is one case where I think PG is wrong. Typing isn't the main productivity burden on programmers, thinking is. Any time you make someone decipher an identifier, you're slowing them down. Unpronounceable functions are particularly bad: I dunno about others, but I always think "F-N" when I see "fn", while I think "def" when I see "def".

I think Python and Scheme have it basically right, Haskell is okay but has an unfortunate tendency towards obscure vocabulary and cryptic conventions (nub? foldl? mapM_?), and Common Lisp and Java are way too verbose.

aston2• 19 years ago

When did we decide your code was cooler relative to someone else's when you end up typing fewer characters per line for the same functionality? If anything, the added density per line makes reading code (yours or, worse, someone else's) more difficult.

Maybe I'm missing something.

byrneseyeview3• 19 years ago

Succinctness is power: notation should contain as much information per character as possible, so we can be programmers instead of typists.

Would that be easier to read if I added (superfluous) words?

aston2• 19 years ago

I nticd ur nt tping lk ths. Sentences are much easier to understand if you use words, even if the abbreviated forms can be parsed out to the same meaning.

If your aim is to save yourself a couple characters per line, fine. But it does come at a cost.

mm• 19 years ago

Kx systems has a database that is pretty popular in the financial circle

10% as verbose as Perl, 3X faster: K is the best language you've never heard of

Related Stories