Hacker News Reader

Actually FP is more often verb-verb as in compose these verby thing together in this way to make a new verb then finally give it a starting noun.

This is an important point. When done well, in FP the data "disappears", i.e. the types control flow and the functions talk about what you're doing. So there's no "find me what I c an do with this object" instead it's "What am I returning?" It sounds the same but it isn't.

Yes, way in the heart of a functional program there's some code sorting lists of ints or something. But by that time, it's all labeled to the point where the functions just tell you what happens. As someone browsing the source, the nouns disappear.

One of the things I like about Java's streams is that it makes the verb-chaining more obvious, at least to me.

list.stream().filter().mapToInt().sum() just reads better to me than sum( mapToInt( filter(list) ) )

I don't enjoy balancing parentheses in Python so I tried to bring Clojure's threading macro into the language...

  def do(x, fs):
      for f in fs:
          x = f(x)
      return x

Which allows left-to-right style programming

  do(list, filter, partial(map, int), sum)

I haven't put this into production code yet, but love pipelining scripts with do

Also see PyToolz's implementation: https://toolz.readthedocs.io/en/latest/api.html#toolz.functo...

They differentiate thread first/last for Fns with arity > 1, just like Clojure.

I made a thing[0] just like that to do pipelined async db queries:

  CompletableFuture<Member> asyncProjectMembers =
    Async.pipeline(Accounts.where("id >= ?", 1000);,
                   (accounts) -> accounts.loadProjects("updated_at >= ?", Instant.now().minusDays(30)),
                   (projects) -> projects.loadMembers());

If you assign the intermediates to variables, each instance will have associated with it the related collection that's queried while avoiding N+1's.

[0] https://github.com/karmakaze/safeql

I know most will disagree but I find code the above hard to read. I'd much prefer

    const people = list.stream();
    const peopleOlderThan50 = people.filter(??);
    const average = peopleOlderThan50.mapToInt().sum() / peopleOlderThan50.length;

Or some such thing. The more complex the chain the harder it is for me to read. Does anyone else have that experience?

There's a spectrum here. Someone even more explicit than you may insist that `average` should be split up into explicit bindings for the mapping to Int, the sum, and the count.

Also, for non-toy examples, there are real benefits to composing transformations, so that you don't pay the memory and performance costs of assigning intermediate sequences.

You're not alone; those long chains are annoying to decipher. The other benefit of what you wrote is that if you have to track down a bug in the chain, you can actually examine the intermediate variables directly instead of having to pick apart a long chain so that a variable is exposed for you to look at in the debugger.

I agree. Naming parts of your code is important. An alternative to named local vals is to either use named functions instead of lambdas: people.filter(olderThan50) or (I use Kotlin) use named extension functions: people.countOlderThan50()

In any nontrivial application, doing this for many of your types, does this not bloat your API considerably, which adds to the cognitive load?

Yeah I much prefer that style because it reads left to right like I naturally read as an English speaker. It flows more naturally from the original object and the changes applied to it.

