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

221–230 of 432 posts

Re: Stages of denial in encountering K

#221

Post by oblio »

jbotz wrote: post #186
rkangel wrote: post #177

Earlier quoted context omitted.

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…

Claim A: Human speech has a constant bitrate. Claim B: The intelligibility of a computer program is proportional to its complexity of the problem it solves, not to the number of characters in its source code. First off, I don't see how B follows from A. Secondly, even if there does seem to be some similarity, one of the reasons any comparison breaks down is that human languages are evolutionarily adapted to our cogni…

At some point you run into entropy. You can only compress code until it covers the requirements 100% and nothing else. You can't go past that point without losing features.

Re: Stages of denial in encountering K

#222

Post by buzzkillington »

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…

>You would not expect them to read them like a paragraph. You are expect to read them symbol by symbol and unpack from the inner out.

As someone who has a bunch of letters before my name because of physics, no. You don't read physics symbol by symbol. You expand those symbols to pages and pages, meditate on those pages and achieve enlightenment on one small aspect of the problem. There is so much implicit state in those equations they are basically meaningless.

A nice book that deals with all the implicit state and terrible unclear notation used in physics: https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...

Re: Stages of denial in encountering K

#223

Post by shawnz »

jbotz wrote: post #186
rkangel wrote: post #177

Earlier quoted context omitted.

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…

Claim A: Human speech has a constant bitrate. Claim B: The intelligibility of a computer program is proportional to its complexity of the problem it solves, not to the number of characters in its source code. First off, I don't see how B follows from A. Secondly, even if there does seem to be some similarity, one of the reasons any comparison breaks down is that human languages are evolutionarily adapted to our cogni…

> human languages are evolutionarily adapted to our cognitive capacities, whereas programming languages are designed [...]

That's what they're designed for, but why does that mean they aren't also evolutionarily adapted to our cognitive capabilities?

Re: Stages of denial in encountering K

#224

Post by 7thaccount »

Firadeoclus wrote: post #220
ivanbakel wrote: post #211

Earlier quoted context omitted.

That's a very convenient analogy for your argument, but it doesn't make sense for programming languages in general. It's not really meaningful to compare the readability of sentences in English versus Chinese. On the other hand, it's both meaningful and important to compare readability of program snippets - and readability is more than just the first-time learning burden. Overly-concise code being difficult to mainta…

> Overly-concise code being difficult to maintain is a well-accepted fact. Many seasoned APL/J/K programmers state that conciseness is an asset. I would trust their judgment on that. There are ways in which that and the quoted statement could both be true at the same time.

Aaron Hsu writes about this a lot. In an APL snippet, you often don't need layers of blackbox abstractions. You can see the whole thing at a macro layer. I'm sure it takes time though.

Re: Stages of denial in encountering K

#225

Post by dcsan »

sriram_malhar wrote: post #202

I love the brevity of regular expressions and use them on a daily basis. It is the same argument that keeps me returning to K: the syntax is terse and compact, the semantics are simple and composable, and your eyes get used to it. Beyond a point however, I cannot read my own regex's after a month's absence. Which is why I use perl's /x modifier extensively to split up regex components onto multiple lines and to docum…

lots of comments there!

/ xml from char

Re: Stages of denial in encountering K

#226

Post by geocar »

gjulianm wrote: post #209
geocar wrote: post #201

Earlier quoted context omitted.

> the claims it's perfectly readable, and anyone who says anything otherwise is either stupid, lying, or too poor to understand it are not useful. Yes: It is perfectly readable once you know how , and anyone who says anything otherwise is just plain wrong. Including you 58 days ago. I don't know if you are wrong because you are lying, or you believe this because you are stupid. I wrote off at the time that it was wel…

> I believe you can learn to read it and read it as well as me as quickly as with a few months of study. Then it's not perfectly readable. That, or your definition of readable is useless because then any programming language is readable given enough study time. > being able to do it easier is the point. I still haven't seen any example where it is actually easier. Shorter? Yes. Easier? Very debatable.

> Then it's not perfectly readable. That, or your definition of readable is useless because then any programming language is readable given enough study time.

Given a fragment of Chinese, if you do not know Chinese, would you say it is unreadable?

What possible definition of "unreadable" could you have that would make that a useful statement?

No, I don't think speaking to a language as being "unreadable" is particularly helpful. A very careful reader might interpret your claim that "K is unreadable" as "gjulianm can't read K" but I wonder what exactly is the point of even saying it in the first place? Maybe you mean "approachable" -- a fully reasonable statement, but one reflecting your inability to say anything else meaningful about it.

On the other hand, if I know Chinese, it's entirely possible for me to point to a gibberish statement (for example, on a tattoo), and say that it's unreadable. I'm definitely referring to something else here.

Now maybe we just accept having two different definitions for "readable", but I think yours has real harm. I think referring to something that you do not understand with the same word that means nobody can understand it might confuse people, and I just cannot understand for the life of me, why so many programmers would want to intentionally confuse people like this.

If I pick up some random K code, I can read it. I could make a change to it, and other K programmers will understand what I did and why. That's good enough for me.

> I still haven't seen any example where it is actually easier. Shorter? Yes. Easier? Very debatable.

I think the max of list example is a good one. I've also previously observed some examples that might be less mathematical.

[1]: https://news.ycombinator.com/item?id=22467866 - Here I beat a custom "database" by 50x with one line of q (a very similar language to k)

[2]: https://news.ycombinator.com/item?id=21799376 - A six-character solution to the rock-paper-scissors game, using q to analyse the creation of the solution

[3]: https://news.ycombinator.com/item?id=21680743 - Here's our friend the bin operator again, showing how it appears in production.

