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

Stages of denial in encountering K

nsl.com

Post reply on HN
Print view View original

231–240 of 432 posts

Re: Stages of denial in encountering K

#231

Post by brazzy »

iateanapple wrote: post #116
brazzy wrote: post #105

Earlier quoted context omitted.

...and in idiomatic K code, you apparently still need to constantly wonder what 'a' or 'X' means in your current context, with likely 5 different usages on your screen at once.

I have not experienced that. If you see many different usages of the same identifier then it’s probably a common construct/pattern you aren’t aware of. In the same way as ‘i’ tends to be used as the current array index in a for loop - but devs don’t get confused by seeing ‘i’ used in lots of different loops. Or kotlin devs seeing ‘it’ or class based language devs seeing ‘this’.

So you claim it never happens that two people working on different parts of the code decide to use the same identifier for completely unrelated things?

Seems to me that is bound to happen pretty frequently when the expectation is to use only one- and two-letter identifiers.

Re: Stages of denial in encountering K

#232

Post by geocar »

goto11 wrote: post #136
dang wrote: post #107

A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.

I doubt that K can reduce line count by a factor 1000 though. The examples in the article is mostly about shorter identifiers like "!" instead of "range" and a compact notation. That is perhaps a factor 5 not a factor 1000. The example with a for-loop for summing a range is a blatant strawman. In which modern language would that be idiomatic? Furthermore the examples only show a particular use case: Processing lists…

> I doubt that K can reduce line count by a factor 1000 though.

It adds up! Consider something like this:

    (defun count (list)
      (let ((hash (make-hash-table)))
        (dolist (el list)
          (incf (gethash (cadr el) hash 0) (car el)))
        (let (result)
          (maphash (lambda (key val)
                     (push (list val key) result))
             hash)
          result)))
That's just #:'=:

Re: Stages of denial in encountering K

#234

Post by qayxc »

keymone wrote: post #34
duchenne wrote: post #25

> +/!10 I personally find the given example harder to read than the equivalent in python/matlab/javascript with lodash/probably many other languages sum(range(10)) sum(1:10) With "K", you have to know a few new conventions. In the second case you just have to read, and the data flow is more obvious.

As I understand author’s point, your example with “sum” is only valid because “sum” word has very few meanings, especially in software engineering world. Even the word “product” would introduce certain ambiguity in context of real world codebase: is it “math” product or some “domain” product? It’s even worse with most other words. So if in any given codebase you still have to know the specific meaning of every word,…

> So if in any given codebase you still have to know the specific meaning of every word, how is it different from having to know specific meaning of every K symbol?

So you never encountered namespaces then? Because that's why you use namespaces. The number of symbols is limited, which is the reason why the whole "a symbol is more explicit"-argument simply doesn't hold in general. It breaks apart pretty quickly. That's why you'll find the following sentence pretty much verbatim in most maths and cs publications: "Throughout this paper, unless otherwise specified, we use the following notations," followed by half a page of definitions. Plot twist: different authors often use different notation even within the same field of research.

Re: Stages of denial in encountering K

#235

Post by kortex »

saagarjha wrote: post #139

Look, I don't hate K. It's probably a pretty good language for the task it seems to have been designed for, which appears to be numerical computing. Being able to fit an entire code on a screen is an interesting concept; while I'm not completely convinced it should be a goal in and of itself it's certainly something I can't rule out as a possible productivity booster. However, I still find it problematic, and it's no…

> Specifically, the claims it's perfectly readable, and anyone who says anything otherwise is either stupid, lying, or too poor to understand it are not useful.

