As mentioned in their 2013 PyCon talk, the problem with HTM (at least with current designs) is the hard limits to transaction sizes. They are attempting run run entire interpreted code loops in transactions, while HTM is designed more around smaller transactions.

Specifically I think Haswell requires that all mutated references must fit in the L1 cache. That doesn't really leave much wiggle room

It also allows for multiple copies of the same application to run on the same VM. That is a nice dev feature.

If you're interested in lisp without the JVM, there's always ClojureScript. Once the JVM compiler is up an running it compiles most of my ClojureScript code in about 1 sec, and there's utilities that auto re-compile code as files change.

"without the JVM" ... "Once the JVM compiler is up"

Does not compute! :P

Can't quite tell if you're serious or joking. In case it's the former: the ClojureScript compiler is implemented in Clojure, which runs on the JVM. The compiled code is Javascript, which doesn't require the JVM. There have been some discussions about making the compiler hostable from Javascript as well, but it's not possible just yet.

> but the JVM kept me at bay

> ClojureScript compiler is implemented in Clojure, which runs on the JVM

Author of Mjolnir here. There's some major updates going on in the "datomic" branch. If you're thinking of using Mjolnir in a project, you'll want to keep an eye on that branch over the next few months.

With Datomic, the inference engine is completely re-written in datalog. This allows for a massive code clean-up, and the code in that branch is much cleaner.

sadly, this doesn't seem to support any sort of multithreading. Even something as simple as swap! isn't thread-safe in this implementation. So that kills one of the main reasons to use Clojure in the first place.

Lack of multithreading seems like a result of the implementation being heavily based on ClojureScript ;) (it's actually pretty cool to see how reusable core.cljs is IMO). I imagine ClojureC will have its uses like ClojureScript does when the JVM is not an option.

> sadly, this doesn't seem to support any sort of multithreading

Maybe multithreading is just not yet implemented?

> So that kills one of the main reasons to use Clojure in the first place.

I could see ClojureC being very useful for when you want:

  * small footprint
  * easy C-library interop
  * fast start-up time

and where you don't necessarily need multithreading.

(BTW, I'd be curious to hear what you think might be the differences in use cases between ClojureC and mjolnir/clojure-metal.)

It is quite interesting though as soon as you extend it with calls to C libraries. Like if you want to use Clojure for libavcodec, or many others.

I would go a step farther and say that OpenDoc should be in a separate interface from SaveDoc.

That's what I meant - should have said interface_s_, I see now :)

Actually, opening a document is probably not even a good abstraction. DocProvider is better: You can have FileSystemDocProvider and BlankDocProvider - the latter can't meaningfully be said to "open" a document, but it's interacted with in the same way.

Use it every day and you'll probably think different about it.

(baz 33 (bar 12 (foo 33 (+ 1 42))))

Is way harder to read than:

   (->> (+ 1 42)
        (foo 33)
        (bar 12)
        (baz 33))

I totally agree and personally love using -> and ->> but I've heard people say that the idiomatic way is to use let instead:

    (let [fortythree (+ 1 42)
          foo33      (foo 33 fortythree)
          bar12      (bar 12 foo33)
          baz33      (baz 33 bar12)]
       baz33)

I understand the logic behind preferring let and a lot of times it really does make things clearer to have everything named and explicit, but especially in prototype code, I find the need to name things to get in the way. I would prefer not naming things over badly named things, for example, and that's usually how I decide between let and thrush (all things being otherwise equal).

agreed, it has to the the worst looking site I've seen in awhile.

+1 Since I stopped writing C# code in Visual Studio, I software development doesn't make me nearly as angry as I used to be. Now I write Clojure code on OS X, and couldn't be happier.

This is why I use Clojure. I can do Functional, OOP, logic, or any of the dozens of other programming styles in one language. And since it's a lisp I don't have to worry about having to need extra syntax from the language writers to get what I want.

Pragmatic languages FTW!

I interpreted the OP suggesting that you not use a single multiparadigm language because then you won't be forced to follow the new principle everywhere. Of course, it's possible to do (for example) OOP in a lisp-like language, but you'll really be forced to work with it in a language like Java, which may give you a deeper understanding.

Well, avoid Java, which is just C++--, and think Smalltalk instead.

Therefore Java == C?

I don’t think programming languages have inverses, so in general λ + 1 − 1 ≠ λ.

Well, only shittier.

Your comment gives the impression that Clojure is a big multiparadigm mess. But it is not. Clojure's design is clean and simple. Clojure is mostly functional. Sure, since it's a Lisp one can kind of incorporate other paradigms with macros. But out of the box Clojure does not do Java-style OOP (except for interop) or Prolog-style logic.

Perhaps it does place oriented OOP poorly, but it actually has an extremely nice logic engine (see core.logic).

Yeah, I know about it, but it's an additional dependency, right? [org.clojure/core.logic "0.7.5"] Whatever, Clojure is clean and simple is what I wanted to say. :)