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

The thrill of a new technology: CouchDB

tempe.st

Post reply on HN
Print view View original

41–48 of 48 posts

Re: The thrill of a new technology: CouchDB

#41

Post by Tichy »

jamesbritt wrote: post #36
jshen wrote: post #32

Earlier quoted context omitted.

Yeah, the HN headline was stupid. Sadly stupid titles usually get a lot of up votes. By stupid I mean, intended to incite a knee-jerk reaction.

Same seems true of comments. I think I see Tichy's point; if you ask question, you are often ignored, or mocked. If, however, you make a (willfully) ignorant assertion, people jump at the chance to tell you just how wrong you are. Not that I want to advocate this approach, but I understand why someone would use it if, in the end, it generates more useful information. (I think this was discussed elsewhere on HN, with…

I wasn't trying to troll, I merely answered in the same tone as the submission title. Let's not blow this out of proportion.

Re: The thrill of a new technology: CouchDB

#42

Post by intinig »

jshen wrote: post #32
Tichy wrote: post #31

Earlier quoted context omitted.

I used to do that but then got negative comments from HN. Anyway, the title of the article was a bit provocative, so I hoped answering in the same spirit would not be taken as offensive. It certainly is inspiring to look into CouchDB.

Yeah, the HN headline was stupid. Sadly stupid titles usually get a lot of up votes. By stupid I mean, intended to incite a knee-jerk reaction.

I am sorry for the headline, but you're right about stupid headlines getting reactions.

Re: The thrill of a new technology: CouchDB

#43

Post by dagheti »

jrockway wrote: post #40
jules wrote: post #33

Earlier quoted context omitted.

> However, software is complex, and complexity has to live somewhere. Exactly. This argument comes up in a lot of topics. For example, that pure functional programming is easier to reason about. True, but as soon as you have to simulate state it's more complex that just having state. This is also the reason that pure functional programming isn't automatically parallelizable. Data dependencies don't magically go away.…

For example, that pure functional programming is easier to reason about. True, but as soon as you have to simulate state it's more complex that just having state. I actually disagree here. It's true that the traditional state model of "everything gets everything" makes writing code very easy. Everything can see and modify everything else, so you never have to worry about manually passing state around. This makes the…

I agree with you here 100%. Maybe this is a good pathway to explaining why relational databases are good ideas in much the same way as having a programming strategy that uses a backbone of pure functions. This purity-dividend is exactly why the relational model is such a good strategy for database management.

In the same way haskell lets you separate your pure functional code from your monadic code, giving you the ability to referentially transparent reasoning and construct imperative machines where you must, the RDBMS approach applies total logic programming to database management. It's frustrating because your code cannot all live in one language as it can in Haskell, but the separation of pure from impure is exactly where the value is coming from.

RDBMSs focus on values and total computations (you know they will halt, making it even easier to reason about queries than non-total functions) allows you to isolate simple logic programs from the rest of your impure non-total code.

Navigational databases don't give the same benefits because they are not value based nor are they total. They are the imperative-model of the database world, and though they are easy to write, they will end up difficult to debug, maintain, and keep coherent.

Re: The thrill of a new technology: CouchDB

#44

Post by jrockway »

dagheti wrote: post #43
jrockway wrote: post #40

Earlier quoted context omitted.

For example, that pure functional programming is easier to reason about. True, but as soon as you have to simulate state it's more complex that just having state. I actually disagree here. It's true that the traditional state model of "everything gets everything" makes writing code very easy. Everything can see and modify everything else, so you never have to worry about manually passing state around. This makes the…

I agree with you here 100%. Maybe this is a good pathway to explaining why relational databases are good ideas in much the same way as having a programming strategy that uses a backbone of pure functions. This purity-dividend is exactly why the relational model is such a good strategy for database management. In the same way haskell lets you separate your pure functional code from your monadic code, giving you the ab…

I don't think this is what I meant.

Re: The thrill of a new technology: CouchDB

#45

Post by dagheti »

jrockway wrote: post #44
dagheti wrote: post #43

Earlier quoted context omitted.

I agree with you here 100%. Maybe this is a good pathway to explaining why relational databases are good ideas in much the same way as having a programming strategy that uses a backbone of pure functions. This purity-dividend is exactly why the relational model is such a good strategy for database management. In the same way haskell lets you separate your pure functional code from your monadic code, giving you the ab…

I don't think this is what I meant.

I agreed with your overall point, but I was expanding on part of what you were saying:

You seem to appreciate how Haskell allows you to separate your pure code from your non-referentially transparent monadic code. This gives you reasoning where you can have it, and you use monads where you can't.

I'm just saying that same argument applies in databases where using a relational database allows you to separate your total code from your pure code. You use the value-based relational strategy where you can have it (necessary and sufficient for database management), and you use functional (or imperative) programming where you can't.

Re: The thrill of a new technology: CouchDB

#46

Post by jamesbritt »

Tichy wrote: post #41
jamesbritt wrote: post #36

Earlier quoted context omitted.

Same seems true of comments. I think I see Tichy's point; if you ask question, you are often ignored, or mocked. If, however, you make a (willfully) ignorant assertion, people jump at the chance to tell you just how wrong you are. Not that I want to advocate this approach, but I understand why someone would use it if, in the end, it generates more useful information. (I think this was discussed elsewhere on HN, with…

I wasn't trying to troll, I merely answered in the same tone as the submission title. Let's not blow this out of proportion.

I didn't mean to suggest you were trolling, just that some folks have found that adopting certain troll-like characteristics is (for better or worse) an effective means of getting informative replies.

Re: The thrill of a new technology: CouchDB

#47

Post by dasil003 »

jrockway wrote: post #37
dagheti wrote: post #28

Earlier quoted context omitted.

Ok so let's clarify this: (SQL schema & upgrades + ORM classes + Logic classes, random scripts) - (logic classes + random scripts) = SQL Schema & upgrades + ORM classes The question then becomes how do you handle the trade-off between being able to declare constraints (that evil schema) and the necessity to "map" how you access your data to your programming language. If you "program" your constraints in your host lan…

Integrity is best declared, not guarded by your program. How do programs that don't use a database stay internally consistent?

With much testing and reinventing of the wheel.
Post reply on HN