Agreed. Some functional languages (like F#) have a pipelining operator |> that gives the same syntactic impression:

    list |> map (1+) |> filter odd |> sum

I have found myself using pipes many times in Elm, because they make the code so much more readable. Now I understand why!

I haven't seen an autocomplete that works on pipes. But with a good type system, it is technically possible to list all compatible functions that take "noun" as first parameter.

Sometimes you supply partially applied functions (also with pipes in noun->verb order) and that's not so easy to match:

noun |> verb1 |> (otherNoun >> verb2) |> etc

But perhaps even functions that take "noun" as nth parameter could be suggested.

And other languages, such as Forth; don't need one.

    list map filter odd sum

Huh. I would've expected it to be `odd filter`, not `filter odd`.

Interestingly enough, the now standard data manipulation package in R, dplyr, uses pipelines.

Good to learn me some F#, looks like Elixir.

If verbs from the object flowing you want, "That style to me is preferable" you should say. (Style is the object, preferring it is the verb)

English reads left to right overall, but writing instructions in English does not flow smoothly either way. e.g. "shuffle a deck of playing cards then deal four" reads more naturally than either "a deck of playing cards shuffle then four cards deal" or "deal four cards after shuffling a deck of playing cards".

shuffle(cards).deal(4) is a mix of both approaches.

Yes yes, english doesn't follow this noun-verb order but that's not what I'm actually talking about.

Usually the languages either encourage cards.shuffle().deal(4) or deal(shuffle(cards),4).

In the 'noun-verb'/OOP version the sequence of modifications follows the english reading order where basically I only have to keep information about the last result in my head. The functional verb-noun version I have to pop in and out of layers: 'ok we're dealing what?, something shuffled, what are we shuffling?, the cards object/variable, ok we're dealing shuffled cards how many are we dealing? 4.'

In general the noun-verb follows the sequence of operations applied by the computer so it's easier to read.

That's where I was going as well, LISP style and APL style claims "reads left to right" but having to build up a stack of buffered work which you can only unwind once you get to the end, is annoying and unhelpful and limiting.

But simply turning it around to cards.shuffle().deal(4) isn't a good answer, it's still the case that you can only put a small number of things together in a chain because it stops making sense. If the next move was to start the game, "cards.shuffle().deal(4).startgame('some-card-game')" does not make sense because starting the game is not something the cards do, but "start(deal(shuffle(cards), 4), 'some-card-game')" can make sense because start is a function which takes a board state and a game to start. It describes the world state, not the cards and their abilities.

That is, neither style is right, but a mixed style where both approaches are available and you can mix and match to be more expressive, works much better, IMO. Chunking a small number of things with prefix into one operation, or with postfix into one operation, but combining those chunks flexibly at a larger scale.

the main point was about auto-completion and usability and discoverability. fluent api for the win.

English is worse as it is SVO. So a more English like language would be all infix operators. I thunk part of ambiguity is that English can be used in both modes.

“Say that” “He said”

I was really just talking about the left to right order of modification not the actual order of English sentences. Apparently I was very unclear because that's all the responses I'm getting.

Yeah, Lisp-y parenthesis syntax isn't the best for that, but Ruby and CoffeeScript express it reasonably well: `sum mapToInt filter list`

Which is basically just a sequence of verb-nouns.

> Auto-complete also really helps with discoverability. Consider checking for the presence of a key in a map/dictionary. In Java, auto-complete will quickly lead you to `map.containskey(key)`. In Python, though, you'd have to know that the syntax is `if value in dict`.

This isn't an argument for noun-verb over verb-noun, though it's an argument for more homogeneous syntax. `if value in dict` isn't noun-verb OR verb-noun.

There's not really a reason that f(<tab> couldn't complete with arguments (and it does in many systems). I think if you wanted to use autocomplete to make a point, you'd have to argue that it's more effective somehow to complete on verbs than on nouns.

I also think that the object-oriented syntax matches my thinking process more closely: for example, I have an array of strings, and I want to convert them to numbers, pick only the odd ones then sum them rather than "I want to sum some things…things which I'm filtering by parity…which are actually strings I'm converting to integers".

That's how the thread-last/first macros help in Clojure. You sort of specify a pipeline:

``` (-> list parseInt isOdd sum) ```

Is the same as

``` (sum(isOdd(parseInt(list))) ```

Particularly useful if you're pulling a deeply nested key out.

I think that can be solved without bringing objects into the mix -- functions are usually grouped up into modules of some kind, so leading with `Foo.` (or `foo::` in C++, etc.) still provides a useful level of scoping that can aid autocomplete.

On the other hand, tools like Hoogle [0] let you search for functions based on type, so you can search for e.g. `ByteString -> _` to find functions that take a bytestring. There's no reason the same paradigm can't be applied in an IDE.

+1 for “ball of cats”. That’s a new one for me.

It's real great to know that I can get and set all the fields. Thanks previous programmer.

This is one of those paradigms that I don't understand in Java. It's the most trivial of trivial encapsulations.

It is (was?) the primary way to maintain binary compatibility between versions of class files, where switching an attribute to a method (if logic such as verification needed to be added in a future version) would break that compatibility.

Setters I get (see what I did there?). It's the superfluous getters that simply return the values I'll never understand.

See my cousin comment - it maintains compatibility when changes are internal to the class. For example, if a field was switched from concrete to derived, you'd have to switch the attribute to a getter, which would break compatibility with the previous version.

But exactly because it's easier to "stumble upon" the right answer, I think this may be worse for games. I like feeling as if it's necessary to come up with the solution in my head and then do it. It's not satisfying if every puzzle can be quickly solved by selecting each item in the room and trying the couple actions the game offers you for that item.

The Python approach also exposes unnecessary details and by doing so causes a performance hit by forcing you to get a list of keys/values and then find out of what you’re looking for is in them. This is slower than what the dictionary could do internally: hash the key and check if there’s an entry for it in the backing store.

The .values() method does not return a list, it returns a view object. If you write ‘value in m.values()’, it invokes the __contains__() method.

(Note that this cant be a hash check because it’s not testing the presence of a key.)

(Also note that the story is different if you look at sufficiently archaic versions of Python.)

This is one of the reasons I like ruby better than python... none of the magic 'dunder' methods... if you want to define a custom adder for your class, so "foo + bar" works, you do "def +()" in ruby instead of "def __add__ ()" in Python.... I love that ruby just uses the actual operator instead of some arbitrary method name you have to remember.

> none of the magic 'dunder' methods

Ruby do have equivalents to Python magic methods... disguised as normal methods. For example Python `__hash__` is Ruby `hash` and both are used by built-in dict/hash values and you should be aware of that fact in both. There are some philosophical differences as well, Python likes to have standalone functions that are customized via magic methods (e.g. `str` vs. `__str__`, you don't normally call the latter) and in Ruby everything is method (e.g. `to_s`). It really seems like a matter of taste.

Fair enough!