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

91–100 of 119 posts

Re: Stages of Denial

#91

Post by kleene_op »

In my opinion, the conceal feature in Vim provides the best of both world to the name vs symbol problem.

When you want to review your code, you just go into normal mode, concealing all lengthy but frequent names into appealing symbols. When you want to write code, you switch to editing mode and all symbols on the editing line turn back into names

I use this feature mostly with python code. One liners making proficient use of lambdas, maps, reduces, and other functional treats are satisfyingly condensed, reducing the amount of attention required to parse each line.

No need for custom keyboards. People don't have to parse arbitrary symbols to understand what I wrote because the underlying code remains vanilla.

A drawback is that the apparent conciseness tricks me into writing very big one-liners difficult to parse when all terms are expanded.

Re: Stages of Denial

#92

Post by gjulianm »

DanielR31D wrote: post #61
goto11 wrote: post #54

Earlier quoted context omitted.

> Imagine the second line being added in by your ide in a light gray. So what would be the benefit compared to just writing `plus reduce range 100`?

less keystrokes

It's a very weak benefit. I don't know about you but most of my time programming is spent thinking about the program, not writing it. In fact, this would only increase the time I need to think about how to write things (what was the symbol for reduce again?)

Re: Stages of Denial

#93

Post by still_grokking »

nextaccountic wrote: post #79
still_grokking wrote: post #69

Earlier quoted context omitted.

But why not just write (0 to 99).sum That's not much longer, and quite readable even for the uninitiated. (It's a Scala expression, so not made up).

in rust you would write (0 .. 99).sum() for range not including 99 or (0 ..= 99).sum() for range including the 99 which makes me think that i don't know how to read (0 to 99) unless i learn whether it's exclusive or inclusive (but at least it's googlable, unlike a random looking operator)

The "to" method on an Int creates an inclusive Range.

There is also an "until" method which would create the noninclusive Range (which would be actually closer to the original code as it would be "0 until 100").

The Rust syntax is not better. Maybe you could come up what means what if you see it in comparison (this would also work maybe for the Scala code).

The K example has even two implicit assumptions: It's an noninclusive range starting at zero. (They write on the Wikipedia page where I looked this up, as I don't know K, that the range is over "nonnegative integers" lower than the given one. But "nonnegative integers" means usually, but not always, the natural numbers, so zero not included; this makes it even more inconclusive than the Rust or Scala code snippet, imho. I had to look on examples to find out whether zero is included or not in "!").

Re: Stages of Denial

#94

Post by gjulianm »

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 of the most important aspects of programming languages is that they need to be used, and K is the single hardest language that I've tried to understand, even with documentation on the other screen and reading just short snippets. A language that people will ignore because they don't even know where to start reading is not that good of a language.

Re: Stages of Denial

#95

Post by vanderZwan »

> list.reduce((x,y)=>Math.max(x,y))

Honestly, while I like the clarity, I would still dislike it in JavaScript for performance reasons, because in JavaScript reduce is not optimized at all. And yes, I do work on a code-base where that difference is significant.

Also, that loop can still be cleaned up a bit in modern JS:

    let max = list[0];
    for (const v of list) {
      if (v > max) max = v;
    }

Re: Stages of Denial

#96

Post by nickray »

still_grokking wrote: post #93
nextaccountic wrote: post #79

Earlier quoted context omitted.

in rust you would write (0 .. 99).sum() for range not including 99 or (0 ..= 99).sum() for range including the 99 which makes me think that i don't know how to read (0 to 99) unless i learn whether it's exclusive or inclusive (but at least it's googlable, unlike a random looking operator)

The "to" method on an Int creates an inclusive Range. There is also an "until" method which would create the noninclusive Range (which would be actually closer to the original code as it would be "0 until 100"). The Rust syntax is not better. Maybe you could come up what means what if you see it in comparison (this would also work maybe for the Scala code). The K example has even two implicit assumptions: It's an non…

Nonnegative always includes zero, unless the author had muddled thinking themselves. Since positive is >0 and negative is =0.

Re: Stages of Denial

#97

Post by still_grokking »

z3t4 wrote: post #43

I already have problems reading arrow/inline functions... for example where a method is called with a function that returns a function... if there is one more (async) call in there my brain starts smoking.

It's likely a mater of what you're used to.

I start to feel uncomfortable when I see an explicit loop.

But that's actually very weird as I write Scala a lot where you use "for" (instead of "do-notation") for monadic computations.

My brain starts smoking when someone uses a "for" as an regular loop! That causes usually a few seconds of complete confusion. :-D

Re: Stages of Denial

#98

Post by compressedgas »

gHosts wrote: post #44

This is either the most important paper in Computer Science.... or a trivial side effect of representing function composition by string concatenation... http://nsl.com/papers/rewritejoy.html

I have come to call:

        [A] a = A
        [A] b = [[A]]
    [A] [B] c = [A B]
        [A] d = [A] [A]
        [A] e =
    [A] [B] f = [B] [A]
This the minimal Joy.

  [[db]fbcabc[da]cfc]da
This program is one I most like.

Vg vf gur cnenqbkvpny pbzovangbe.

Re: Stages of Denial

#99

Post by still_grokking »

nickray wrote: post #96
still_grokking wrote: post #93

Earlier quoted context omitted.

The "to" method on an Int creates an inclusive Range. There is also an "until" method which would create the noninclusive Range (which would be actually closer to the original code as it would be "0 until 100"). The Rust syntax is not better. Maybe you could come up what means what if you see it in comparison (this would also work maybe for the Scala code). The K example has even two implicit assumptions: It's an non…

Nonnegative always includes zero, unless the author had muddled thinking themselves. Since positive is >0 and negative is =0.

OH! That's of course right.

I wasn't precise enough. The Wikipedia page talks actually about "positive" integers, and I transformed this in my head to what should be written there.

Original quote:

> !x enumerate the positive integers less than x.

Re: Stages of Denial

#100

Post by gjulianm »

travisjungroth wrote: post #24
chiph wrote: post #14

{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.

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/wiki/Fibonacci_sequence

Post reply on HN