Hacker News Reader

Comment by fmbb | Hacker News Reader

That javascript version is obviously objectively the best alternative.

I actually prefer the JSONPath version, probably I used to like XPath and I'm not hugely fond of JavaScript.

Yeah, it's not bad. Guido famously preferred the list comprehension style over the functional style, but when you have nested data types and the "monadic style" (ish) functions, it does really make sense. You could imagine it in Python (lets pretend lists have map and filter):

    data['store']['book'].filter(lambda x: x.price < 10).map(lambda x: x.title)

Yeah, not nearly as good. The syntax sugar of a.b instead of a['b'] and arrow functions instead of lambda really does make a pretty big difference.

Best syntax for closures I've ever seen in Scala. Would look something like

    data.store.book.filter(_.price < 10).map(_.title)

Every language should just adapt it.

Raku does a version of that as well, it's sick.

in Raku, this

    data.store.book.filter(_.price < 10).map(_.title)

would be written as

    data.store.book.grep(*.price < 10).map(*.title)

F# just added this syntax:

  let possibleNow = 
      people 
      |> List.distinctBy _.Name
      |> List.groupBy _.Age
      |> List.map snd
      |> List.map _.Head.Name
      |> List.sortBy _.ToString()

Meanwhile JS is still struggling to define even version 1.0 of a pipe operator, and the proposal has been bikeshedded into shabby oblivion with a syntax that's worse than just pulling out lodash pipe() or similar. TC39 does not fill me with hope.

I will never understand why people find the need to cram as much "mystery meat" code into one line as humanly possible. It makes it much harder to understand, debug, and optimize.

It cuts out the programerese and makes it easier to read?

The less clutter there is, the more the remaining elements pop.

Cramming a bunch of chained commands on a single line doesn't reduce clutter. In fact, it increases it.

I’m a fan, but let’s go even further. JavaScript has pleasant definitions of functions with

    filter((x) => x.price < 10)

but why can’t we just write

    filter(x.price < 10)

and add a rule to the JS engine that says “when you encounter a ‘syntax error: undeclared identifier x’, rewrite the code to add `(x) => ` in front of where the syntax error occurred, if and only if this rewrite prevents the syntax error”.

You might protest that reacting to syntax errors by inserting extra code and checking if the errors go away is an insane strategy, but I would note that JavaScript is actually a semicolon-terminated language in which most developers never write a semicolon, and the JavaScript engine is already using this insane strategy on nearly every line of modern JS to insert a semicolon whenever it encounters a syntax error, so it’s obviously practical.

Some languages do this already but with a designated placeholder, like

    filter(_.price < 10)

That may not work because plain underscore is already a valid identifier but another placeholder could potentially be used and no need for the parser backtracking / function insertion (which I don't like the idea of, there may be cases where an undeclared identifier was a bug and it shouldn't be turned into a function)

The problem with your approach is that `filter(x.price < 10)` is perfectly valid syntax, it's filter with a single boolean arg. You need something else to trigger the magic: change `x` to `it` and you have Kotlin and Groovy's shorthand syntax -- you just can't define a variable called `it` anymore. If you want closure semantics on arbitrary undefined variables, I think I might have to slap you on general principle ;)

That's exactly what the Raku Programming Language does. Except that the "x" is represented by "*", so it reads:

    grep(*.price < 10)

This is referred to as "Whatever-currying": https://docs.raku.org/type/Whatever*

I dislike that syntax, but it might be better to instead use a special syntax that can't be the name of any variable, like the asterisk in Raku as mentioned below. In such a case, perhaps the function that would call it should check if the value is already the correct type and use that instead of calling it as a function, since then it would be possible for the filter condition to be a constant true or false that does not depend on the values being filtered (this is not usually useful, but it is more consistent and sometimes it is useful).

I think that the automatic semicolon insertion is a bad feature of JavaScript.

Kotlin has it instead of _

    val numbers = listOf(20, 19, 7, 12)
    val multiplied = numbers.map { 3 * it }
    // [ 60, 57, 21, 36 ]

The Raku programming language has, with some tweaks:

    data.store.book.grep(*.price < 10).map(*.title)

Although personally I would write that as:

    data.store.book.map: { .title if .price < 10 }

which combines the filter / map into a single operation.

https://raku.org

You know, I think you're right. I never realized that Python list comprehension is basically filter/map (and reduce is an external function). That is actually pretty horrible syntax for it from that perspective.

It's also the one that's least optimizable.

If you're that focused on optimization you wouldn't be traversing JSON.

As an aside the js example above could be simplified to a reduce().

Reply on news.ycombinator.com