Greencodds Tenth Rule Of Programming

A database-oriented twist on GreenspunsTenthRuleOfProgramming in which, "Every sufficiently complex application/language/tool will either have to use a database or reinvent one the hard way." I don't know who originally said it, so I combined DrCodd's name with Greenspuns'. Ironically, even Lisp, the original "greenspun" language, reinvents one by having an internal complex data structure (nested list in byte-code form) that takes on database-like characteristics. -- top

What the heck is a "nested list in byte-code form"? I'm an experienced Lisp programmer, and I don't know what you're talking about.

The giant internal tree(s) that Lisp code compiles into. See HiddenDatabaseSyndrome.

Oh shit... Forget I asked.

I'm sure I'm going to regret commenting, but...kinda like the giant internal trees that every major database compile into? -- JonathanTang

It's an implementation detail, not a software application organization issue. The implementation could be gerbils on treadmills. If Oracle replaced the index engines with superfast gerbils on treadmills, nobody would (should?) know the difference. At the root level everything is just a list of 1's and 0's. But that does not mean that humans should work at that level. -- Top

So is the "giant internal tree(s)" that Lisp compiles into. Key word here is "compiles into"; anything being compiled into is an implementation detail.

These are perhaps syntax trees? Related perhaps to the notion that they model parsing Rules? I pray 't' please write a parser using a database please please please. Then explain to everyone here how extend the language using the language... Please.... Please Please... --- I am now sure that this is Joke page

You could quibble with the interface that Lisp presents to manipulate its code. There've been various attempts to improve it, the most recent being DylanLanguage and GooLanguage. But the fact remains that a large number of programmers find it convenient, enough that Lisp is the only language where code-that-writes-code is an inherent part of the programming culture. It's much more convenient than any table-based code representation I've seen. -- JonathanTang

Are you confident enough in those claims to take the ChallengeSixVersusFpDiscussion challenge? I suspect the frequency of utility is domain-specific at this point.

Top, it may be the case that ChallengeSixVersusFpDiscussion is a reasonable challenge; maybe, maybe not, but it seems to me that it is asking people for a lot of work, whereas mostly people drop by c2 to talk, not to work. That's just a btw.

It would not be "a lot of work" if FP greatly simplified development, as some have suggested. I picked that example because of complaints about toy examples not being thorough enough.

More to the point, would you please stop assuming you know anything whatsoever about how Lisp implements anything at all. Seriously, you have completely the wrong idea, clearly, from everything I've seen you write on the topic over a very long period of time, but you seem very fixated on the notion that you do have the right idea. You don't, really, and I'm not being insulting, just objective.

I honestly don't think some of you understand what "objective" really means.

Just don't keep assuming you do know, please? It doesn't help your arguments. Clearly, everything is implemented as bits, but beyond that, no, no, really, no. I have implemented Lisp and other languages, that sort of thing is one of my specialities, and it pains me to see huge inaccuracy on the topic. Nor is it necessary to your favorite topics, anyway. -- DougMerritt

Yes or no, internally Lisp has a "complex data structure"? And, to the Lisp programmer, that internal structure more or less resembles nested lists, IOW trees of lists? Correct or not in a general sense? Also, some of the comments above that appear to be mine are probably not mine. At least I don't remember writing them. In fact, I suspect some stuff has been removed. Something is out of whack up there. The wiki history seems to be missing the older version that I remember. Either that, my brain is playing tricks on me. I remember introducing challenge #6 over much stronger claims than "programmers find Lisp convenient". A claim like that is relative enough to not trigger my Prove-it finger. Thus, either what I responded to was removed or I misinterpreted what is there. --top

As a side issue, I suppose I should ask if you believe in any of the mainstream orthodox definitions of "database"? Hopefully there are definitely things that are databases, and also things that definitely are not databases? Persistence hopefully figures into the definition? And although most e.g. business applications should use a database, other kinds of apps need not, right? Like, oh, say the calculator app that comes with Windows, which doesn't keep a history -- it doesn't need a database, so long as it doesn't keep a history, right? -- Doug

Re: "Persistence hopefully figures into the definition?" - There is talk of "RAM-only" databases being prepared to improve speed. Disk is merely a convenience, not a prerequisite to be called a "database". Ideally a database should abstract away storage implementation mechanisms from the database user. This was a key goal of DrCodd. I would generally call a database a "general tool to manage large quantities and/or volumes of attributes". By "general" I don't necessarily mean it can be used for everything, but rather it is not geared toward any single application but rather an attempt to provide a tool to handle common attribute-handling needs of multiple or different applications. If you can think of a tool that fits this bill but would not be considered a "database", then perhaps this working definition needs amendments.

Candidate defining properties of a database (and the "DBMS" that supports it) (feel free to edit):

Not defining properties of DB[MS]s in general (though required for RDBMSs): Can we agree on something like "any 4 of the 6 makes it a DB[MS]"?

Some test cases:

Obviously, the more you implement without using a DBMS, the nearer to GreencoddsTenthRuleOfProgramming you are getting.

There is already a list of "database features" under DatabaseDefinition.

This is overblown, rather like Greenspun's rule. I program 'little databases' to go with 'little languages'. The former look nothing like Oracle just as the latter look nothing like LISP. Extending definitions till they cover the entire universe makes the definitions rather pointless. So perhaps the question is: "what is NOT a database by this definition?"

Are there similarities that can be factored to a single tool? Do you reinvent them because there are no satisfactory existing implementations, or because the needs are too different per app?

Mainly because I can, but also because I rather like minimalist designs that run really fast, and gluing a giant general purpose persistence engine onto a small app is silly.

Do you think a DB or DB-like tool can be both minimalist and somewhat general purpose? Plus, don't you risk a DiscontinuitySpike when you have to scale something to a RDBMS of some kind? Further, I disagree that DB engines have to be big and bulky. I agree that existing tools often don't offer much choices, but easy tables were common in the 80's before OO hype pelted such tools with bloated interfaces and bloated engines. The Oracle model is not the only model. Further, the DB engine is now smaller than many of the related engines with languages such as Java and The bloat argument does not hold much weight. (Note that the SqLite engine in C is available for embedded apps.) Related: SimplifyingRdbms and MinimalTable.

An app is stepping into DB Land when it has lots of repeating "instances" of something and DB-ish operations (CollectionOrientedVerbs) tend to be needed on these intances. These actions include the likes of search, sort, cross-reference, summarize, concurrency management, etc.

An example of GreenspunsTenthRuleOfProgramming may be found in TooMuchGuiCode. GUI's can largely be reduced to attributes, and managing those attributes via code (set/get's) can be tedious, verbose, difficult, and not easily sharable or reusable across languages. For example, it would be nice to be able to query the GUI attributes for certain kinds of debugging. However, code-centric techniques often don't make such very easy. You have to guess what is going on based on static code. (Related: AdvantagesOfExposingRunTimeEngine.) --top

Re: "My ObjectBrowser has query-like capabilities, so I don't need a stinkin' database."

Dude, you HAVE a database now, it's just not a relational one, and uses RAM instead of disk.

Combine with ReinventingTheDatabaseInApplication? Except, sometimes it is language features, not just applications. See DoubleCheckedLockingIsBroken.

See also: TableOrientedProgramming

CategoryRant, CategoryRelationalDatabase

EditText of this page (last edited November 18, 2011) or FindPage with title or text search