4 ms·

> Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax. Indeed. https://en.m.wikipedia.org/wiki/K_(programming_la

by pjot 2y ago

> Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax. Indeed. https://en.m.wikipedia.org/wiki/K_(programming_language) https://en.m.wikipedia.org/wiki/K_(programming_language)

brookst 2y ago
“Expressive” = like two cats fought while standing on the keyboard
- xwolfi 2y ago
  I work with it daily in a bank, and I couldnt find a better way to express it. Many colleagues throwing their keyboard in despair at this stupid impossible to remember syntax.
  - rak1507 2y ago
    There are a lot of things in various programming languages which are hard to remember, but k and array languages have such a small surface area, not being able to remember it while working with it daily amounts to learned helplessness. (source: mostly amateur k programmer, also worked with it in a bank, find it vastly easier to read/write/remember than most mainstream languages)
  - aguaviva 2y ago
    [flagged]
    - inopinatus 2y ago
      "Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.
      - userbinator 2y ago
        By becoming even more clever: https://www.linusakesson.net/programming/kernighans-lever/index.php https://www.linusakesson.net/programming/kernighans-lever/in...
        IshKebab 2y ago
        Very unconvincing. If you become cleverer you can just write even more clever code and still not be able to debug it.
        chmod775 2y ago
        Great!
        nine_k 2y ago
        It's a nice interpretation. I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
        darkwater 2y ago
        This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
      - chii 2y ago
        > how will you ever debug it? By being so smart that your program has obviously zero bugs in it!
        nosianu 2y ago
        This view is too static. That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes. For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against. In a living environment the software lives too, and keeps changing and adapting.
    - ryanjshaw 2y ago
      The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
      - Moru 2y ago
        You could also say that the average bank/company should have learned from previous mistakes doing exactly that for many decades. Select a language that is well tested, understood and supported. Set a limit on cleverness and instead focus on maintainability and simplicity.
        speed_spread 2y ago
        If only. In my experience, banks end up building a solution that is maintained by 100 mediocre developers that a reasonably smart developer can't make sense of when it behaves erratically or has extremely poor performance.
        ryanjshaw 2y ago
        I described the theory. You have described the practice :)
      - deleted 2y ago
        [deleted]
      - aguaviva 2y ago
        Which was precisely my point (and I agree with all the responses in this thread), though my wording and light sarcasm seems to have been a bit too dry, and didn't quite take up as intended.
      - queuebert 2y ago
        Keeping skill barriers low keeps wages low as well.
  - nine_k 2y ago
    Not that it's impossible to remember, bit it's definitely contrary to most traditional use of the symbols employed in it, though not without logic. My favorite is the functions from io package, called 0, 1, and 2 (yes, numbers) which handle interaction with stdin, stdout, and stderr respectively. In dyadic form they at least have a colon, but in monadic form they look like plain numbers: 1 "Hello world". I suspect that to study k (and use kdb) efficiently, you need to actively forget what you knew about the syntax of other languages, and study k as a language from Mars that happens to map to ASCII characters somehow.
  - anonzzzies 2y ago
    It is really easy to remember; it is so small that remembering is the least of the issue. The rest is just using it a lot; I find it readable and nice to work with. Unlike other some other languages we get shoved down your throats.
- rtpg 2y ago
  I've been messing with Uiua (https://www.uiua.org/ https://www.uiua.org/) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
  - g8oz 2y ago
    Thanks for the link, it looks like a fascinating language
  - dahart 2y ago
    The front page there has examples like “÷3/+∿⊞×⊟×1.5.220×τ÷⟜⇡&asr” - is that closer to noise, or does it actually look more readable than K once you get used to both? I’m kind-of intrigued by the built-in multimedia output, but still this language looks scary and impractical at first glance. How does it compare to using numpy & jupyter? Do a lot of people prefer the extreme tenseness over using typeable keywords? I’m curious why it lets you type the readable operators but wants to turn them into glyphs; wouldn’t it be more approachable, more readable, and make more maintainable code, if it just used the keywords instead of glyphs?
    - rtpg 2y ago
      Well firstly you can just type keywords and they get swapped by glyphs Secondly, the power with Uiua is you can easily split up that expression literally by just hitting enter in some spots (and line swapping but…). You can give names And finally if you are constantly doing operations across arrays it can be more legible to go a symbol like approach, like how most people prefer x+y to add x y. The conciseness helps you build up larger expressions before you need to break things up.
  - PhilipRoman 2y ago
    Cool language. I happened to notice the ⍜ operator, which operates on a transformed array, then reverts the transformation. Not sure if other array languages include this, but it's a really cool idea. I always found the traditional map/filter operators to be limiting in this regard, kind of like trying to write expressions without using parentheses.
