prospero

My point is that the creator/user dichotomy exists at every level of software.

Show me a software developer who isn’t an end user for someone else’s code.

Here’s one in Java: https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna...

Yes, and that is used as an example for the general point: a network transparent API doesn’t help us understand the network when it inevitably fails.

The point is that an interface should help you to both ignore and understand the underlying implementation. I'm not sure I understand your point about data and transport, since most interfaces (e.g. names) don't touch the network. Are these just synonyms for interface and implementation?

It's very plausible that these techniques could be used to fix the output of a CSG library that uses floating point math, but I'm not sure what the specifics would look like. If anyone has ideas in that vein, I'd be very interested to hear them.

Hi, author here. I looked into that side of things, but CGAL only offers exact precision implementations for lines and circular arcs. The fact that Bézier curves are left as an exercise for the reader is further proof of the disconnect between computational geometry and modern computer graphics.

By forcing the GC to run in between tests, basically. The README for the benchmarking tool describes it in more detail: https://github.com/hugoduncan/criterium.

I tried to include these, but it wasn’t immediately obvious how to construct them from outside Scala without CanBuildFrom. If anyone wants to open a PR or even provide a few hints, I’d be happy to update the benchmarks.

Guava’s “immutable” collections are effectively read-only indices, and do not support efficient updates.

Clojure’s maps, sets, and vectors are all functions.

I’d think a relaxed radix tree would be ideal.

In the first ten minutes of the talk, the SICP definition (which is taken from the Hoare paper) is examined and discarded as too limited.

I'm glad you've found them useful.

You probably saw my response in that thread, where I said that the dramatic performance improvements in lookup speed reported by the CHAMP paper were mostly because they were comparing apples to oranges.

However, Clojure's equality semantics only really help in some niche situations (where you want to be able to use ints, floats, and bignums interchangeably, mostly), so making the equality semantics configurable would be a huge win for all sorts of applications.

Also, lookup is not the only performance win that CHAMP offers: https://github.com/lacuna/bifurcan/blob/master/doc/benchmark.... One thing the approach makes possible, which wasn't explored in the paper, is the ability to do union/difference/intersection operations structurally, rather than just iterating over each element in the set.

None of these improvements are so overwhelming that they take priority over everything else. Clojure's data structures are still really well made. Given how data-focused the language is, however, I think these improvements are more compelling than everything that's been added to the language in the last five years other than `clojure.spec`.

The chance of my implementation being folded into Clojure, as opposed to whatever Rich writes himself, is definitely tiny. But there's no telling when he might get around to it, so the best way to stay sane is to assume it will never happen.

Clojure occupies a really nice local maximum, and I don't think any other language is trying to compete for that niche. Since Clojure is just a Java library, it's relatively easy for you to extend or replace any part of it, so I don't think the future is a concern for anyone who enjoys the language and is motivated to use it.

Rather, I worry about the growth of the community, since that's largely predicated on the out-of-the-box experience. As an author and consultant who is focused on Clojure, that affects me far more than a company which builds its product using Clojure (assuming you're willing to hire people with an interest in FP and teach them the rest in their first month). I don't claim expertise in how to grow a community around a language, but it seems to be at best a part-time job for the people at Cognitect, which is not ideal.

Clojure is the language I'm most productive in. At the beginning of the year I quit my job to write a book about Clojure [1], do some consulting, and build a developer tool I've been talking about for a few years.

For the tool, I'm using a client/server model, and on the client side latency is a huge concern, so I'm using Java. Java is basically assembler for the JVM, and has extremely predictable performance characteristics. Where performance is a non-issue, or I only care about throughput, I'm using Clojure, because it's much more expressive. I think the tradeoffs of the two languages are very complementary, but also much less extreme than, say, Ruby and C.

I find the inertia of the core implementation of the language annoying, even if it's not a huge problem for most applications. Clojure's immutable data structures were world-class when the language was first released ten years ago, but there have been a number of papers which detail improved approaches since then. I've implemented most or all of them [2], but the chance of getting these back into Clojure is effectively nil. That doesn't affect me (I can just use my own data structures), but it does give me some concern as to where the language will be after another ten years.

[1] http://elementsofclojure.com/

[2] https://github.com/lacuna/bifurcan

No idea why this is here, but I'm the speaker and happy to answer any questions.

The lookup performance gain is largely due to the CHAMP implementation using the default Java equality semantics, while Clojure's maps use Clojure's more expensive equality semantics. See https://github.com/lacuna/bifurcan/blob/master/doc/benchmark... for a more in depth illustration of this.

However, it is still a meaningful incremental improvement over Clojure's implementation for iteration and equality checks, among others.

Here's another one: https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna...

Calling other races well-suited to slavery isn't political, it's hate speech.

Thanks!

What did you use to create your animated simulations?

It's not that hard to imagine: map a `get` over a series of keys inside a transaction, return that lazy sequence, and use the results to do another series of operations within a different transaction.

Libraries typically can't guarantee eager evaluation, since that's a property of the top-level execution. That's why libraries shouldn't use `binding`.

There's plenty of reason: you can put any code you like inside of `with-read-txn`, including closures that are evaluated lazily. If you dislike the duplication, create a syntactic form that allows less, like this:

    (transaction-> db-name
      (put! ...)
      ...)

This doesn't lend itself to every kind of action, but it is narrower. Alternately, create a variadic version of `put!` which guarantees eager evaluation inside of a transaction.

The nightmare scenario here is not that the sequence will lazily evaluate outside of `with-read-txn`, because that at least will throw an error. Rather, it's that it will be evaluated inside a different transaction, without anyone ever realizing it. By leaving that possibility open, you're doing a huge disservice to the users of your library.

The problem with that is that if `put!` or some other function is used inside `map` or some other lazy context, it may get realized outside the context of `with-read-txn`. Making `binding` part of your public API breaks referential transparency.

If that's a "proper" replacement, then I think you want a queue, not an agent.

Agents are effectively atoms jammed next to an unbounded queue or unbounded thread pool, depending on whether you use `send` or `send-off`. In cases where you have enough contention to actually need formal serialization, you don't want either of those.

If you have low contention, use an atom. If you have high contention, use atoms and/or pieces of java.util.concurrent.

Without a hint of irony: thank you for reading this so carefully. Some of the things you note are typos or poorly worded, most are things that I think are clear in context. In either case, yours is one of the very few comments about the actual book, rather than Clojure in general. I appreciate it.

The four chapters shown are the complete list, only the first chapter has been completed. I have tried to make this as clear as possible, let me know if you see a way to make it more so.