+1. All of these "compact" languages (I'd even extend it to Perl to some extent, the way some write it), are seriously lacking in the ergonomics department. Sure, J Leet Hacker might have no problem parsing pages of the stuff. What about the coworker with dyslexia, ADHD, vision problem, etc?

Even if you aren't, what are the real gains? It seems resistant to tabcomplete, git diffs are probably near-inscrutable, grepping for snippets is probably an exercise in judicious application of backslashes... it's cute, but I don't see where this holier-than-thou is coming from (not that ANY language justifies that attitude)

Edit: oops, touched a nerve, I see. I'll add to the above the 7 +/-2 rule [0]. Sure, lets say even you COULD write a program in 1/100th or 1/1000th of the lines in k. I don't WANT a source code that looks like that. Way too much information density.

I'll give them this: perhaps the criticism is that ALGOLikes are too sparse, could stand to be denser, and k is the manifestation of the far other end of the spectrum.

- https://en.m.wikipedia.org/wiki/The_Magical_Number_Seven,_Pl...

Re: Stages of denial in encountering K

#236

Post by cat199 »

ivanbakel wrote: post #211
yiyus wrote: post #187

Earlier quoted context omitted.

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm. It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if…

That's a very convenient analogy for your argument, but it doesn't make sense for programming languages in general. It's not really meaningful to compare the readability of sentences in English versus Chinese. On the other hand, it's both meaningful and important to compare readability of program snippets - and readability is more than just the first-time learning burden. Overly-concise code being difficult to mainta…

> It's not really meaningful to compare the readability of sentences in English versus Chinese.

it is if one speaks both languages and is qualified to comment. part of 'overconciseness' is domain/cultural experience - what is overconcise in one context is not in another.

Re: Stages of denial in encountering K

#237

Post by geocar »

rubyn00bie wrote: post #58

Only because earlier today I so definitely thought about the whole "code is a liability (debt)" reality we all live in... that is to say, I'm spit-balling here: but for once K makes me go "oh shit!" and not because of the craziness of its syntax... rather, if that syntax is so precise/terse, and even if to the outsider it looks fucking insane, does it have a wicked lower TCO because you literally have insanely less l…

> does it have a wicked lower TCO because you literally have insanely less lines of liability in your code, libraries, dependencies, etc?

Yes. q (a language and distribution of k4) has a built-in webserver with websockets, messaging, all types can be serialised over IPC (except pointers to C code) and most data structures have an efficient on-disk representation.

You might've recalled a few days ago someone announced a specialised database for doing "have-i-been-pwned" lookups in 49µsec. I wrote[1] one line of q that is about 10x faster:

[1]: https://news.ycombinator.com/item?id=22467866

It's just a single operation, and it's built-in, so maybe you think Python could just have mmap-efficient variables and a bin operator and you'd be there, but those things don't exist in Python. If I had the same problem as the author, it certainly wouldn't materialise as "custom database" of any kind, because I'd already be done.

In fact, one of the biggest challenges with "big data" is choosing an efficient representation. The author spent a lot of time on this, but my language just had one built-in. How much time? What's the target? I mean, if I've already paid for q it's clearly a no-brainer, but q isn't free either (even if you get it for no cost: you still need to learn it!)

> Is that the reason finance uses it, they maybe empirically know what the rest of us don't seem to grasp? Or just because it's so domain specific? Or... something else entirely?

Back in the day, k was the only thing you could put tick data into. Now there's lots of systems, and computers are a lot faster, so quants can use Python. Their code doesn't need to be "fast", but "fast enough".

My code still needs to be fast though.

Re: Stages of denial in encountering K

#239

Post by Tomte »

I totally buy that this is elegant for small number- or lust-based things, but since a financial database is named as the flagship product: how does I/O look like in K? Both user input and disk access. How do you make a user interface? How do you networking?

Is it still as elegant?

Re: Stages of denial in encountering K

#240

Post by keymone »

qayxc wrote: post #234
keymone wrote: post #34

Earlier quoted context omitted.

As I understand author’s point, your example with “sum” is only valid because “sum” word has very few meanings, especially in software engineering world. Even the word “product” would introduce certain ambiguity in context of real world codebase: is it “math” product or some “domain” product? It’s even worse with most other words. So if in any given codebase you still have to know the specific meaning of every word,…

> So if in any given codebase you still have to know the specific meaning of every word, how is it different from having to know specific meaning of every K symbol? So you never encountered namespaces then? Because that's why you use namespaces. The number of symbols is limited, which is the reason why the whole "a symbol is more explicit"-argument simply doesn't hold in general. It breaks apart pretty quickly. That'…

I didn’t say I buy that argument, it’s just my understanding of it.
Post reply on HN