| Hopefully off topic but interesting is OK on HN: I've developed a strong "allergy" for "traditional" OO; perhaps/probably unfairly, since it's based on a lot of C++ work I did in the '90s, and it's as anti-dynamic (not just in typing :-) as you can get in the OO world (insert Alan Kay's comment here (I think it was about C++)) ... but it's also based on my recoiling in distaste from seriously learning Java for some Clojure related stuff, too much accidental complexity. My tastes in languages run a lot more to the Scheme end of things (T may remain my favorite Lisp dialect and language of all time) so my current language interests are more like: Play with Haskell since there's so much ferment there. Learn a pre-OCaml ML so that I can grok all the ML based FP literature from the period before Haskell's ascent. Help liberate Clojure from Java: as part of the Clojure in Clojure effort, work on what I call Turtle Clojure ("It's turtles all the way down"). While a Lisp traditionalist, I'm willing to "Get rid of cons!" (http://news.ycombinator.com/item?id=814632) but I'd like to see what can be done without Java in the middle. I can't imagine that Java tuned GC is optional for something so seriously functional as Clojure, so that's what I'm looking at the most. Maybe an Appel-Ellis-Li GC can be efficient under Xen (it uses VM for read barriers, but traditional OSes don't optimize that path (10,000 cycles circa 1990)). The thing I find most interesting and challenging in the area of programming is the single address space multi-core SMP problem, which Clojure is very most focused on and is obviously very relevant at a time when I can buy a x86-64 4 core 8 MB shared L3 cache server class chip from Intel for as little as $200. I have done the mixin thing with Flavors (proto-CLOS) and C++, and, yeah, the pure Java people don't know what they're missing. |