Live data from Hacker News

Stages of Denial

beyondloom.com

11–20 of 119 posts

Re: Stages of Denial

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

Re: Stages of Denial

#12
post #8

One 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 t…

K is not an esolang and was not designed for golf; it has real users. https://en.wikipedia.org/wiki/K_(programming_language)

Also, the primary goal is not always speed... runtime speed or speed of development. There are other things we trade off for all the time.

Re: Stages of Denial

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

As APL shows, you then need quite a large alphabet of symbols, though.

But I'm not strongly in either camp. A few common branches of mathematics taken together have quite a large alphabet of symbols, too, and we work well with it. It feels like symbolic notations can seem obtuse at first and be hard to get into, but once you're used to it the alternative may appear worse.

Re: Stages of Denial

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

Re: Stages of Denial

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

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

Re: Stages of Denial

#17
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 ! [ + ] /

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

Lisp is polish notation for trees of variable arity. hence all the parens - you need some way to group them.

So in some K flavoured LISP I think it would be

    ((/ +) (! 100))

Re: Stages of Denial

#19
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 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 "°"?)

Re: Stages of Denial

#20
post #8

One 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 t…

It should be noted that, according to Wikipedia, the K language isn't a toy language like Brainfuck but an actual language successfully used for a suite of financial software. It was developed for this purpose, not for code golf.
Post reply on HN