Stages of denial in encountering K • Hacker News Board

Re: Stages of denial in encountering K

#261

Post by aw1621107 » Mon, Mar 09, 2020, 2:01 PM UTC

I've seen a few posts here and there over the years about array languages, but I can't recall any (or any discussion in their comments) that have mentioned any disadvantages beyond more human factors.

So for the k/q/APL/array language gurus out there: in what situations would I not want to use k or another array language, if the relative obscurity of the syntax and mental model were not a factor (e.g., assuming you, your team (if any), and anyone who would ever look at your code would be very familiar with the language and idioms)?

I may not want to choose Go or Java because of latency concerns, or Rust because of compilation speed/iteration time concerns, or C/C++ because of safety issues, or Python/Ruby/Javascript because of performance issues. Why would I not want to pick k?

Re: Stages of denial in encountering K

#262

Post by gjulianm » Mon, Mar 09, 2020, 2:02 PM UTC

geocar wrote: post #226

gjulianm wrote: post #209

Earlier quoted context omitted.

> 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 particula…

The comparison with languages as Chinese is not very appropriate because everybody has a native language. In that sense, programmers have more of a 'tabula rasa' (not completely, of course) that makes for more appropriate comparisons of readability. Usually, when people talk about "readable programming languages" the definition is taken as the amount of effort an average programmer needs to read a certain "standard" piece of code. You can of course categorize (readability of mathematical programs, or of system interactions?) and specify (for general programmers? for data scientists? for functional programmers?) but overall that's it.

Regarding your examples:

1. If you are using a database then it's not an argument for the language, I think. 3. A binary search is hardly a selling point of a language. 4. Views are cool, I reckon that. Although K is not unique in that regard. 5. That solution is, from my point of view, suboptimal and non-obvious. It's not only harder to understand than the naive search but it also performs algorithmically worse in all situations: it always performs nm comparisons (n, m being string, substring lengths resp.) plus the hidden cost of the rotation (which could be zero, could be not-zero depending on how is that implemented) plus the AND of every bit, plus the search of the match position.

I also left the second one as the last, because that, to me, is an anti-example. See the things I need to have "in-memory" in order to understand the snippet `Paper`Rock`Scissors@&/"ki"?

"ki"? means search for "k" or for "i"? I have to assume it's what that is, but I can't reconcile that with the documentation of the find function https://code.kx.com/q/ref/find/ because I don't know where comes the function argument.

* / means 'over'. Together with '&' (which somehow is both 'and' and less than? that's very confusing) it looks like it takes the minimum? I honestly do not know what it's meant to do at this point because I don't know what kind of object is "ki"?.

* @ means 'apply' and here I don't get how you are applying three actions to a what, a list? Because I get that ` means 'print'. Knowing what the code does I assume that when it finds 'k' (index 0) does the first action (paper) and so on. Looks like the 'find' function returns the length of the list when an element is not found (weird, because it is a very good way to facilitate mistakes and induce race conditions) so that's how you get 'scissors' in the other cases.

To me it's weird that you put this as an example. A code example that, despite being pretty simple (if the input has k, return Paper, if it has i, return Rock, else return Scissors) I am not able to understand it even with the documentation at hand. Given this example, I find hard to believe that you can find any K code and understand it quicker that you'd do with other programming languages. And I honestly doubt that it's faster than a for-loop in C.

Yeah, you can say you understand it. But you need a bigger "translation table" than in other languages, which adds to the mental concepts that you also need to keep in mind with programming. It's not to say that it's impossible, but it's more mental work for, as far as I have seen, very little benefit. It can work better for you, yes, but it's very possible that it's just that you're used to it and you don't notice the extra burden of dealing with that code.

Re: Stages of denial in encountering K

#263

Post by gnulinux » Mon, Mar 09, 2020, 2:04 PM UTC

smallnamespace wrote: post #241

yiyus wrote: post #187

Earlier quoted context omitted.

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm. It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if…

> Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. I'm not sure Chinese is necessarily a good example for the point you're trying to make. Native Chinese speakers _probably_ spend more effort acquiring full competency in Chinese than native English speakers need to learn English. For one thing, reading and writ…

> hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection).

The claim that noun declension and inflection is harder to learn isn't well founded. If your native language has these, it'll be more natural for you. All languages have semantic declension and inflection, in the sense that context signals the kind of each word even if it's not syntactically inflected. For example in English the position of the word can signal whether a word is an object or subject "John hit Sally" vs "Sally hit John", the order of John and Sally signals who hit whom. In an agglutinate language you could signal this by putting a prefix like "John hit Sallyum" or "Sallyum hit John" would be parsed the same. My native language is Turkish, I've been learning English since I was 5 years old, but this "order matters" thing eternally confused me. It doesn't make sense to me when people say suffixes are more confusing than this order thing.

Re: Stages of denial in encountering K

#264

Post by Veedrac » Mon, Mar 09, 2020, 2:05 PM UTC

geocar wrote: post #232

goto11 wrote: post #136

Earlier quoted context omitted.

I doubt that K can reduce line count by a factor 1000 though. The examples in the article is mostly about shorter identifiers like "!" instead of "range" and a compact notation. That is perhaps a factor 5 not a factor 1000. The example with a for-loop for summing a range is a blatant strawman. In which modern language would that be idiomatic? Furthermore the examples only show a particular use case: Processing lists…

> I doubt that K can reduce line count by a factor 1000 though. It adds up! Consider something like this: (defun count (list) (let ((hash (make-hash-table))) (dolist (el list) (incf (gethash (cadr el) hash 0) (car el))) (let (result) (maphash (lambda (key val) (push (list val key) result)) hash) result))) That's just #:'=:

