4 ms·
Lisps are awesome! But to be fair, the Java code can be a lot more compact by using Guava: import com.google.common.base.Functions; import com.google.c
by julian37 14y ago
Lisps are awesome! But to be fair, the Java code can be a lot more compact by using Guava:
import com.google.common.base.Functions;
import com.google.common.base.Joiner;
import com.google.common.collect.FluentIterable;
import com.google.common.collect.Ordering;
import com.google.common.collect.Sets;
import java.util.Map;
import java.util.Collection;
public class MapUtils {
public static String sortedKeyList(Map<?, ?> map1, Map<?, ?> map2) {
Collection<String> sortedKeys = FluentIterable
.from(Sets.union(map1.keySet(), map2.keySet()))
.transform(Functions.toStringFunction())
.toSortedSet(Ordering.natural());
return sortedKeys.isEmpty()
? "<none>"
: Joiner.on(", ").join(sortedKeys);
}
}
Not nearly as pretty as the Clojure code, but a lot nicer than without Guava.
- deleted 14y ago[deleted]
- doktrin 14y agoThis is a good point. I personally find the "code compactness" to be a bit of a red herring. Java's greatest weakness, after all, is not the verbosity per se. If all of its other failings were addressed I would probably scarcely care about the amount of code it takes to perform a given task. Likewise, compactness is not what lies behind the current FP trend. Compactness, after all, while related to programming paradigms is more directly tied to the strength and level of abstraction afforded by a given library / API. Ruby's standard library, for instance, allows for some pretty insane one liners. This is to say nothing of the development time overhead involved in switching paradigms (non-trivial, IMHO). This alone offsets "compactness", both from the standpoint of up front dev time as well as readability / correctness, for (IMO) up to half a year. As an aside, that code could be made yet more compact if written in Groovy (Groovy-as-a-Java-superset and not functional Groovy, necessarily).
- zmmmmm 14y ago> that code could be made yet more compact if written in Groovy Indeed. It's very hard to read this and not think ... "but this would just be" in Groovy: [m1,m2]*.keySet().sum().sort().join(",")?:"<none>" So small that I would rarely even make a separate function for it. I imagine it's much the same in many dynamic languages.
- martinced 14y agoI think that what's important is not that this particular example has a short Guava equivalent but that, overall, Clojure code seems to be way shorter than equivalent Java code (even if you use Typed Clojure). A lot of people are talking about a 10x code size reduction, which is amazing. Also, it's not as if the Clojure code was some obfuscated brainf*ck-style unreadable one-liners. It's very easy to read for anyone remotely familiar with Clojure.
- amalag 14y agoI like this better than the Clojure code.
- deleted 14y ago[deleted]
- fooooobar 14y agopackage com.howardlewisship; import java.util.*; public class MapUtils { public static String sortedKeyList(Map<?, ?> map1, Map<?, ?> map2) { Set<Object> allKeys = new HashSet<Object>(map1.keySet()); allKeys.addAll(map2.keySet()); return allKeys.isEmpty() ? "<none>" : org.apache.commons.lang.StringUtils.join(new TreeSet<String>(allKeys), ",").toString(); } }