Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stages of Denial

beyondloom.com

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Stages of Denial

#101

Post by gjulianm »

nlitened wrote: post #45
tarxzvf wrote: post #23

Just replace K and JavaScript with German and English to see the vacuity of this argument. Either of several possible representations can become native to one’s thinking. The question is which is a better aid in reaching some non-arbitrary goal. The only merit of K presented and emphasized here was the supposed brevity of its programs. Personally I’ve found the habitable zone somewhere that allows for more air betwee…

How about this: K is an interpreted language, but your whole program's source code plus the interpreter plus the whole database engine fits inside your server's L1 cache, so K programs tend to be faster than their C equivalents (in addition to all the array operations being highly optimized). And you don't get to waste time scrolling, your typical module's code fits on your single screen.

> but your whole program's source code plus the interpreter plus the whole database engine fits inside your server's L1 cache, so K programs tend to be faster

Is that really the bottleneck? I've done quite a lot of profiling on high performance code and I've almost never hit a bottleneck in the instruction cache. Data access bottlenecks or branching hit performance harder and sooner than instruction fetching.

> And you don't get to waste time scrolling, your typical module's code fits on your single screen.

How much of the time you save scrolling is spent on decoding an array of symbols and remembering what those symbols are?

Re: Stages of Denial

#102

Post by WillDaSilva »

nine_k wrote: post #83

> Does giving a K idiom a name make it clearer, or does it obscure what is actually happening? There's a balancing act around that. It's called "abstraction". At some point, you cannot afford to know what's actually happening. If you try, the entire problem won't fit in your head. So you cut the thing you're working with to a name and an interface, and forget what's "actually happening". You do that right in the K co…

I love the idea of using k as a DSL (domain specific language) for working on time-series data. Something like it would also be great for working on n-dimensional arrays, but unfortunately k doesn't really support working with them in any elegant or efficient way.

Python and Numpy would benefit a lot from having something like k to express vector/matrix operations elegantly.

Re: Stages of Denial

#103

Post by the_af »

vintermann wrote: post #85
nine_k wrote: post #83

> Does giving a K idiom a name make it clearer, or does it obscure what is actually happening? There's a balancing act around that. It's called "abstraction". At some point, you cannot afford to know what's actually happening. If you try, the entire problem won't fit in your head. So you cut the thing you're working with to a name and an interface, and forget what's "actually happening". You do that right in the K co…

You certainly can do points-free programming in Haskell. It's the first place I ever heard of it. Ironically, points-free programming in Haskell has a lot of '.' in it.

Haha, I never understood why the point-free (aka "pointless") form in Haskell actually is the form that requires lots of "."!

Re: Stages of Denial

#104

Post by jstanley »

richarme wrote: post #77
goto11 wrote: post #75

Earlier quoted context omitted.

I find it rather weird to compare K to C. In what circumstances would the choice be between K and C? A more reasonable comparison would be between say Python with numerical libraries and K.

K&R is a common nickname for the book "The C programming language" by Kernighan and Ritchie, and a reference to the authors: https://en.m.wikipedia.org/wiki/The_C_Programming_Language

But TFA is about K.

Re: Stages of Denial

#105

Post by andrewl-hn »

secondaryacct wrote: post #42
endgame wrote: post #21

Earlier quoted context omitted.

The lens library has a reasonably consistent visual language baked into it: - Operators containing `%` apply a function to the target (mnemonic: % is "mod" in many languages). - Operators containing `=` have a `MonadState` constraint and operate on the monadic state. - Operators containing `~` operate directly on values. - Operators starting with ` - Operators starting with ` - Operators containing `@` operate on ind…

You wouldnt make it compact, so the new dreaming intern joining your codebase would be able to gloriously produce changes rapidly and get hired under the well intentioned smiles of the rest of the team. Instead, in the kdb team I joined recently (a one-letter, symbol heavy language used by quants), nobody can remember what things do, nobody has time to teach you the insanity of code older than 2 months, and you re in…

I think the K team recognized these issues and tried to address them - at least partially - with Q and it's readable function names and SQL-like extensions. But, AFAIK most Kdb programmers keep writing straight K instead. Don't know why either.

