Live data from Hacker News

Stages of Denial

beyondloom.com

21–30 of 119 posts

Re: Stages of Denial

#21
post #9

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]. 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…

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 indexed optics (mnemonic: indices tell you where you are "at" in the structure you're traversing).

So an operator like `(=)` means "semigroup append something in the monadic state and return the old result". This is the power of a well-chosen symbol language, and I don't know how you'd do this ergonomically and compactly with only named operators.

Re: Stages of Denial

#22

Earlier quoted context omitted.

The trouble in Haskell is that an operator like %%@~ is just an arbitrary name. In languages like K or APL, the combination of symbols is the actual definition.

how is "%%@~" different from, say, "°"? Since they're both designed to be contentless, couldn't you form a bijection between them without losing anything? (And if your objection is atomicity, how do you feel about "%" and "°"?)

The premise here is wrong, because lens operators are very much designed to carry meaning. See my sibling comment (parent->parent->sibling, I guess), but operators with `@` operate on indexed optics, and the leading `%%` means "modify, and collect summary".

Re: Stages of Denial

#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 between ideas.

Re: Stages of Denial

#24
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.

Re: Stages of Denial

#25
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.

The /0 1 gives it away practically immediately for me, but that might just be because I've seen/used that particular example so many times.

Re: Stages of Denial

#26
post #6

Math.max(...list)

Huh, I had no idea that function had variable arity. Thanks.

Funnily enough, that variable arity is mentioned in the article as a nuisance:

> ... wincing slightly at the lambda notation you need to avoid running afoul of JavaScript’s variadic Math.max()...

Re: Stages of Denial

#27
post #9

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]. 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…

As anyone who uses such a language could tell you, you get used to the symbols quite quickly, and commit their meaning into memory. For that reason I mostly view the heavy use of symbols in a programming language as a negative only insofar as it makes it intimidating to newcomers.

The only other thing can I find can be an issue with the heavy use of symbols in a language is that it can lead to a certain degree of inflexibility in the language. There are only so many symbols that can be used, and once they're all used up your options are either use normal variable names (and reduce the number of ideas that can be expressed concisely), or make symbols context dependent.

The designers of k went to some lengths to avoid the use of variable names, so some symbols are better than others in terms of clarity. Some mean the same thing everywhere, but others are heavily context dependent in an effort to reuse the limited amount of symbols they have at their disposal.

k is a great domain-specific language, but struggles at being a good general purpose language for a variety of reasons. I'd love to be able to use it for data processing inside of other languages. Let the other less expressive but more robust languages handle the control flow, library interactions, etc., and then run k code to work with data as vectors and tables. If only k supported n-dimensional arrays, then it'd be very interesting to see what it could do if integrated with something like Numpy, but I could spend all day wishing k was better than it is. I'm very happy with what it's able to do, and generally groan when I find myself having to use other less expressive data processing tools (which is practically everything).

Re: Stages of Denial

#29
post #5

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

Iverson wanted consistent symbols and rules for math notation. So it's math first, then programming language next. Makes it extremely strong with describing algorithms, but gets a bit complicated for programming.
Post reply on HN