[HN Gopher] K Language (2011)
___________________________________________________________________
K Language (2011)
Author : lelf
Score : 54 points
Date : 2020-03-12 20:01 UTC (2 hours ago)
(HTM) web link (www.math.bas.bg)
(TXT) w3m dump (www.math.bas.bg)
| invalidOrTaken wrote:
| A story, since in retrospect I think it's worth telling.
|
| Some years ago I was at the SF Clojure meetup. Arthur Whitney's
| daughter worked at the sponsoring company, and he agreed to come
| tell us about K.
|
| In retrospect, I don't think we gave him the welcome he deserved.
| No one was rude or anything, but it seemed there was a
| disconnect: Arthur was keen to show off how _fast_ K (and Kdb)
| was, over zillions and zillions of rows.
|
| But the thing that the Clojurists were all searching for (that
| got them into Clojure in the first place) was _expressivity_. Is
| Clojure fast? I don 't know, generally the problems I face come
| down to avoiding balls of mud rather than performance
| bottlenecks. And I think that was true of most there.
|
| So Arthur got something of an underwhelming reception. I remember
| someone asking "Does K have the ability to self-modify, a la Lisp
| macros?" When Arthur said no, you could see most people in the
| room just sort of mentally shrug and move on.
|
| And this was too bad. Because recently I've been playing around
| with J (another APL descendant) and been very impressed by some
| expressivity/readability benefits. Some small things that have
| very big effects on the codebase you actually end up with.
|
| The first thing is the avoidance of abstraction. To use a
| Twitterism:
|
| Broke: Just write your code and don't divide it into functions,
| creating one long main method
|
| Woke: Divide your code up, naming parts that get reused
|
| Bespoke: If your code is made up of _really really short_ things,
| it ends up being shorter than _the names you would use_ , so you
| can just _write the thing_ rather than your name for it. An
| analogy would be: there is no human-comprehensible way to
| communicate the idea of "picosecond" in less time than an actual
| picosecond.
|
| The other thing I didn't expect was the benefit of multiple
| dispatch being baked into e v e r y t h i n g. In Clojure I might
| write (map + a b) to add each index together; in J I could just
| write a+b.
|
| This is neat stuff! Best practices for keeping complexity down in
| APL's tend to be the _opposite_ of what they are in other
| languages. Aaron Hsu gave a talk about this:
| https://www.youtube.com/watch?v=v7Mt0GYHU9A
|
| It's too bad! Arthur came to tell us about speed---there's a
| reason it's used on giant datasets in _finance_ , where
| performance translates directly into cash---but I wish we'd had
| the presence of mind to ask more about _experience_ of writing K.
|
| So, Arthur, if you're reading this: Sorry everyone seemed kinda
| bored in SF a few years ago when you kindly came to present. We
| missed out!
| kazinator wrote:
| > _so you can just write the thing rather than your name for
| it_
|
| I do not find this convincing. Names, especially good names,
| can convey additional meaning, which is helpful even if the
| names are longer than what they stand for in terms of raw
| character count.
|
| One obvious example is that I would often rather see a seven-
| letter manifest constant than the two-digit decimal literal it
| represents.
|
| In a similar vein, I would rather have a structure with named
| fields, than array indices or offsets. employee.department is
| objectively better than e[13]; a compiler can generate the
| equivalent of the latter from the former.
|
| In calculations that have many nodes in the syntax tree, it's
| helpful to break up the tree and give intermediate values
| names, which remains true even if the names are longer than the
| intermediate calculations.
|
| A name may _longer_ than what it denotes in raw character
| count, but in spite of that it may less complex due to its flat
| structure which only indicates "same or not". If a 13
| character identifier stands for some 9 character syntax that
| denotes a tree with 7 nodes, the identifier is certainly
| simpler.
|
| Lastly, different expressions that occur in a program can
| sometimes be very similar to each other. If we do not use
| names, then these differences can be hard to find. It might
| seem that identifiers which are longer than what they denote
| make the problem worse, but that is not necessarily so.
| Identifiers which are clearly different from each other can be
| selected for denoting forms that are very similar to each
| other. If instead of ((<]):) and ((<[):) I write foolyfoo and
| barlybar, that will be less error prone.
| kick wrote:
| The RPN calculator example makes me really happy.
|
| As for the content of this page, there's a line within that now
| applies to itself:
|
| _Introductory articles - somewhat dated but nevertheless rather
| informative:_
|
| k4, what it lists as the most recent version, is about 20 years
| old now, and it talks about it like it's new. Still informative,
| though!
|
| EDIT: Giving it another look, it looks like the links have been
| updated over time (for example, the reference to oK), though the
| main content of the post is about ten years old and the initial
| list of links is over ten:
|
| https://web.archive.org/web/20110927003800/http://www.math.b...
___________________________________________________________________
(page generated 2020-03-12 23:00 UTC)