Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Datomic Best Practices

docs.datomic.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Datomic Best Practices

#21

Post by sooheon »

taeric wrote: post #15
Skinney wrote: post #13

Earlier quoted context omitted.

> Simplicity would be to have a single mechanism for landing the Curiosity. Not 3. With one of them being a crane drop from a hovering rocket!? Why? Simple, in the way Rich Hickey advocates, means the opposite of complex, which means that things are woven together. You can have many landing strategies without them being tightly coupled together. A huge system isn't necessarily complex.

That is the catch, all three landing strategies were coupled together. You couldn't do one without the one before it. More, previous steps had to take into account the baggage (literal) that was necessary to perform later steps.

If that's the best they could do and what got the job done, good. It's as simple as was possible and necessary. What exactly does this prove against simplicity, again?

Re: Datomic Best Practices

#22

Post by jtmarmon »

mattjaynes wrote: post #2

I have a client that is exploring Datomic, so I wonder if some of you can chime in on why this is popular at the moment and what your experiences are with it? I'm a big Rich Hickey fan. If you don't know who he is, he's the guy behind Clojure and Datomic. I don't use those tools, but his views on simplicity are wonderful. Here's a great quote of his on the subject: "Simplicity is hard work. But, there's a huge payoff…

We're using datomic in production. It's had its ups and downs. For one, having raw data available at in-memory speeds really changes the level of expressiveness you have in your code; you no longer are constrained to packing every question about your data into a giant query and sending it off - you can instead pull data naturally and as needed. Many of our queries make multiple queries and are high performance.

The licensing is a huge pain in the ass. If I accidentally launch an extra peer over our license limit, our production environment will stop working until the extra peer comes down. This is really butting heads with the growing popularity of abstracting physical servers as clusters so I think the strategy is kind of a mistake on cognitect's behalf.

Re: Datomic Best Practices

#23

Post by joshdick »

blintzing wrote: post #10
mattjaynes wrote: post #2

I have a client that is exploring Datomic, so I wonder if some of you can chime in on why this is popular at the moment and what your experiences are with it? I'm a big Rich Hickey fan. If you don't know who he is, he's the guy behind Clojure and Datomic. I don't use those tools, but his views on simplicity are wonderful. Here's a great quote of his on the subject: "Simplicity is hard work. But, there's a huge payoff…

I was very interested, but pretty disappointed that Datomic is completely closed source. Maybe this is a little mean, but what could be more "simple" than being able to read, understand, and modify the database you rely on? Neo4j, though marketed differently, is a similar approach (but the Community version is GPLv3 and Enterprise is AGPLv3). The Cypher query language is declarative in a similar way to Datomic - the…

Rich Hickey has been criticized for that repeatedly. When asked, he's been transparent that Datomic is closed source so that he can put his kids through college. He also points out that he already gave us the whole Clojure language open source.

It's hard for me not to sympathize with him on this.

Re: Datomic Best Practices

#24

Post by taeric »

sooheon wrote: post #21
taeric wrote: post #15

Earlier quoted context omitted.

That is the catch, all three landing strategies were coupled together. You couldn't do one without the one before it. More, previous steps had to take into account the baggage (literal) that was necessary to perform later steps.

If that's the best they could do and what got the job done, good. It's as simple as was possible and necessary. What exactly does this prove against simplicity, again?

The difference between "simple" and "as simple as possible" is the crux.

Mainly, the problem is that these speeches all talk about keeping things simple. In many problems, this can't be done. Understanding the simple helps. But the actual solution will not be simple. So any newspeak to get around that is just annoying.

Re: Datomic Best Practices

#25

Post by cliftonk »

jtmarmon wrote: post #22
mattjaynes wrote: post #2

I have a client that is exploring Datomic, so I wonder if some of you can chime in on why this is popular at the moment and what your experiences are with it? I'm a big Rich Hickey fan. If you don't know who he is, he's the guy behind Clojure and Datomic. I don't use those tools, but his views on simplicity are wonderful. Here's a great quote of his on the subject: "Simplicity is hard work. But, there's a huge payoff…

