I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like:

  users.asSequence()
    .filter { it.lastName.startsWith("S") }
    .sortedBy { it.lastName }
    .take(3)

    sorted((u for u in users
           if u.last_name.startswith("S")),
           key=lambda u: u.last_name
    )[:3]

    sorted((u for u in users
           if last_name(u).startswith("S")),
           key=last_name
    )[:3]

On top of the lessened readability, the Kotlin version makes it very easy to add, subtract, or comment out lines/actions which really helps when debugging. The Kotlin version is almost identical in structure to how you’d do it in Rust, Elixir, etc.

It should also be noted that Python would allow a more functional style, possibly leaving out the list comprehension.

It does contain a generator expression though, which is the same as a list comprehension in general structure, but slightly more confusing because it doesn't have the relationship to lists that square brackets in a list comprehension would have given it.

My point, though, was that not being able to tell the difference was a key "tell" that the comment author was not very familiar with Python — in some contexts, that would tend to undermine credibility in their comment (and then it would be rude to point it out), but in this context, it probably makes their opinion more objective.

The map filter chaining is obviously simpler, but python code is not that difficult and it's a no brainer task anyway.

Python is for the most part overrated when it comes to these things, IMO. It's a nice enough language but it's aged badly and has an undeserved reputation for concision, readability and being "simple".

The method chaining syntax and the query syntax are alternatives. I think most devs lean towards the former, considered to be cleaner... whereas the latter is probably easier to learn in the beginning, to those unfamiliar with piping/functional style - owing to its SQL feel-alikeness.

ReSharper would offer converting the latter to the former, and that's how I learned method-chaining LINQ back in the day.

I think if you like this idea, you will really like the book. Better still, you can download the pdf for free.

[1] https://en.wikipedia.org/wiki/Anaphoric_macro [2] http://www.paulgraham.com/onlisp.html

  users.asSequence()
    .filter { user -> 
      user.lastName.startsWith("S") 
    }
    .sortedBy { user -> 
      user.lastName 
    }
    .take(3)

Probably before then too.

(He'd also written about that more at length in the 1990s in On Lisp, but many more people became acquainted with his language-design ideas in the 2001–2003 period, thanks to Lightweight Languages and his increasingly popular series of essays.)

Anyway, I'm talking specifically about the use of the identifier "it" in Kotlin, not implicitly or contextually defined identifiers in general, which are indeed a much more widespread concept, embracing Perl's $_ and @_, awk's $0 (and for that matter $1 and $fieldnumber and so on), Dyalog APL's α and ω, Smalltalk's "self", C++'s "this", dynamically-scoped variables in general, and for that matter de Bruijn numbering.

Compared to the existence of Perl, yes. Anyone who does any amount of Perl learns that $_ is the implicit argument ("like 'it'") to most functions. It's pretty much one of Perl's main deals. The talk has about 100K views on YouTube, which is pretty good, but Perl is in another league.

Though I will conceed that I also find the fluent interface variant nicer.

  users.apply {
      asSequence()
      filter { it.lastName.startsWith("S")
      sortedBy { it.lastName }
      take(3)
  }

Many have tried and failed, Google and Dropbox to name a couple, and countless other attempts.

Lastly, AFAIK, CPython's FFI API is actually more of a problem than the dynamic semantics of the language. You can expose Python objects directly to C code. That makes it very hard for a JIT to represent said Python objects in an efficient way internally.

That's not universally true. C# has more features than Java but is generally easier to read and the intent of the code is easier to follow. The lack of features, like properties or unsigned integers, leads to Java coders creating much more convoluted solutions.

If languages with less features were universally better we would all be using C and BASIC for everything.