Python 3.7+: Counter(elems).values()

But we can play this game both ways. What's the K for (Counter(a) & Counter(b)).most_common(3)?

Re: Stages of denial in encountering K

#265

Post by magicalhippo » Mon, Mar 09, 2020, 2:07 PM UTC

kick wrote: post #256

magicalhippo wrote: post #188

Earlier quoted context omitted.

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

Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like. This is wrong. k programs aren't really random at all. It's not even that complicated; it has less than thirty primitives. It's a notation for representing ideas, and it excels at that. Dyalog APL is similarly terse, although less so, and the goal of it isn't to be terse. This criticism stil…

> This is wrong. k programs aren't really random at all.

The k source code posted around here are certainly more random than a similar byte count of say Java code. Try zipping 1000 bytes of either.

> notation isn't golfing, it's a convenient way to express thought

Sure. But up to a point. And it seems to go beyond pure notation. Check out the interpreter posted here: https://bitbucket.org/ngn/k/

It _requires_ a readme file to explain the file names. That's not convenient by any sensible measure. And the same goes for variable and function names. Take the xml parser[1], "xd". How would a new user know what this did without checking the definition?

[1]: https://a.kx.com/a/k/examples/xml.k

Re: Stages of denial in encountering K

#266

Post by [deleted] » Mon, Mar 09, 2020, 2:10 PM UTC

wcarss wrote: post #252

geocar wrote: post #226

Earlier quoted context omitted.

> 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 particula…

Sorry to start popping up on all of your threads! Your points are really good here, and writing code that runs faster and finding a solution yourself faster are clear wins for a language. I think the value of those wins is subjective, though. If you need speed of execution, or if you're working in a green-field scenario and need to get your work done super fast, your wins are the most valuable ones. But for example,…

[deleted]

Re: Stages of denial in encountering K

#267

Post by i_don_t_know » Mon, Mar 09, 2020, 2:11 PM UTC

How does error handling work in K? For example, what happens when you try to read a file that doesn’t exist? How does the read function indicate failure to the caller? How does the caller check and recover (show an error to the user and continue with some default values)?

Re: Stages of denial in encountering K

#268

Post by kick » Mon, Mar 09, 2020, 2:17 PM UTC

gjulianm wrote: post #262

geocar wrote: post #226

Earlier quoted context omitted.

> 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 particula…

The comparison with languages as Chinese is not very appropriate because everybody has a native language. In that sense, programmers have more of a 'tabula rasa' (not completely, of course) that makes for more appropriate comparisons of readability. Usually, when people talk about "readable programming languages" the definition is taken as the amount of effort an average programmer needs to read a certain "standard"…

1. If you are using a database then it's not an argument for the language, I think.

The database is a piece of the language, though, and the language ships with it. Python has a lot of very complex things in its standard library; C without a standard library is foreign to most programmers. Why do they get a pass while k doesn't?

It can work better for you, yes, but it's very possible that it's just that you're used to it and you don't notice the extra burden of dealing with that code.

It's not like 'geocar is foreign to writing in other languages. His GitHub (github.com/geocar) is full of projects in other languages, some fairly recent. This may make sense as an accusation for someone who doesn't write any other code, but I don't think it's a fair accusation here.

If there was some intense burden from writing k in comparison to ALGOL-like languages, would 'geocar have written an operating system in it rather than C? That doesn't seem apparent to me.

Re: Stages of denial in encountering K

#269

Post by yiyus » Mon, Mar 09, 2020, 2:24 PM UTC

ivanbakel wrote: post #211

yiyus wrote: post #187

Earlier quoted context omitted.

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm. It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if…

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…

Analogies are just analogies. The point of my comment was that you need to approach this with an open mind, forgetting what you already know from other languages.

> Overly-concise code being difficult to maintain is a well-accepted fact.

Your well-accepted facts do not apply to this totally different paradigm. You seem to think those well-accepted facts are universal. They are not.

I have spent the last two years learning about array languages and think it is a fascinating topic, so I tried to give some advice (based on my own experience) to those who want to make the same journey. My point is not that you need fluency (you need some fluency to understand anything complicated), it is that the fluency you have in other languages may be counterproductive. Your comment is an excellent example of this.

Try to read a tutorial. Rewrite it using "meaningful names". All we have done that at some point, and all we started finding the sort names more comfortable to work with after a while. Don't take my word, give it a try.

Re: Stages of denial in encountering K

#270

Post by lmm » Mon, Mar 09, 2020, 2:26 PM UTC

kick wrote: post #19

lmm wrote: post #15

Earlier quoted context omitted.

> k is perfectly readable. That's like, one of the biggest points of the post. The post mocks the mindset featured within your comment. It mocks it, but it doesn't present a convincing argument. Switching from an imperative language to K is making several changes at once, so we can't really conclude anything about the details of which changes are good or bad. The closest I've seen to a controlled experiment is someth…

I'm very much a believer in concise notation (more than most people I've worked with), but the advantages of having a name that can be unambiguously spoken are large enough to outweigh a small constant factor. I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's…

> I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's worked with the language and its derivatives agrees that your statement isn't true.

The people who have worked with the language are a small and highly specialised minority of programmers, unusual in many respects. I haven't worked with APL, but I have worked with symbol-heavy Haskell-style code, and I've found that even if these operators theoretically had standardised, pronounceable names, in practice being able to talk about them was a genuine problem. If there's some special difference between APL and symbolic Haskell libraries, what is that difference?