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.
I know that much about Julia, I just meant to say I'm not an expert or authority :). Anyway, "objects are not strongly coupled to functions", as you said, nails it.
I believe the ability to configure this behavior is being tracked at the link below. It seems like it's a switch between consistency and availability. By default Kafka prefers availability, and the possible inconsistency results in data loss (because Kafka just discards some inconsistent data it can't resolve). But the JIRA linked below should make that behavior optional, so if a majority of machines fail the cluster will become unavailable rather than inconsistent.
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?
Take a look at Event Sourcing, commonly used with CQRS. The approach is indeed to store data as change-events in an event-store (which could by a SQL database or NoSQL store, that depends on your needs) and then built one or more views (separate databases, Lucene indexes, files, anything really) to service the type of requests that the application handles.
SQL databases also do this. They have events called 'SQL statements' which are written to a 'journal' and applied to the domain which resides in the 'tables' of the database :)
You seem to not understand the point. SQL databases don't count because these mechanisms are not visible, and the programming model is changing data in place.
No-one really cares how DB's are implemented under the hood, we just care about the programming model. (And speed, CAP, ACID, etc...)
Given the underlying architecture of most relational databases, is it realistically possible to do "point in time queries", without requiring playing back the entire log history into a clean database up to the point in time you want? That's not going to be very efficient.
I've only seen SQL logs presented as solutions to replication and disaster recovery, not point in time functionality.
What I'm getting at, is it even possible in principle to expose part of the inner workings of some relational database systems to get this kind of capability?
Snapshotting and log replay should be fairly straightforward, if you save all sql statements in their entirety. Snapshots would stop the world, which might pose a problem, but I presume this is no different to other event sourcing solutions. Given the concurrency of a db, I'm also not sure that there's a strict ordering of all incoming statements.
There is also http://geteventstore.com/ - an immutable event database by one of the main CQRS aficionados - Greg Young.
BTW, clustered HA setup has been opensourced very recently.
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.)
Nice work Ryan. I've been reading through these, and "Code is Design" is roughly similar to something I was trying to explain to my manager not too long ago, but I couldn't quite put it into words. I just sent him a link haha.
The parallels between software and physical construction are pretty amazing.
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.
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. ;)
It's true that out of the box core.async is MUCH nicer to use with existing asynchronous IO APIs. My limited experience has shown that you'll want to wrap your synchronous IO operations to play well with core.async. This generally means queueing work in an operation-local (or subsystem-local) threadpool and providing an async API for interfacing with via core.async.
The next step is deciding on how to expose the asynchronicity. I chose to accept / return channels rather than callbacks, because... well... wrapping your sync code in a callback-based async API just to glue them together with go blocks and channels seemed backward to me. :)
I think this "next level up" from the foundation of core.async has potential for some really great solutions and I'm dying to see what Tim and others will come up with...
I'm working on that right now, but it won't be out till the end of the year. I'm giving a talk at Clojure/Conj about core.async and hope to cover most of these sort of questions. I'd publish notes about it now, but that'd kind of kill my talk in two months.
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)))
...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?
Clojure's type hints are only about Java interop and performance, and pretending otherwise is not a good idea. They aren't nearly rich enough to do the things that Typed Clojure does - think about less trivial examples like type checking heterogenous maps.
Right now it only checks maps for a set of keys, the idea longer term is to add in other types of "type" checking.
I haven't yet tied into the built-in annotations, just because those didn't appear to check anything but valid Java types. If it is possible, I would be really interested in seeing how.
I believe the "small navy" was a political and technological requirement and not something you'd need today. A single ship ought to do now.
Political, because it was the Space Race, and a lot of it was about shows of force. And hey, why not? You have a bunch of carrier battle groups just waiting around for a hot war, and you need to have them out training anyway, so why not use them to pick up spacecraft from time to time?
Technological, because guidance wasn't necessarily very accurate. It's interesting to look at the miss distances here:
Some of these landed hundreds of miles from their target. However, by the time Apollo came around, they were all very close. You definitely want a big recovery fleet to cover a lot of area when you can't be sure it'll land on target, but that's not so much of an issue these days.
I remember reading about the issue in a book called "This New Ocean"
apparently by the time Apollo was on the go NASA had to ask the military to position the ships off to the side of the splashdown zone - the guidance improved so dramatically they were afraid of hitting the carrier directly
Funny to see this here. That wiki was used to put together the contributions for the book, and the fact it wasn't planned as a high-volume site is pretty obvious right now.
There are a number of items worth reading from some pretty good writers in there (Verity Stob, Michael Feathers, Scott Meyers, Uncle Bob, to name a few.) Mostly short vignettes but I enjoyed them.
(Disclosure: I wrote 2/97 of that book, but there are many chapters in there better than mine).
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.