Re: Stages of Denial

#107

Post by rak1507 »

gjulianm wrote: post #100
travisjungroth wrote: post #24

Earlier quoted context omitted.

I think this hints at the main issue people have when reading more terse code: you need to read it slower. If you try to read K at the same speed as C, it’s going to fly by. I can feel this in my own Python code when I write in a more or less compact style. But on the more dense code, if I slow down, I can understand it faster and more clearly than the verbose code.

It's not only slower to read but requires much more context to understand. Take a look at the Rosetta code page for Fibonacci [1]. For most languages you'll be able to mostly identify what each part is doing. They rely on concepts that most programmers consider intuitive. K relies on a completely different set of knowledge that you need to have to even start to grasp what the code is doing. 1: https://rosettacode.org…

I'm not going to deny that learning any array language requires thinking slightly differently (as does any new paradigm), but really this example doesn't use anything particularly strange.

    {x#x{x,+/-2#x}/0 1}
         x                  x is the argument of an anonymous function {}
          ,                 concat
           +/               plus reduce (sum)
             -2#x           last two elements of x
       x f        /0 1      applied x times to 0 1
     x#                     take first x elements

Re: Stages of Denial

#108

Post by aaron-santos »

TheAceOfHearts wrote: post #48

This is a category of cursed knowledge which causes psychic damage to the reader. When you go down certain rabbit holes you develop a fascination with obscure forms of programming and start to realize it has some powerful benefits of which you can never take advantage because it isn't widely adopted. To free yourself from this curse write ten regular for-loops in C and say a prayer to K&R while tighly holding your co…

If you internalize this cursed knowledge, you will see how language[C]-evangelists cherry-pick which dimensions to measure the value/success of a programing language. Don't proceed. It will make you frustrated, cynical, and disillusioned with the state of PL discourse.

Re: Stages of Denial

#109

Post by rak1507 »

gjulianm wrote: post #94

I remember a discussion on HN on this language like a year ago or so. In the end what I got was some extremely weird snippets for very specific little quizzes that someone claimed were faster than with other languages, the argument that "it's shorter" and "but I can work with it". So yeah, if you like it, I get it, go enjoy it. But this smugness of "it's actually better and I'm better for knowing it", it irks me. One…

Where to start reading: https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.... maybe

If you ever feel like trying it again, and get stuck on something, https://chat.stackexchange.com/rooms/90748/the-k-tree is the place to ask :)

Re: Stages of Denial

#110

Post by gjulianm »

rak1507 wrote: post #107
gjulianm wrote: post #100

Earlier quoted context omitted.

It's not only slower to read but requires much more context to understand. Take a look at the Rosetta code page for Fibonacci [1]. For most languages you'll be able to mostly identify what each part is doing. They rely on concepts that most programmers consider intuitive. K relies on a completely different set of knowledge that you need to have to even start to grasp what the code is doing. 1: https://rosettacode.org…

I'm not going to deny that learning any array language requires thinking slightly differently (as does any new paradigm), but really this example doesn't use anything particularly strange. {x#x{x,+/-2#x}/0 1} x x is the argument of an anonymous function {} , concat +/ plus reduce (sum) -2#x last two elements of x x f /0 1 applied x times to 0 1 x# take first x elements

It does have some strange things:

- What's the scope of x? it appears to be the argument of two different anonymous functions.

- Is / both apply and reduce?

- So 'x f list' applies f to list x times. What if I use ',' instead of f? That is, what does 'x,/list-of-lists' do? does it flatten the list of lists and then concatenates x or does it flatten the list of lists x times? It seems confusing to have symbols that act both as operators and as functions.

- Why is '-2#x' "take last two elements of x" and not "negate the first two elements of x"? If I understand correctly, based on the evaluation order you're using it should be the latter, no?

And all of that from a simple Fibonacci function. I can't imagine how difficult it must be to dive into an actually complex codebase. And it's not just about the different paradigm. That's not the problem, the problem is focusing on terseness above all.

I get that once you are deep into a language or codebase you lose sight of the complexities because you get used to them. But it doesn't mean they aren't there.

Post reply on HN