hilux 2y ago
But possibly not its maintainability.

by pjot 2y ago

brookst 2y ago

“Expressive” = like two cats fought while standing on the keyboard

xwolfi 2y ago
I work with it daily in a bank, and I couldnt find a better way to express it. Many colleagues throwing their keyboard in despair at this stupid impossible to remember syntax.
- rak1507 2y ago
  There are a lot of things in various programming languages which are hard to remember, but k and array languages have such a small surface area, not being able to remember it while working with it daily amounts to learned helplessness. (source: mostly amateur k programmer, also worked with it in a bank, find it vastly easier to read/write/remember than most mainstream languages)
- aguaviva 2y ago
  [flagged]
  - inopinatus 2y ago
    "Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.
    - userbinator 2y ago
      By becoming even more clever: https://www.linusakesson.net/programming/kernighans-lever/index.php https://www.linusakesson.net/programming/kernighans-lever/in...
      - IshKebab 2y ago
        Very unconvincing. If you become cleverer you can just write even more clever code and still not be able to debug it.
        chmod775 2y ago
        Great!
      - nine_k 2y ago
        It's a nice interpretation. I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
      - darkwater 2y ago
        This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
    - chii 2y ago
      > how will you ever debug it? By being so smart that your program has obviously zero bugs in it!
      - nosianu 2y ago
        This view is too static. That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes. For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against. In a living environment the software lives too, and keeps changing and adapting.
  - ryanjshaw 2y ago
    The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
    - Moru 2y ago
      You could also say that the average bank/company should have learned from previous mistakes doing exactly that for many decades. Select a language that is well tested, understood and supported. Set a limit on cleverness and instead focus on maintainability and simplicity.
      - speed_spread 2y ago
        If only. In my experience, banks end up building a solution that is maintained by 100 mediocre developers that a reasonably smart developer can't make sense of when it behaves erratically or has extremely poor performance.
        ryanjshaw 2y ago
        I described the theory. You have described the practice :)
    - deleted 2y ago
      [deleted]
    - aguaviva 2y ago
      Which was precisely my point (and I agree with all the responses in this thread), though my wording and light sarcasm seems to have been a bit too dry, and didn't quite take up as intended.
    - queuebert 2y ago
      Keeping skill barriers low keeps wages low as well.
- nine_k 2y ago
  Not that it's impossible to remember, bit it's definitely contrary to most traditional use of the symbols employed in it, though not without logic. My favorite is the functions from io package, called 0, 1, and 2 (yes, numbers) which handle interaction with stdin, stdout, and stderr respectively. In dyadic form they at least have a colon, but in monadic form they look like plain numbers: 1 "Hello world". I suspect that to study k (and use kdb) efficiently, you need to actively forget what you knew about the syntax of other languages, and study k as a language from Mars that happens to map to ASCII characters somehow.
- anonzzzies 2y ago
  It is really easy to remember; it is so small that remembering is the least of the issue. The rest is just using it a lot; I find it readable and nice to work with. Unlike other some other languages we get shoved down your throats.
rtpg 2y ago
I've been messing with Uiua (https://www.uiua.org/ https://www.uiua.org/) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
- g8oz 2y ago
  Thanks for the link, it looks like a fascinating language
- dahart 2y ago
  The front page there has examples like “÷3/+∿⊞×⊟×1.5.220×τ÷⟜⇡&asr” - is that closer to noise, or does it actually look more readable than K once you get used to both? I’m kind-of intrigued by the built-in multimedia output, but still this language looks scary and impractical at first glance. How does it compare to using numpy & jupyter? Do a lot of people prefer the extreme tenseness over using typeable keywords? I’m curious why it lets you type the readable operators but wants to turn them into glyphs; wouldn’t it be more approachable, more readable, and make more maintainable code, if it just used the keywords instead of glyphs?
  - rtpg 2y ago
    Well firstly you can just type keywords and they get swapped by glyphs Secondly, the power with Uiua is you can easily split up that expression literally by just hitting enter in some spots (and line swapping but…). You can give names And finally if you are constantly doing operations across arrays it can be more legible to go a symbol like approach, like how most people prefer x+y to add x y. The conciseness helps you build up larger expressions before you need to break things up.
- PhilipRoman 2y ago
  Cool language. I happened to notice the ⍜ operator, which operates on a transformed array, then reverts the transformation. Not sure if other array languages include this, but it's a really cool idea. I always found the traditional map/filter operators to be limiting in this regard, kind of like trying to write expressions without using parentheses.

hilux 2y ago

But possibly not its maintainability.