pg had an interesting take on "hackers radar" wrt Java. worth a read. http://www.paulgraham.com/javacover.html
It's silly to compare Java8 with Java1.4? 1.3? from 2001.
261–270 of 314 posts
pg had an interesting take on "hackers radar" wrt Java. worth a read. http://www.paulgraham.com/javacover.html
It's silly to compare Java8 with Java1.4? 1.3? from 2001.
I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see: - Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a depende…
Multiple return types: Questionable benefit there. Exceptions are nice when used properly. Option classes handle the rest. Categories: Default methods probably do what you want. Get rid of primitives: Are you nuts? It turns out computers work on primitives. It's good to support them. "Proper" generics: maybe you mean specialization, or maybe you mean reification. It's a choice. Properties: If they irritate you that m…
Earlier quoted context omitted.
Apparently Android is not using Java, but something that looks like Java. I bet Google vs. Oracle trial can be attributed to that. :)
Actually they use Java the language, except that the code doesn't run on JVM but on a different VM (Dalvik at this time). Dalvik supports Java 6 and parts from Java 7.
Earlier quoted context omitted.
Isn't map/flatMap and orElse enough, if only for Optional?
It's not enough for compactly expressing imperative logic. In Scala: resultOption match { case Some(x) => println(x) case None => println("error") } Without pattern match: if (resultOption.isDefined) { println(resultOption.get) } else { println("Error") } The .get is the problem.
import java.util.Optional;
public class Scratch {
public static void main(String... args) {
Optional foo = Optional.of("foo");
Optional bar = Optional.empty();
System.out.println(foo.orElse("Error"));
System.out.println(bar.orElse("Error"));
foo.map(Print::print).orElseGet(() -> Print.print("Error"));
bar.map(Print::print).orElseGet(() -> Print.print("Error"));
foo.ifPresent(Print::print);
}
static class Print {
public static T print(T val) {
System.out.println(val);
return val;
}
}
}Earlier quoted context omitted.
It's not the approach, but the capabilities: 1. State-of-the-art garbage collectors, which enable good implementations of lock-free data structures. 2. Excellent implementations of lock-free data structures (like ConcurrentLinkedQueue and ConcurrentSkipListMap) and other concurrent data structures (like ConcurrentHashMap). 3. A state-of-the-art work-stealing scheduler (ForkJoinPool), excellent for both parallelism (a…
Thanks - I use Java all the time - but sometimes I find knowing which data structures to turn to in a given situation tough.
Earlier quoted context omitted.
I think that's a pretty extreme position. First, it will run a lot slower than the pattern matching alternative: optional match { case Some(x) => whatever(x) case None => fallback } Second, I find the pattern matching code much clearer. Sure, it's also longer, but clarity trumps everything.
map / getOrElse is standard in all the Scala code I've seen. Abstracting over the monad is also a pretty big win that has made some big refactorings painless for me. Pattern matching is really only used by beginners IME.
Earlier quoted context omitted.
That's the story that gets told, but how often have they actually removed something after deprecating it? Does anybody have a single concrete example of a method that actually went away? http://stackoverflow.com/questions/18063599/has-ever-anythin...
I don't believe they have ever removed a Class or method from the JDK... Thread still has all of those super-unsafe or non-implemented methods in it (see: stop(), destroy() etc.) I think part of the reason for this ultra-conservative approach might be that alternate JVM implementations could in theory have well-implemented versions of deprecated methods such as the above-mentioned Thread ones.
Earlier quoted context omitted.
map / getOrElse is standard in all the Scala code I've seen. Abstracting over the monad is also a pretty big win that has made some big refactorings painless for me. Pattern matching is really only used by beginners IME.
Well, then maybe the beginners do it right? You have not argued against my two points: It's much slower, and less clear.
The speed benefit is well known, as is the corollary, premature optimisation. I expect checking for null is even faster if speed is the main concern. It's an engineering tradeoff, just like making the abstraction to a monad (or monad plus). In the normal course of events I'm more concerned about flexibility than performance and would prefer the abstraction.
Earlier quoted context omitted.
What is best practice when it comes to Java GUIs? Would you recommend Java for building cross-platform desktop apps with near native UI performance? The IntelliJ IDE looks great but most Java desktop apps I've come across just look and feel weird. Not sure why there is such a big difference.
You have probably encountered the occasional Java desktop app, without realising. If you can't easily tell it is Java, the development team have done a good job. Two of my company's three products are a Java desktop app for Mac, and they look and feel like typical Mac apps. Best practice? IMO you should spend significant time on the GUI making sure it feels native. Otherwise, Swing is still about as good as it gets f…
I've never seen any Java desktop app that I cannot easily tell it's Java. With most of those apps, even on i7/16GB/SSD systems, you get laggy behavior with Swing and the GC. And SWT still has the "uncanny valley" look going.
Earlier quoted context omitted.
JS ecosystems in terms of quality, tooling, and engineering is already bad, can't be worse than that really... PS: No, yet-another-js-library-to-replace-jquery is not considered tooling. No, yet-another-replacement-for-grunt/bower/yeoman is not a good sign of the ecosystems. Java has Maven since 2004.
Maven is horible. Hth