211–220 of 314 posts
You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…
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.
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…
Earlier quoted context omitted.
Have a look at SWT. It's the best way to do Java UIs IMO. I don't know why it isn't more popular. It uses the native UI kits internally, so it feels and is 100% native.
There is more to a native ui (common spacing, font usage, interface patterns) than just swapping out the underlying widgets.
Earlier quoted context omitted.
A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…
The JVM has a couple of pretty significant problems when trying to work with functional-style languages. The biggest one is the way it deals with the stack: It's not in the heap, and it's pretty limited, so with something like scala, and more specifically with scalaz, you have to do some contortions to avoid overflows. 90% of usages of scalaz trampolines are nothing but ways to work around JVM limitations. I'd argue…
See my blog post: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...
I'm excited to see tail-call optimisation ("proper tail calls") coming to JavaScript. Hopefully a bit of competition will encourage the JVM to clean up its act too.
http://bbenvie.com/articles/2013-01-06/JavaScript-ES6-Has-Ta...
(* Heap-allocated frames can help with other things though, e.g continuations.)
Earlier quoted context omitted.
> There are plugins for Emacs (nrepl) I think nrepl for emacs has been replaced by cider (which still uses nREPL)
AFAIK Cider is like SLIME, big and integrated. Emacs nrepl is just the repl connection, and is usually enough (at least, has been enough for me).
"CIDER (formerly nrepl.el) is the Clojure IDE and REPL for Emacs, built on top of nREPL, the Clojure networked REPL server."
That and the availability of the packages on melpa:
cider 20140318.... available Clojure Integrated Development Environment and REPL
Earlier quoted context omitted.
A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving…
Agreed, in fact what's surprising is that anyone thinks it's surprising that the JVM with its billions of man hours and primary usage in mission critical finance/banking/etc is anything but one of the most performant, scalable, robust, well-tooled platforms around. >Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use) Though I'd probably still rese…
I would absolutely not. Erlang/OTP/BEAM might be the best distributed computing platform (though Akka is making huge inroads), but Erlang is actually a pretty terrible at single-box concurrency.
Erlang has one concurrency primitive - message passing. Which is great, but it's not always the right one.
Consider a a producer process which solves a PDE or does a big Bayesian computation (output is an Array[Float] or Array[Double]). You have consumer processes which read from the array and compute sums over subsets of the elements.
In Erlang you are just passing around copies of arrays. In the JVM, you'll probably have a single mutable array. You'll either wrap the appropriate calls in arr.synchronize {...}. Or you can use memory barriers and let the consumers freely read from the array, and invalidate their computation if the producer wrote to the array between the start and end of their read.