Yes, the final example code reads reasonably nicely, but alas -- unless ConcurrentHashMap.merge() has been rewritten since Java 8 time -- it is definitely not as performant as the author appears to think it is since the actions will be contained in a fairly long synchronized block. This is not to say the code is bad, but you can't get around that.

Somewhat surprisingly, the code the author pooh-poohs is actually more performant (although it's better if the test is for the presence of the key rather than the "putIfPresent/computeIfAbsent combination) because the JVM will properly optimize a membership test (in keyset) and the use of a ternary expression makes the action clear.

yes, Java 8 adds a bunch of methods to ArrayList and HashMap that makes the code a little more high level.

There is also another variation, using map.getOrDefault()

  words.forEach(word -> {
      map.put(word, map.getOrDefault(word, 0) + 1);
  });

and then at some points you discover the Stream API

  var map = words.stream().collect(Collectors.groupingBy(w -> w, Collectors.counting()));

Anyone else disappointed by the Java implementation of these ideas? It feels less ergonomic than previous solutions and came considerably later. That said, it is better than nothing.

The streams api is a little verbose but this is mainly because of Java’s backwards compatibility policy. They want older code to still compile and run on new JDKs.

Default methods on interfaces help to add features to existing collections but they are limited in what they can do, hence streams.

If you really want more ergonomic collections while staying close to Java then use Kotlin which can be easily added to most Java code bases and has all the modern functional methods like map/reduce/filter/group on standard collections.

It's also to separate the methods doing computation lazily (Stream) from the one doing computation eagerly (Collection). Otherwise a simple call like isEmpty() can trigger the whole computation like in Haskell.

As a user of the API, you have to wrap your code into a Stream to be lazy evaluated, the Stream being a computation monad, so you always know if a code is evaluated eagerly or lazily.

> modern functional methods like map/reduce/filter/group

"Modern". Lol.

I know these functional concepts are far from new.

I use "modern" in this context because other contemporary languages like Python/Ruby/Scala/Rust etc all have versions of those and FP-style collection usage using these names has become popular in the last 10 years.

Java is changing: https://www.youtube.com/watch?v=gIrKP76iuPs "Venkat Subramaniam — Design Patterns in the Light of Lambda Expressions"

And you can use Scala or Clojure with Java APIs/Libraries/Frameworks

https://www.scala-lang.org/ https://typelevel.org/cats/ http://dotty.epfl.ch/

https://clojure.org/ https://clojure.org/guides/spec https://github.com/clojure/spec-alpha2/wiki/Schema-and-selec...

in python:

    >>> from collections import defaultdict
    >>> map = defaultdict(int)
    >>> for word in ['hi', 'there', 'hi']:
    ...   map[word] += 1

I am glad Java has this stuff now, but it's a little surprising that its tools are still so obtuse relative to competitors.

edit: I should have foreseen the derailment caused by and nitpicking to follow a comment like this. Sorry folks!

Yes... now turn that map into a lock free thread-safe dict in Python and show us the same code. I get that for free in Java via ConcurrentHashMap.

If you mean lock-free as in no GIL, you obviously can't. But otherwise all python code is inherently thread safe.

Yea I meant lock free and ready for multi-threaded use without a GIL. I didn't mean to dump on Python either, I write a lot of Python and Java but comparisons like yours aren't really fair because the JVM is just considerably more powerful than Python's runtime. I could take a huge list of words, hand subsets to threads and let them all update the same map using the same API and without needing a lock.

You'd preferably use collections.Counter for this.

To be fair, getValueOrDefault is strictly more powerful than defaultdict because you can vary the initial value by the key.

dict.get() does the same in Python (optional second parameter for a default value). But I've wondered too why there isn't a form of the default dict that can take parameters like the key for the factory function.

But your python code is still really ugly. In Scala:

import scala.collection.mutable.Map

> val map = Map.empty[String, Int]

> List("hi", "there", "hi").map { x =>

> map(x) = i

> }

Not the same but immutable approach is more idiomatic Scala.

    List("hi", "there", "hi")
      .zipWithIndex
      .map { case (x, i) =>
        x -> i
      }.toMap

That example doesn’t really illustrate the point of updating maps with repeated values.

Funny you say that, because I find the key-sorted TreeMap to be useful in Java, but Python seems to have no equivalent.

Python has OrderedDict.

OrderedDict is ordered by order of insertion, TreeMap is ordered by key value.

Logically equivalent to LinkedHashMap, thought it was the other. I should use Python more often.

This is a poor semantics. The function should always be called. In the non-existent-key case, it should be invoked on the default value that is supplied. Thus the example of the histogram tabulation would use 0 as the initial value.

The name is ill-chosen; this mutator doesn't "merge" at all; it "updates" the map entry through a function, with a default value.

"merge" might be a somewhat good name for an operation that combines two maps, with a function that resolves key clashes; though since that is a kind of set union, that provides better terminology.

I like how the more mathematical concepts get their way to the mainstream languages. It's making concepts such as monoids and semigroups more accessible to general public.

The one thing that frustrates me about merge is that it returns the value inserted, rather than the value being replaced (as Map::put does).

There are good uses cases for what it does - but there are also good use cases for returning the previous value, and when i have one of those, i can't use merge, and have to fall back to a get followed by a put.

Perhaps what i would really like is a Rust-style entry API, where i could use a key to obtain a Map.Entry, which i could then inspect and mutate how i liked. It might look like:

  Entry<K, V> getOrCreateEntry(K key, Function<? super K,  ? extends V> mappingFunction)

And then i could write:

  void sell(Potato) throws FarmException { ...}

  Map<Field, Potato> potatoesByField = new HashMap<>();
  for (var potato: getAllPotatoes()) {
    var fieldAndPotato = potatoesByField.getOrCreateEntry(potato.getField(), f -> potato);
    var oldPotato = fieldAndPotato.getValue();
    if (potato.getWeight() > oldPotato.getWeight()) {
      potatoAndField.setValue(potato);
      sell(oldPotato);
    } else {
      sell(potato);
    }
  }

To collect my prize potatoes into a map, and sell the rest. Still ugly, but hey, at least it's not Go.

Your API works less well in concurrent map scenarios, though.

Nice, so basically it's `INSERT ... ON DUPLICATE KEY UPDATE` ?

It's also MERGE in the SQL standard: https://en.m.wikipedia.org/wiki/Merge_(SQL)

Monads do exist in the programming for a reason.

This is a toxic attitude as this can be said about pretty much any language / thing, "lol Ruby developers discovering what LISP developers have been doing since the 80s", "lol LISP developers discovering lambda calculus", etc.

A better attitude would be to appreciate that these solid practices are being rediscovered everywhere, and focus on the good rather than the "us versus them". It's not productive.

You could say the same thing about JavaScript, Python and PHP discovering typing.

The best languages borrow from each other.