Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stages of denial in encountering K

nsl.com

Post reply on HN
Print view View original

171–180 of 432 posts

Re: Stages of denial in encountering K

#171

Post by yiyus »

heinrichhartman wrote: post #163

Looks like the author figured it all out at the very beginning: > If each punctuation character in the K is a separate part of speech, and you reverse their order + / ! 100 plus reduce range 100 This seems to be how this works. Compare that to math equations like these ones: https://en.wikipedia.org/wiki/Maxwell%27s_equations#Formulat... You would not expect them to read them like a paragraph. You are expect to read…

The author is a K professional developer who works with K on a daily basis and have implemented a K interpreter in JS (oK). He is not frustrated, he is making a point. It looks like you perfectly got the point.

Re: Stages of denial in encountering K

#172

Post by lolc »

Veedrac wrote: post #56

K +/!100 Python sum(range(100)) Haskell sum [0..99] Rust (0..100).sum() Ruby (0..99).sum There are plenty of ultra-concise languages for toy problems like these; they are called ‘golfing languages’. Ultimately it's a bit pointless since most of the time people aren't playing code golf. (The issue with setting everything to obscure ultra-compressed keywords isn't that it's not possible to learn those keywords , but th…

That's what I'm wondering with K! What happens once I want to abstract over the basic operations?

Re: Stages of denial in encountering K

#174

Post by kaminari »

ehsankia wrote: post #31
busterarm wrote: post #7

Are reduce and lambdas really that cryptic/complex to people? I think I need an adult. -.-

range(100).reduce(plus, 0) isn't cryptic, what's cryptic is single character symbols. Looking at that line, unless you know K specifically, it's very difficult to figure out it's a reduce. Where as `sum(range(100))` is pretty self explanatory to most programmers who don't know python.

I don't know K but "+/" immediately stood out to me as "add over", so I think they made a good choice in using "/" for fold.

"!", on the other hand...

Re: Stages of denial in encountering K

#176

Post by kaminari »

msla wrote: post #76

My problem with K isn't its syntax, it's its culture: People who are so self-satisfied with their ability to read their own code they refuse to give variables meaningful names, aping mathematical tropes they half-understand at best, because those mathematical equations are only tolerable in the context of a paper where the rest of the lifting is done by natural language prose. They eschew comments without realizing t…

Elsewhere in this comment section, someone mentioned a HFT firm that extensively used noweb and K.

Re: Stages of denial in encountering K

#177

Post by rkangel »

dang wrote: post #107

A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.

It has recently been discovered that human speech has a constant bitrate of 39 bit/second[1]. People speak faster in some languages but convey less information per word, and the converse holds true in languages where people speak slower.

In a 'code golf' language where you reduce a 1 million line program to 1000 lines, the 1000 line program is going to be just as hard to read. More concise syntax doesn't help as the same number and complexity of concepts are going to exist in both programs, and that's what the human has to understand.

There are languages where more powerful concepts are available for less code. Erlang for instance, with concurrency. In those cases, yes, readability is aided and maintainability is improved.

[1] https://www.sciencemag.org/news/2019/09/human-speech-may-hav...

Re: Stages of denial in encountering K

#178

Post by chrispsn »

uryga wrote: post #140

what is ` the closest i got to finding some pattern is this: >>> xs '34210' >>> grade(xs) [4, 3, 2, 0, 1] >>> grade(grade(xs)) [3, 4, 2, 1, 0] # :O where grade = lambda xs: ( [i for (i,_) in sorted(enumerate(xs), key=swap)] ) swap = lambda p: (p[1], p[0]) no clue what it means though. (i guess "ordinal" really is too ambiguous...) EDIT alright, i see it now - `<<xs` is "for each item x of xs, where does x land when y…

This may help - I found it confusing at first too: https://twitter.com/kcodetweets/status/1236904643684270080?s...

Re: Stages of denial in encountering K

#179

Post by chrispsn »

kaminari wrote: post #174
ehsankia wrote: post #31

Earlier quoted context omitted.

range(100).reduce(plus, 0) isn't cryptic, what's cryptic is single character symbols. Looking at that line, unless you know K specifically, it's very difficult to figure out it's a reduce. Where as `sum(range(100))` is pretty self explanatory to most programmers who don't know python.

I don't know K but "+/" immediately stood out to me as "add over", so I think they made a good choice in using "/" for fold. "!", on the other hand...

What would be a more obvious symbol choice for range (aka til or seq)? Pound (#)?

Re: Stages of denial in encountering K

#180

Post by mhd »

The problem is also that you encounter K/APL in these circumstance, hardcore math functions or ad hoc queries. I'd say that most languages look their worst in these circumstances, deeply nested for loops for e.g. 3D math in C aren't exactly instantly clear either.

Once you see e.g. input verification or other more "tedious" parts of programs, things get decidedly less cryptic.

And less optimized/concise, of course. A bit like the people who complain about GUI hello world programs taking 10 lines.

Post reply on HN