4 ms·

K is being used in the financial market for at least 25 years, having been dominant through most of this time. It's certainly not a toy language. Although I'm

by haolez 7y ago

K is being used in the financial market for at least 25 years, having been dominant through most of this time. It's certainly not a toy language. Although I'm not a K programmer (I've done some J in the past), the point that K programmers make is that the code IS readable once you get used to it. One of the benefits commonly mentioned is that you can keep the whole program in your mind at once. I can't do that with my own Go and Python programs :)

magicalhippo 7y ago
But with proper code, you shouldn't need to keep the whole program in your mind at once. You need the high-level overview, but the pieces shouldn't require you to know the details about "far away" code.
- smabie 7y ago
  And yet, they do. We as developers are so bad at building and maintaining abstractions that maybe we should just do away with most of them. I'm not convinced that layers upon layers of abstractions even help at all; K's approach of destroying abstractions is probably a better way to program. I think we've hit an inflection point in the last 10 or 20 years where the stack is so complex that absolutely no one can understand it. This is a natural consequence of abstraction: it never stops and is self-justifying. It's possible that we just need to stop creating "elegant" class hierarchies or free monad or whatever and just write some compact, blazing fast, and unabstracted code. k/q is interesting because it doesn't even really have the tools to create abstractions, so you're forced to actually solve the problem at hand from the get-go. And when you do solve said problem, you realize it's 10x shorter than the abstracted program, all fits on one screen, and is even easier to understand. Once you reach that point, you start to question whether current development practices are just cargo-culting.
  - magicalhippo 7y ago
    At work our program is about a million lines of code (plus third party libraries etc). We've got 124 different customer specific file/data integrations. Most of those integrations are file based, and the majority of them also involve us fetching or uploading via HTTP or (S)FTP. Doing low-level file I/O, socket I/O, handling low-level HTTP and FTP code for each one that needs it, parsing XMLs from scratch five dozen times, doing all those integrations without abstractions... how is that an improvement? And reducing line count by a mere 10x would do nothing for keeping it all in the head at one time. Even if you could get it down by 1000x, I don't think you'd accomplish much because the logic still has to be there.
    - haolez 7y ago
      Chuck Moore, the creator of Forth, created a CAD system for microelectronics with a tiny fraction of code that mainstream products required. With our bloated stacks, the most used CPU instructions that our binaries use are the ones moving data. We are not using the computers to compute, but just to move data around. That just feels wrong. K, APL, Forth and the likes are living proofs that there are other ways to solve complex problems.
      - magicalhippo 7y ago
        > We are not using the computers to compute, but just to move data around. That just feels wrong. That is because moving data around is a very useful thing. In fact, our entire product is almost entirely about moving data. Using it, our customers don't have to move data by hand. They don't have to look at invoices and fill in forms with a pen, put those in an envelope and send it to the government. Instead our product can do that. And it can be smart about which data to move, when to move it, and where to move it. That's where the small bit of computation comes in.

by haolez 7y ago

magicalhippo 7y ago

But with proper code, you shouldn't need to keep the whole program in your mind at once. You need the high-level overview, but the pieces shouldn't require you to know the details about "far away" code.

smabie 7y ago
And yet, they do. We as developers are so bad at building and maintaining abstractions that maybe we should just do away with most of them. I'm not convinced that layers upon layers of abstractions even help at all; K's approach of destroying abstractions is probably a better way to program. I think we've hit an inflection point in the last 10 or 20 years where the stack is so complex that absolutely no one can understand it. This is a natural consequence of abstraction: it never stops and is self-justifying. It's possible that we just need to stop creating "elegant" class hierarchies or free monad or whatever and just write some compact, blazing fast, and unabstracted code. k/q is interesting because it doesn't even really have the tools to create abstractions, so you're forced to actually solve the problem at hand from the get-go. And when you do solve said problem, you realize it's 10x shorter than the abstracted program, all fits on one screen, and is even easier to understand. Once you reach that point, you start to question whether current development practices are just cargo-culting.
- magicalhippo 7y ago
  At work our program is about a million lines of code (plus third party libraries etc). We've got 124 different customer specific file/data integrations. Most of those integrations are file based, and the majority of them also involve us fetching or uploading via HTTP or (S)FTP. Doing low-level file I/O, socket I/O, handling low-level HTTP and FTP code for each one that needs it, parsing XMLs from scratch five dozen times, doing all those integrations without abstractions... how is that an improvement? And reducing line count by a mere 10x would do nothing for keeping it all in the head at one time. Even if you could get it down by 1000x, I don't think you'd accomplish much because the logic still has to be there.
  - haolez 7y ago
    Chuck Moore, the creator of Forth, created a CAD system for microelectronics with a tiny fraction of code that mainstream products required. With our bloated stacks, the most used CPU instructions that our binaries use are the ones moving data. We are not using the computers to compute, but just to move data around. That just feels wrong. K, APL, Forth and the likes are living proofs that there are other ways to solve complex problems.
    - magicalhippo 7y ago
      > We are not using the computers to compute, but just to move data around. That just feels wrong. That is because moving data around is a very useful thing. In fact, our entire product is almost entirely about moving data. Using it, our customers don't have to move data by hand. They don't have to look at invoices and fill in forms with a pen, put those in an envelope and send it to the government. Instead our product can do that. And it can be smart about which data to move, when to move it, and where to move it. That's where the small bit of computation comes in.