Stages of Denial
beyondloom.com
Stages of Denial
1–10 of 119 posts
Re: Stages of Denial
#2I guess the ending is supposed to be a joke, but because the piece never explains what | means, I couldn’t figure it out.
Re: Stages of Denial
#3I guess the ending is supposed to be a joke, but because the piece never explains what | means, I couldn’t figure it out.
I guess it means "max" or something like that (comparison operation?), and |/ means "max of an array".
Author builds this up by showing how long is writing "max" function with other approaches (iteration, reduce).
Can be wrong though
Re: Stages of Denial
#4I guess the ending is supposed to be a joke, but because the piece never explains what | means, I couldn’t figure it out.
I guess it means "max" or something like that (comparison operation?), and |/ means "max of an array". Author builds this up by showing how long is writing "max" function with other approaches (iteration, reduce). Can be wrong though
Exactly. From the K2 manual [0] referred to in the article, |/ is "Max-Over". The ostensibly-unreadable K manages in two characters what the article's subject and coworker need either three lines of boring loop or one line of a more cognitively-demanding lambda to accomplish.
...FWIW my understanding of the language is such that I would have suspected the last line of the article to read "|/ list". I thought Max-Over needed an argument.
[0] pg36, http://web.archive.org/web/20050504070651/http://www.kx.com/...
Re: Stages of Denial
#5So are array languages polish notation?
+/!100
100 ! [ + ] /Re: Stages of Denial
#6 Math.max(...list)Re: Stages of Denial
#7So are array languages polish notation? +/!100 feels like the opposite way you'd write it in some kind of RPN concatenative language 100 ! [ + ] /
Not quite. + isn’t the last thing done (which it would be in Polish notation). Instead it’s done during the / operation.
Polish notation would be lisp (or the notion most people have for lisp, special forms and macros break it up a bit).
Re: Stages of Denial
#8One important thing to remember about esolangs like this is that theory != implementation. Just because Brainfuck "theoretically" exists as a language doesn't automatically solve issues like memory management or extensibility. Sure, maybe it is more ergonomic to write some functions in K. But, as with most code-golfing languages, the goal isn't to build a better language, it's to build a faster one.
Maybe K can run those programs faster than Lisp/C/$FAV_LANG, but it's ultimately up to a much smarter programmer to implement that bit.
Re: Stages of Denial
#9I'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 read out loud as "percent-percent-at-squiggly" and "hat-dot-dot" stand for (withIndex and toListOf respectively).
But arguably, the ones that are long and seldom used need looking up anyway, and their name is not that much more useful maybe?
[1] Also compare "2+2*8" with "sum 2 to the product of 2 and 8", or even just "sum(2,prod(2,8))".
Re: Stages of Denial
#10So are array languages polish notation? +/!100 feels like the opposite way you'd write it in some kind of RPN concatenative language 100 ! [ + ] /
You read it strictly right to left, weird idea to me but it’s common in the array languages - j and APL do it this way too.
I believe the reasoning is something like Iverson (or maybe Whitney) didn’t like the complexity of PEMDAS in maths so decided on this rule.