"Not everyone [...] has a choice over what language gets used." If people can't make ideal technical choices for political reasons, then that is a political problem rather than a technical one.
I can't fault programmers who try to "sneak" useful or stimulating technologies around the stifling confines of their employment situation. However, accommodating this type of "sneaking" shouldn't be a first class design consideration for the Java platform. "What I really cannot tolerate is a badly written version of it in the core Java libraries, that will stay there untouched forever only for backward compatibility reasons. Does java.util.Date remember you something?" I completely agree with this. "If the feature is good and useful in Java code, there's no reason not to use it in Java code." Generally good features should be added to Java. The two major caveats are: - Divisive issues: Some love it, some hate it. Option and flatMap are extremely divisive. - Legacy Impact: Some features are easy to ignore if you don't like or care about. Option is particularly invasive across a code base. I prefer Option, even in Java, but I can understand some of the resistance to it. Persistent immutable collections should be an ideal addition because they are extremely valuable, they are not divisive (no one seriously objects to them), and they don't have any real legacy problems. There are a bunch of third party implementations, but there is a big opportunity for something much better. If I had the time, this would be a fun side project. "Option is not a Scala thing, [it] is a micro-design pattern" Today, JVM programmers are highly divided. It's not a perfect summary, but I would broadly categorize into two groups: those that want all the Scala features and those that want to stick with a simpler Java-like language. Option is a good marker at signaling which camp a programmer falls into, but obviously Scala didn't invent or "own" the Option pattern. I retract what I said about Some/None sublasses. In Scala that works with the match construct, but since Java doesn't have such a construct, it isn't important, and the Java implementation should focus on whichever is most efficient in terms of memory overhead and runtime speed. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/PopEZeQSxDkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
