BC: Do you ever look at your own code and think, "What the hell was I doing here?"
AW: No, I guess I don't.
BC: Wow! I confess that I tend to write comments for my future self. I know that when I come back to code I've written, I often don't recall instantly what the problem at hand was or how I solved it. Now you've got me thinking that maybe I'm just in the wrong language. When you're at this higher level of abstraction, maybe it's easier to see your intent.
In terms of debugging your code, obviously the power of a terse language such as K or Q is that, presumably, it's easier to find bugs by inspection. How do you debug them?
AW: In C I never learned to use the debugger so I used to never make mistakes, but now I make mistakes and I just put in a print statement. K is interpreted, so it's a lot easier. If I'm surprised at the value of some local at some point, I can put in a print, and that's really all I do.
BC: That works well when you have deterministic inputs. What if the nature of the problem is just less reproducible—for example, if you were in an event-driven system where you had a confluence of events that led to a problem?
AW: It has been 20 years now that I've had Wall Street customers—they're doing 2 billion transactions a day and they have trillion-row databases—and in those 20 years, there was one time where we couldn't reproduce the bug. That was nasty. I knew the kinds of operations that they were doing and I finally found it by just reading my code.
=================================================
I can't believe, well I guess I can, and have to, that people out there can be this good. Is there something missing from the reality painted here?
In general, Mr. Whitney seems like a freakin' genius, and I'm gonna take a stab at learning some K just to see what it provides. For those interested, from a previous thread today about Mr. Whitney's work, is Kona an open source implementation of K:
I had dealings with him about 15 years ago, and he really is that good.
However, you need to appreciate he's that good because he's able to see solutions that are easy to implement, and not that he has any special implementation talent. K itself is tiny. The programs he's written in it are an order of magnitude less, yet do a frightening amount for their size.
Yes, he is that good. I worked directly with him for a few years and it deeply changed my long term approach. Side effect is that it became harder to deal with the "normals" ;-) seriously though, it made me very impatient with the sorry state of the "state of the art" in the valley.
Just grokking K had that effect on me ... I can't even estimate how much farther that will go if I had a chance to work with Arthur.
And I keep thinking "ignorance is bliss" might have been right in this respect - perhaps I would have been better off had I not lost my appreciation for the (now obviously sad) state of software construction. (Engineering it is clearly not, by and large).
No, I wouldn't go back. That said, it has made it rather difficult to fit comfortably in standard settings. I've been successful so far but taking Arthur's lessons and applying from various domains, to software, and into cluster/system/soc arch in my case, has been viewed as rather unorthodox.
I find that especially in the valley, adherence to buzzwords and fashion of the day is a little too common for my taste now.
Very true. It actually bothers me that the incentives in most tech companies would eject his sort of talent fairly fast. Small, simple but highly efficient solutions are not what most people seem to want, and certainly are not valued/rewarded highly enough.
Even the URL is terse. The attitude is "this is so obvious, I don't know why I'm even telling you". And if you work at it, you will eventually realise: yes, it is obvious.
The product is fantastically good at what it does. Maybe with today's SSDs and hundreds of GB of RAM you don't need such highly-optimised software, but it's still something to marvel at, like Petra, or the Merlin engine.
=================================================
BC: Do you ever look at your own code and think, "What the hell was I doing here?"
AW: No, I guess I don't.
BC: Wow! I confess that I tend to write comments for my future self. I know that when I come back to code I've written, I often don't recall instantly what the problem at hand was or how I solved it. Now you've got me thinking that maybe I'm just in the wrong language. When you're at this higher level of abstraction, maybe it's easier to see your intent.
In terms of debugging your code, obviously the power of a terse language such as K or Q is that, presumably, it's easier to find bugs by inspection. How do you debug them?
AW: In C I never learned to use the debugger so I used to never make mistakes, but now I make mistakes and I just put in a print statement. K is interpreted, so it's a lot easier. If I'm surprised at the value of some local at some point, I can put in a print, and that's really all I do.
BC: That works well when you have deterministic inputs. What if the nature of the problem is just less reproducible—for example, if you were in an event-driven system where you had a confluence of events that led to a problem?
AW: It has been 20 years now that I've had Wall Street customers—they're doing 2 billion transactions a day and they have trillion-row databases—and in those 20 years, there was one time where we couldn't reproduce the bug. That was nasty. I knew the kinds of operations that they were doing and I finally found it by just reading my code.
=================================================
I can't believe, well I guess I can, and have to, that people out there can be this good. Is there something missing from the reality painted here?
In general, Mr. Whitney seems like a freakin' genius, and I'm gonna take a stab at learning some K just to see what it provides. For those interested, from a previous thread today about Mr. Whitney's work, is Kona an open source implementation of K:
https://github.com/kevinlawler/kona