7 ms·

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

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

geocar 7y ago
> 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 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 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 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 https://news.ycombinator.com/item?id=19659590 - One of my favourite k/q features is views. [5]: https://news.ycombinator.com/item?id=16851862 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".
- wcarss 7y ago
  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, if you work on a CRUD application that handles edge cases for specific customers that someone wrote 11 years ago when you used a different ORM but that still matter today, concision and execution speed aren't really the triumphal traits of the code. Clarity to others who may not be as well-versed as I am is the key thing I care about. Does Javascript, or Python, or whatever else achieve that? Gosh, I don't know. But I'm scared of thinking about k as a total novice, so... I think they win against it up to some point. Maybe the level at which I'd know enough k to not be bothered by it is low enough that this doesn't matter, but ... it's still scary! If I feel that way, why would I choose to use it knowing that I'd need to find the rare someone who overcame that fear, just to work on my CRUD app? This isn't k's fault, but k is not the right choice here, and so k has lost on this attribute of approachability, which is "readability for novices", and is the most valuable for a huge number of people.
  - deleted 7y ago
    [deleted]
  - geocar 7y ago
    I mean, if you work on a CRUD application, you're kindof stuck where you are. If it's written in Python, I think it's naive to think that your JavaScript knowledge will be very helpful: So many things are just too different. The JavaScript developer is looking for promises and maybe event streams, but 11 years ago, Python asyncio was uncommon, so you've got a thread-per-worker model. It's terrible any way you cut it! What you've got that's similar: Block structure, single dispatch, everything's an atom, and a few seemingly familiar keywords like "for" and "if" that despite working differently, often appear in familiar patterns. I mean, how different is for k in x: than x.forEach(k =>? It seems like enough of these things dominate those first few steps into the unknown that they provide a comforting handrail into the descent into the coming madness, but it's difficult for me to believe it provides anything more than that. And it's my experience that kind of comfort can be a lie: To read a fragment of well-documented code, to be amazed in the work and thought that clearly has gone into it, only to discover that fragment contained a bug I skipped over (since that area was so well tested and so clearly good) simply because I didn't bother to actually read it. So now I read. And maybe I read JavaScript and Python a little slower than others, what's important to me is that I also read JavaScript and Python slower than I read k. I think that's a valuable trade. But I think you're touching on something important: It's very difficult to mix in a little bit of k into an existing application to "try it out". I hope that there may be things we can do to the environment to make k more accessible and approachable that don't involve trying to cut out this valuable thing, because this thing that makes k unique is just so good I don't want to give it up.
7thaccount 7y ago
Truly grokking Python as a first language also took me a few months of studying it and writing it, so the author is probably trying to say it's the same as any technology. The only caveat is once you learn something like Algol, you can kind of pick up similar ones fairly quick, while something like APL or K requires you to start over again.
- gjulianm 7y ago
  Grokking a language in a few months is different from being able to just read a language in a few months. It's not just the paradigm change: Haskell, Julia, Mathematica or MATLAB for example are far, far more readable than K.
  - 7thaccount 7y ago
    I think Julia, Mathematica, and Matlab aren't too bad, but have never had too much luck with Haskell despite spending time reading many blog posts and an entire book. APL was MUCH easier for me personally to start doing real things with quickly. Maybe because my experience is almost entirely with dynamic languages, I don't know. Point is, readability isn't an absolute. Haskell is easier for you, but APL is easier for others too.

geocar 7y ago

> 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 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 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 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 https://news.ycombinator.com/item?id=19659590 - One of my favourite k/q features is views. [5]: https://news.ycombinator.com/item?id=16851862 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".

wcarss 7y ago
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, if you work on a CRUD application that handles edge cases for specific customers that someone wrote 11 years ago when you used a different ORM but that still matter today, concision and execution speed aren't really the triumphal traits of the code. Clarity to others who may not be as well-versed as I am is the key thing I care about. Does Javascript, or Python, or whatever else achieve that? Gosh, I don't know. But I'm scared of thinking about k as a total novice, so... I think they win against it up to some point. Maybe the level at which I'd know enough k to not be bothered by it is low enough that this doesn't matter, but ... it's still scary! If I feel that way, why would I choose to use it knowing that I'd need to find the rare someone who overcame that fear, just to work on my CRUD app? This isn't k's fault, but k is not the right choice here, and so k has lost on this attribute of approachability, which is "readability for novices", and is the most valuable for a huge number of people.
- deleted 7y ago
  [deleted]
- geocar 7y ago
  I mean, if you work on a CRUD application, you're kindof stuck where you are. If it's written in Python, I think it's naive to think that your JavaScript knowledge will be very helpful: So many things are just too different. The JavaScript developer is looking for promises and maybe event streams, but 11 years ago, Python asyncio was uncommon, so you've got a thread-per-worker model. It's terrible any way you cut it! What you've got that's similar: Block structure, single dispatch, everything's an atom, and a few seemingly familiar keywords like "for" and "if" that despite working differently, often appear in familiar patterns. I mean, how different is for k in x: than x.forEach(k =>? It seems like enough of these things dominate those first few steps into the unknown that they provide a comforting handrail into the descent into the coming madness, but it's difficult for me to believe it provides anything more than that. And it's my experience that kind of comfort can be a lie: To read a fragment of well-documented code, to be amazed in the work and thought that clearly has gone into it, only to discover that fragment contained a bug I skipped over (since that area was so well tested and so clearly good) simply because I didn't bother to actually read it. So now I read. And maybe I read JavaScript and Python a little slower than others, what's important to me is that I also read JavaScript and Python slower than I read k. I think that's a valuable trade. But I think you're touching on something important: It's very difficult to mix in a little bit of k into an existing application to "try it out". I hope that there may be things we can do to the environment to make k more accessible and approachable that don't involve trying to cut out this valuable thing, because this thing that makes k unique is just so good I don't want to give it up.

7thaccount 7y ago

Truly grokking Python as a first language also took me a few months of studying it and writing it, so the author is probably trying to say it's the same as any technology. The only caveat is once you learn something like Algol, you can kind of pick up similar ones fairly quick, while something like APL or K requires you to start over again.

gjulianm 7y ago
Grokking a language in a few months is different from being able to just read a language in a few months. It's not just the paradigm change: Haskell, Julia, Mathematica or MATLAB for example are far, far more readable than K.
- 7thaccount 7y ago
  I think Julia, Mathematica, and Matlab aren't too bad, but have never had too much luck with Haskell despite spending time reading many blog posts and an entire book. APL was MUCH easier for me personally to start doing real things with quickly. Maybe because my experience is almost entirely with dynamic languages, I don't know. Point is, readability isn't an absolute. Haskell is easier for you, but APL is easier for others too.