
10% as verbose as Perl, 3X faster: K is the best language you've never heard of - byrneseyeview
http://www.kuro5hin.org/?op=displaystory;sid=2002/11/14/22741/791
======
aston
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.

~~~
byrneseyeview
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?

~~~
aston
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.

~~~
SwellJoe
The interesting thing for me is that the K programs are fewer lines...a lot
fewer. 9 in K vs. 96 in Perl in one example. When one remembers that perl is
historically the king of one-liners, this is pretty impressive. I'd probably
be willing to learn how to interpret line noise if I only have to parse 9
lines for every 96 I'm parsing now (I'm primarily a Perl programmer). I,
obviously, don't believe this is representative--a large number of programming
tasks aren't reduce-able beyond a certain level. But for a 50% LoC reduction,
I might consider it.

There's a lot of other considerations, and right now Haskell and Erlang are
leading my "what'll my next back end projects use" list (after Perl 6...which
I'm getting excited about after seeing Audrey Tang's talk about it from a few
days ago, as it appears it will fix every single major problem with Perl, by
my reckoning)...but I'm not going to rule out a language merely because my
first glance at it makes me uncomfortable or confused (if that were the case,
I would have never used Perl, Python, Ruby, and I would be avoiding messing
with Erlang and Haskell...I might have even continued trying to figure out
Java, since it seemed comfortably familiar based on my C experience, but I
believe that would have been a very bad instinct).

~~~
ralph
_I'd probably be willing to learn how to interpret line noise if I only have
to parse 9 lines for every 96 I'm parsing now_

bzip2 -9 <hellow.c | uuencode hellow.c.bz2

------
nostrademons
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.)

~~~
byrneseyeview
<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.

~~~
nostrademons
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.

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

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