[4]: https://news.ycombinator.com/item?id=19659590 - One of my favourite k/q features is views.

[5]: https://news.ycombinator.com/item?id=16851862 - String parsing is "obvious" in k/q where it isn't in other languages

In these cases (and many others) q/k is "easier" because it gets the job done faster. If you can beat my k with your JavaScript then good for you (And I'd like to see it! I can always get better!), but I usually can't. I find the solution faster with k, the program runs faster with k, and those are the things that matter to me when I say "easier".

I absolutely do not mean "more approachable".

Re: Stages of denial in encountering K

#227

Post by PeterisP »

magicalhippo wrote: post #188
brokensegue wrote: post #113

Earlier quoted context omitted.

literally any of it. I don't know perl but I can read and modify well written perl scripts in a pinch with maybe a little googling. I know several major languages and this program looks like noise to me. is it standard to give functions terrible names? and to not pull out constants to make things understandable? i'm unclear what semi-colons, colons and commas do here or why the lines are so long.

> I know several major languages and this program looks like noise to me. That's because it is. As pointed out repeatedly, one of the main goals of the program is to minimize the program size, in terms of bytes. Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.

"one of the main goals of the program is to minimize the program size, in terms of bytes." -> so, you're claiming that code-golf is actually the intended goal?

It seems that there's a fundamental disconnect of values here. It seems to me that you're optimizing for something that's nearly insignificant (to me) at the expense of qualities that actually matter for me and almost everyone else.

In essence, if that code could be modified to take twice as many bytes but allow other programmers to save 10 seconds when figuring out what exactly does 'k' (the first symbol introducing in that raya.k example) means in this context, then it should and even must be done. If there's a tradeoff between program size in bytes and readabilty, then there's no question that program size in bytes should be sacrificed for even small improvents in readability.

That raya-k is an excellent example - it's a nice, terse proof-of-concept, but it's not finished until it's been "ungolfed" for maximum readability (and likely at least twice the code size), and is currently not usable for illustrating the language unless you intentionally want to pick a bad, unoptimal (i.e. heavily optimized for a wrong metric at the expense of important things) example as an illustration. Terseness is nice-to have if all other things are equal, but sacrificing readability to improve terseness is ridiculously maladaptive.

Re: Stages of denial in encountering K

#228

Post by Firadeoclus »

qayxc wrote: post #216
geocar wrote: post #214

Earlier quoted context omitted.

> You are making the same arguments as Perl fanatics who used every possible abbreviation in their language 25 years ago. How much of that is even comprehensible now without a major reverse-engineering effort? Perl is inscrutable in a different way: It is impossible to insert an instruction reliably into a statement allows the student to observe what is going on without changing it: Program flow can change mid-senten…

> I've been looking at K code for more than five years at this point, and I don't have any problems reading code written by K programmers a decade ago or more. I think you're completely missing the point here. The assumption wasn't that old code is unreadable, but that you have trouble understanding it after NOT looking at ANY K code for five years.

If that's true it's a trade-off which may or may not be worth it. It's not inherently bad or unacceptable.

Many other skills require a period of re-learning after a five year gap. Where do you believe K sits on the scale of re-learning effort involved, riding-a-bike seconds to minutes, or months to years of effort?

I've only learned a little APL so far, and that really didn't take much effort so I'd be surprised if it would take me more than a month of dedicated learning to get fluent in the language. If that's what it takes to learn from scratch (the language, not the concepts common to maths and many programming languages), I would expect re-learning to be possible in less than a week. That does not strike me as too big an obstacle in many cases.

Re: Stages of denial in encountering K

#229

Post by geocar »

qayxc wrote: post #216
geocar wrote: post #214

Earlier quoted context omitted.

> You are making the same arguments as Perl fanatics who used every possible abbreviation in their language 25 years ago. How much of that is even comprehensible now without a major reverse-engineering effort? Perl is inscrutable in a different way: It is impossible to insert an instruction reliably into a statement allows the student to observe what is going on without changing it: Program flow can change mid-senten…

> I've been looking at K code for more than five years at this point, and I don't have any problems reading code written by K programmers a decade ago or more. I think you're completely missing the point here. The assumption wasn't that old code is unreadable, but that you have trouble understanding it after NOT looking at ANY K code for five years.

> I think you're completely missing the point here. The assumption wasn't that old code is unreadable, but that you have trouble understanding it after NOT looking at ANY K code for five years.

Fair enough.

I don't see any evidence why that would be true, or even more true than other languages.

Do you have any?

Re: Stages of denial in encountering K

#230

Post by smichel17 »

7777fps wrote: post #149
buzzkillington wrote: post #129

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Write-only_language >Languages that are often derided as write-only include APL, Dynamic debugging technique (DDT), Perl,[2] Forth, Text Editor and Corrector (TECO),[3] Mathematica, IGOR Pro and regular expression syntax used in various languages.

You've got me wondering about the utility of a genuinely write-only language. As a thought experiment, would there be benefit to letting functions only be written once? No-one could come along and break code by changing a function. If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version. A lot of maintenance overhead? Possibly, but tooling would…

The idea is interesting. However, worth noting that you would have to increment main() with literally every change, because when you fix a bug in foo#10 (by rewriting as foo#11), you'll need to update the affected call sites to use foo#11 instead, which means they get incremented, too, so you need to do the same to their callers, all the way up to main.

You'd absolutely need tooling to automate some of this (present a list of call sites; you select which should use the new function). It would also increase the size of your code base by a lot, although I'm not sure that's as much of a problem since we may be spending less time reading code and more just writing a new function.

Post reply on HN