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

61–70 of 119 posts

Re: Stages of Denial

#61

Post by DanielR31D »

goto11 wrote: post #54
turbinerneiter wrote: post #47

I recently started using rust-analyzer with vscode. One common sight is this: thing .stuff() .other() .whatevs() Each of the calls returns a different type. Rust-analyzer displays the return type of each call to the right of it. I imagine something similar could reconcile the benefits of terseness with readability and discoverabilty. The blog post already has the prototype: + / ! 100 plus reduce range 100 Imagine the…

> 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

Re: Stages of Denial

#62

Post by LAC-Tech »

zdkl wrote: post #53
LAC-Tech wrote: post #17

Earlier quoted context omitted.

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

Or in clojure with the threading macro (->> 100 range (reduce +)) which is equivalent to this, without the macro (reduce + (range 100))

yes, quite a bit more long winded than K

Re: Stages of Denial

#63

Post by still_grokking »

neolog wrote: post #50
anyfoo wrote: post #13

Earlier quoted context omitted.

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.

> As APL shows, you then need quite a large alphabet of symbols, though. I count 71, which doesn't seem like a lot.

That's more than key-words in most languages, I think.

Re: Stages of Denial

#64

Post by jasonwatkinspdx »

BugsJustFindMe wrote: post #30

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

Yeah, ever since running into this little snippet eons ago, I've found the symbols are better argument for APL style languages quite weak: http://nsl.com/papers/kisntlisp.htm

Since the arity of all the primitives are known there's less parens than lisp. That seems like the clear sweet spot to me.

And I think this is born out with K the product. One of the things they added with Q is a more text oriented syntax.

The big a-ha in APL style languages is shifting from thinking about loops and iterating over single elements to transforming tensor like objects. It's a powerful approach no matter what language and syntax you use.

Re: Stages of Denial

#65

Post by TeMPOraL »

smoldesu wrote: 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 language and APL family languages are serious business, though. And they get a head start on "extensibility" and other nice practical properties - notice how all those single-character operations are inherently and extremely composable.

Re: Stages of Denial

#66

Post by goto11 »

LAC-Tech wrote: post #59
goto11 wrote: post #58

Earlier quoted context omitted.

It is a typical language-comparison strawman. He is writing list.reduce((x,y)=>Math.max(x,y)) To get the max number in a list. And he is "winching" because he can't write: list.reduce(Math.max) Because the variable arity of max does not play well with reduce. But because of the variable arity he can write: Math.max(...list) Which is even simpler. So he deliberately writes overly complex JavaScript code to show how th…

IIRC the spread syntax only works with relatively small arrays, because it's function application at the end of the day. So worthwhile keeping in mind that the nice JS code falls apart.

Fair point. In any case, if you wanted to do more than trivial array processing in JS, you would use a library like lodash which have an array max function.

And if you think lodash is still to verbose, you can define your own:

  const å = list => list.reduce((x,y) => Math.max(x, y));
Now you can write å(list) to get the max value of an array!

Re: Stages of Denial

#67

Post by leprechaun1066 »

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

And easier to spot patterns in the source files. Whether someone finds that beneficial or not is subjective I guess, but I think it's useful to be able to immediately recognise what something like +/! is doing whenever you see it in source after using it once or twice.

Re: Stages of Denial

#69

Post by still_grokking »

turbinerneiter wrote: post #47

I recently started using rust-analyzer with vscode. One common sight is this: thing .stuff() .other() .whatevs() Each of the calls returns a different type. Rust-analyzer displays the return type of each call to the right of it. I imagine something similar could reconcile the benefits of terseness with readability and discoverabilty. The blog post already has the prototype: + / ! 100 plus reduce range 100 Imagine the…

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

Re: Stages of Denial

#70

Post by scns »

still_grokking wrote: post #63
neolog wrote: post #50

Earlier quoted context omitted.

> As APL shows, you then need quite a large alphabet of symbols, though. I count 71, which doesn't seem like a lot.

That's more than key-words in most languages, I think.

Quick'n'dirty wetware lookup:

Go: C: ~ 31

C++: > 70

Post reply on HN