Wow, this is art Wonder how many people did not skip to the end and then skim back
Wait... How did that happen.
Stages of Denial
31–40 of 119 posts
Re: Stages of Denial
#32> a more direct translation into another language might look like: range(100).reduce(plus, 0) That's...uhh...one way to do it. But it's a lot shittier to read than sum(range(100)).
Yes, a direct translation. (Using the reduction)
Re: Stages of Denial
#33Math.max(...list)
Got to be careful with the argument spread, since depending on the JS engine and how large the `list` is, you can end up with a RangeError
e.g.,
Math.max(...Array(100_0000).fill(0))
Uncaught RangeError: Maximum call stack size exceededRe: Stages of Denial
#34{x#x{x,+/-2#x}/0 1} I'm sure if you used K for a year or so, that would be obvious and understandable at a single glance. But all I can think of is that I used to see that in my terminal session right after my modem got disconnected.
Been doing k for a bit (under a year). A single glance is optimistic, but probably only took me a few seconds. Almost certainly faster than any equivalent code in any other language. It's even easier if you give it a nice name, like "fib".
What kind of projects does K get used in?
Re: Stages of Denial
#35Earlier quoted context omitted.
Been doing k for a bit (under a year). A single glance is optimistic, but probably only took me a few seconds. Almost certainly faster than any equivalent code in any other language. It's even easier if you give it a nice name, like "fib".
What kind of projects does K get used in?
I don't use it professionally or anything like that but most of the real world use as far as I know is in finance stuff.
Re: Stages of Denial
#36Math.max(...list)
Got to be careful with the argument spread, since depending on the JS engine and how large the `list` is, you can end up with a RangeError e.g., Math.max(...Array(100_0000).fill(0)) results in: Uncaught RangeError: Maximum call stack size exceeded
Bizarre. on V8 this seems to be an underlying limit on Function.prototype.apply -- and in the REPL, it's not even deterministic, somewhere in the neighborhood of 123,125. (side effect of optimization?) It's enforced on the caller side as well, the empty function with no arguments still throws when apply'd too large an array.
It's not at all clear to me why this would be a necessary limit to exist, as functions can't reasonably have more than a few hundred formal parameters so passing 100,000 would always imply using unspread or arguments on the receiver, which could surely trivially handle arbitrarily sized arrays.
Re: Stages of Denial
#37I'm torn. Not about the conciseness of the language overall, but about using symbols vs. names. I do see how the symbols make things more concise, less clutter, and can even make it easier to grasp a piece of code if you are deeply familiar with them[1]. On the other hand, there might be a limit. I do know how it is to use the Haskell lens package only occasionally, and then having to lookup again what the operators…
> I'm torn. Not about the conciseness of the language overall, but about using symbols vs. names. I do see how the symbols make things more concise, less clutter, and can even make it easier to grasp a piece of code if you are deeply familiar with them[1].
I think the "if you are deeply familiar with them" is important. Using non-standard symbols makes comprehension more binary: either you've memorized them and understand or you don't; there's no muddling through, relying on common concepts and terms to make up for incomplete memorization.
That probably also results in a much more binary user base: true-believers who dedicated a bunch of time to become proficient, and non-users who were unable or unwilling to, and not a whole lot in between.
Re: Stages of Denial
#38Earlier quoted context omitted.
Got to be careful with the argument spread, since depending on the JS engine and how large the `list` is, you can end up with a RangeError e.g., Math.max(...Array(100_0000).fill(0)) results in: Uncaught RangeError: Maximum call stack size exceeded
Bizarre. on V8 this seems to be an underlying limit on Function.prototype.apply -- and in the REPL, it's not even deterministic, somewhere in the neighborhood of 123,125. (side effect of optimization?) It's enforced on the caller side as well, the empty function with no arguments still throws when apply'd too large an array. It's not at all clear to me why this would be a necessary limit to exist, as functions can't…
In V8 I believe it's limited by the stack size and when you get a stack overflow that gets converted to a RangeError in JS land.
OTOH, Webkit and Firefox have arbitrary limits 65537, and 500k args.
https://bugs.webkit.org/show_bug.cgi?id=80797 https://github.com/mozilla/gecko-dev/blob/1475b3b0cb274b2a71...
Re: Stages of Denial
#39also posted previously as
Stages of denial in encountering K, March 9, 2020, 422 comments https://news.ycombinator.com/item?id=22504106
Re: Stages of Denial
#40Earlier quoted context omitted.
Been doing k for a bit (under a year). A single glance is optimistic, but probably only took me a few seconds. Almost certainly faster than any equivalent code in any other language. It's even easier if you give it a nice name, like "fib".
What kind of projects does K get used in?
Mainly time-series data processing through kdb+. There's an IDE and language tools for q (which is a thin layer over k) that is primarily written in q called: https://code.kx.com/developer/
Unfortunately it's closed source so I can't share much about the world of application and library development with q/k. If you want to learn more about how it's used though, I'd recommend checking out KX and kdb+.