We're using datomic in production. It's had its ups and downs. For one, having raw data available at in-memory speeds really changes the level of expressiveness you have in your code; you no longer are constrained to packing every question about your data into a giant query and sending it off - you can instead pull data naturally and as needed. Many of our queries make multiple queries and are high performance. The l…

Part of me wonders why they don't open source datomic and crank up the marketing effort on the consultancy and datomic/clojure/etc support portion of the business. It seems like a much more effective model for DB companies. For direct revenue streams, they can always have tuned/monitored clusters packaged as appliances.

Re: Datomic Best Practices

#26

Post by Skinney »

taeric wrote: post #15
Skinney wrote: post #13

Earlier quoted context omitted.

> Simplicity would be to have a single mechanism for landing the Curiosity. Not 3. With one of them being a crane drop from a hovering rocket!? Why? Simple, in the way Rich Hickey advocates, means the opposite of complex, which means that things are woven together. You can have many landing strategies without them being tightly coupled together. A huge system isn't necessarily complex.

That is the catch, all three landing strategies were coupled together. You couldn't do one without the one before it. More, previous steps had to take into account the baggage (literal) that was necessary to perform later steps.

I thought you were speaking about different strategies, but in this case you're describing three different stages of an overall landing strategy. That doesn't sound complex.

Re: Datomic Best Practices

#27

Post by Skinney »

taeric wrote: post #24
sooheon wrote: post #21

Earlier quoted context omitted.

If that's the best they could do and what got the job done, good. It's as simple as was possible and necessary. What exactly does this prove against simplicity, again?

The difference between "simple" and "as simple as possible" is the crux. Mainly, the problem is that these speeches all talk about keeping things simple. In many problems, this can't be done. Understanding the simple helps. But the actual solution will not be simple. So any newspeak to get around that is just annoying.

Why not?

Re: Datomic Best Practices

#28

Post by sgrove »

arohner wrote: post #19
mattjaynes wrote: post #2

I have a client that is exploring Datomic, so I wonder if some of you can chime in on why this is popular at the moment and what your experiences are with it? I'm a big Rich Hickey fan. If you don't know who he is, he's the guy behind Clojure and Datomic. I don't use those tools, but his views on simplicity are wonderful. Here's a great quote of his on the subject: "Simplicity is hard work. But, there's a huge payoff…

I love datomic. It's a relational, ACID, transactional, non-SQL database. The upsides: SQL is a horrible language, yet all other noSQL DB also throw away the relational, transactional and ACID features that are great in postgres. Postgres with datalog syntax would basically be a win by itself. Datomic queries are data, not strings. Queries can be composed without string munging, and with clear understanding of what t…

Definitely agree re: datalog/pull syntax for SQL backends. Quite surprised it hasn't happened yet.

Re: Datomic Best Practices

#29

Post by taeric »

Skinney wrote: post #27
taeric wrote: post #24

Earlier quoted context omitted.

The difference between "simple" and "as simple as possible" is the crux. Mainly, the problem is that these speeches all talk about keeping things simple. In many problems, this can't be done. Understanding the simple helps. But the actual solution will not be simple. So any newspeak to get around that is just annoying.

Why not?

See my above post. As simple as possible is a far cry from simple. That is all I am saying.

I extend that into saying that people that can understand complicated things, as well, will have an advantage.

Re: Datomic Best Practices

#30

Post by snikeris »

anonetal wrote: post #20
dasmoth wrote: post #9

Earlier quoted context omitted.

Could you say a bit more about the query optimisation problems you've run into? The "put your most restrictive clauses first" rule (which is reiterated on the new Best Practices page) usually seems to do the trick in our hands.

I think Datomic is a very interesting project for a variety of reasons like use of Datalog, immutability etc. This particular thing seems like a backwards step though. One of the major reasons why relational databases became so popular was that: the user didn't have to think about which predicate to put first in the where clause, or which join to do first. Query optimizers can do that much better, and there is decade…

I'm sure they'll get to it eventually.
Post reply on HN