ryanbrush

It seems like a stretch to classify Julia as Object Oriented. It has types and record structures, but these aren't strongly coupled to functions like you'd see in most OO-style approaches. It also doesn't encourage hiding data behind a bunch of "accessor" methods on objects.

There also isn't OO-style inheritance and polymorphism. Julia's multi dispatch reminds me most of Clojure's protocols, which is a great feature. It achieves polymorphic behavior of functions without having to do ugly things to the objects. That Julia can make this fast and ubiquitous in the language is pretty awesome.

I'm also new to Julia, but I really like the above design decisions, among others features.

Were any issues logged, or these problems otherwise addressed, in the ten+ months since this was posted?

I wasn't able to find anything with some quick searches but hopefully others on this thread are more familiar with these projects.

Whether through Datomic or something else, it seems like some version of "database-as-a-value" (as described by Rich Hickey) is bound to happen. We're keeping immutable version histories of as much as our hardware and systems will allow, from source code management through other types of media. Why in the world wouldn't we do this with our data if we could?

It'll be interesting to see how this plays out. Widespread adoption of technology tends to follow a path of least resistance. Does Datomic offer a simple enough path to pull many people over? I also know many of us have a preference for building on open source systems; will this be an obstacle for Datomic?

Yes, these are excellent, and goes into much more depth than the brief article I wrote.

Very kind of you to say! I came up with the metaphor when needing to explain this to a semi-technical person as well, so we've had similar needs there.

Using that cache is a good idea. The site linked to was used to gather the original content rather than broad consumption. (I wrote two of the chapters in this book, and this was where we revised them.)

Lots of good articles in there, though.

Sounds great. I'm glad to know something like that's in progress, and many thanks for your efforts on this project!

Understanding that core.async is new and evolving, but is there a reference or an idiomatic way to work with blocking operations, beyond the general advice of separate threads as an exercise for the reader?

EDIT: I bring this up because this seems like a common misstep for users of core.async, and a simple pattern for blocking IO might help people avoid it.

core.async really looks awesome...if we can create simple patterns for working with blocking operations, it would be a compelling model for a lot of use cases.

(Also, hats off to the core.async developers; it seems like the reward for creating something great is just demand for more. ;)

Ah, I didn't realize that core.typed could deal with rich data structures like that. That's actually pretty amazing.

A perhaps naive question: could this sort of thing tap into Clojure's type hints rather than using external annotations? So rather than writing the example in the post:

(ann my-inc [Number -> Number])

(defn my-inc [n] (let [internal-number (Integer/parseInt "1")] (+ n internal-number)))

one could write this:

(defn ^Number my-inc [^Number n] (let [internal-number (Integer/parseInt "1")] (+ n internal-number)))

...and then run a type checker that reads and analyzes the hints?

Of course, the core.typed annotations could preserve whatever information they need in the compiled output, whereas the type hints aren't preserved past the compile phase (as far as I can tell.) Is that the limitation that requires defining type information in separate annotations?

Not to mention the operational costs of a small navy to recover the rocket and transport it to a launch site.