The Redis Manifesto | Hacker News Reader

The Redis Manifesto

antirez.com

191 pointstednaleid26 comments

We optimize for joy. We believe writing code is a lot of hard work, and the only way it can be worth is by enjoying it. When there is no longer joy in writing code, the best thing to do is stop. To prevent this, we'll avoid taking paths that will make Redis less of a joy to develop.

Love this as a priority, and not just as a coder, but as anyone involved in building software. I've noticed an extremely high correlation with how enjoyable a code base is to work on, and how easily I get into The Zone on that project. Hopefully I don't need to elaborate on the correlation between The Zone and developing a kick ass product in record time.

As for the meaning of enjoyable, well... hire great developers, listen to them when they speak, and make having a great, well designed, low code debt code base a priority whenever possible.

I'm not saying that redis is undocumented or buggy.

But stopping and avoiding taking paths that will make redis less of a joy, will make it so.

(Sometimes) solving bugs, adding documentation, support are not exactly joyful activities. But I'm picking on that phrase and not on Redis.

You misunderstand "joy". Least resistance <> joyful.

A buggy codebase, or one that is difficult to work in, is inherently non-joyful. Thus, removing bugs, cleaning up architectural mis-steps, improving the code for the next iteration, etc., are joyful activities.

This applies in life beyond software development, too...

Totally agree. I'm surprised more people don't figure this out. Our assumption that work and fun are opposed seems like an atavism from millenia of scrounging and slavery. Admittedly, those millenia are still going on for countless people, but not for those of us blessed with the chance to do creative work. Creative work is fun, even when it's gruelling. This is so vital for software projects that I sometimes toy with the conclusion that it's the most important thing - not the most valuable thing (that's what you create) but the most important indicator about the project itself. It's the canary in the coal mine: if fun goes, everything goes. You can walk into a software team's space and tell within minutes how a project is going by attending to this. Yet billions of dollars get spent trying to answer the same question.

While I'm surprised that so few people figure this out, I'm also surprised to see it expressed so elegantly as "We optimize for joy." Yay Salvatore! More projects should have manifestos. I want to write one!

I also love the phrasing of "we optimize for joy" and totally agree about the relation between enjoying a code base and getting into The Zone.

One caveat though: whose joy is getting optimized for? The phrasing here makes it seem like it's only the developers' of Redis. I'd love this a lot more if they're also trying to optimize the joy of people using it as well.

The bit about "if we ever come in contact with other forms of life, they'll understand other basic data structures" is really interesting. I had never thought about that, but it's probably true.

It's not exactly a "data structure" but we lean on expectations like these with some of our outgoing extraterrestrial communications when we send patterns based around prime numbers.

This sounds like the Anthropic Principle, which to me is a tautology or hasty generalization: "We're intelligent, and this makes sense to us, so this must be how intelligent beings make sense of things. QED bitches!"

The assumption is that the particular way of understanding the world that humans possess is the only intelligent way to comprehend it. First off, the way that we categorize the world is (as far as we can know) unique to us, and it is also the only way that we have to understand the universe -- it encompasses our math, science, epistemology, ontology and whatever other ways we categorize experiences.

We have no way of understanding anything that cannot be represented by this system of categorizing knowledge and experience, and that includes other incompatible systems which may in fact be superior. Nassem Taleb says that categorization is a necessary human activity, and I would agree. But it's not impossible to conceive of a worldview that is not predicated on categorization, and which could in fact be superior. It's not unthinkable also, that a being with such a worldview might use different (and possibly superior) informatics than our system, with its lists, maps and trees.

Suppose a two-dimensional being claims that his understanding of the universe is supreme and all other intelligent beings would likely use his own system of knowledge representation, manipulation and communication. It is likely that those techniques would seem feeble and impoverished to us. So why can we boldly claim -- a priori -- that all forms of intelligence we may encounter would use our systems?

As you say, not all things are universal. Data structures, however, are based on principles, such as divide and conquer, that you may well argue transcend the human condition.

Yes it can be argued, but the argument would be unproductive: either idealizations correspond to fundamental conditions in the universe or they are merely artifacts of human perception. But we would know only when we meet intelligent non-humans, and not before.

Once again, the philosophers are stuck in a busy-loop, waiting for empirical evidence to sweep their debate away into the tedious realm of science.

DNA is a data structure, isn't it? (I'm not a biologist so perhaps it's more accurate to say that genomes, or the double-helix structure of DNA, or whatever, is a data structure, but I'm sure you get my point: there are data structures which were created without any human involvement whatsoever, so it doesn't seem to be a stretch to assume that alien species would understand them or perhaps even use them.)

I don't think you would refer to the raw sectors on your harddrive as a data structure. It may be more useful to view DNA as a just storage medium.

There's an encoding scheme on top of the nucleotides -- amino acids are encoded with trinucleotides. The RNA sequence AUG can be used as a start signal to indicate that peptide synthesis should begin at that point (it can also be used to encode the residue Methionine). Other sequences encode splice sites, these are used to signal the removal of sequences called introns.

Still other sequences (DNA binding sites, like the famous TATA box) have a high affinity for protein (those with DNA binding domains). The presence or absence of enhancers or suppressors can activate or deactive protein synthesis.

DNA also contains error checking information. Eukaryotic DNA undergoes methylation (think of this as adding meta-data to the DNA). After cells undergo replication, the new DNA is untagged. When error-checking enzymes happen upon a mismatch in the DNA, they remove the untagged base. There are also unrecoverable errors. For example, two adjacent Thymine bases can undergo cross-linking upon ultraviolet exposure -- the bases get stuck together. This sort of error can contribute to melanoma.

I don't think that the data structure analogy is appropriate for DNA, but there are certainly data structures encoded on top of it.

Great stuff. We love Redis and I've always been impressed with the quality of the software (and readability of the code). This manifesto makes sense in that context. I like 'Redis is a data structure server' better than what point #1 says now.

Agreed. Also, viewing this as a manifesto, you might want move this out of the list and reframe this as a definition, instead of making it point #1. It's crucial, but at least to me doesn't have the same punch as the others.

Just to be clear this is intended only a minor wording suggestion, not a criticism -- great piece, really gave me a feel for what you're doing with Redis and why so many people are into it.

"4 - Code is like a poem..."

This item makes me want to read the Redis source.

(All the items do, actually.)

You should. I'm absolutely not a C programmer but I found I could follow the Redis source and figure out pretty much exactly what was going on for the most part - it's just a bunch of fundamental data structures hooked up to a simple network server.

Longevity is difficult to predict, but I suspect Salvatore's approach will seem familiar to those who wrote some of the decades-old software that programmers still use every day.

I suggest having a Redis command for it: redis man. Similar in a way to Python's import this

There's already a Google command for it: "redis manifesto". This also turns up some discussion threads, which is an added bonus.

Try to get that from the command line :-).

Call me a grumpy programmer but "optimizing for joy" reminds me of Ruby's "a programmer's best friend". Come on, keep it real... less marketing. For example, how is Redis a DSL? Is everything a DSL these days? How is it for ADTs in general? It's not for all ADTs, just the ones that are very commonly used, the ones you support. Which is good, but it's another example of your marketing missing the mark.

How Redis is a DSL? The basic 'verbs' and the command structure is taken from the Tcl language. See lrange, append, set, and many others. But it's not a full featured language of course, just a domain specific one for manipulating ADTs. But why is this DSL thing so important for Redis? If you look at the internals you'll discover Redis is in many ways an interpreter. So I think this is really important to stress to understand what Redis really is.

In the Redis manifesto there is no place where I claim we support all the kind of ADTs. We just have random access arrays, lists, sorted sets (trees), and dictionaries.

There was no marketing intention in the Redis manifesto.

Is Apache a DSL?

I agree that the manifesto doesn't explicitly claim to support all kinds of ADTs. It just wasn't clear.

Manifesto without a marketing intention... interesting :)

I think that one of the biggest reasons antirez had for writing the manifesto was not for marketing, but so that he had a place to point people to who try to make Redis something that it's not. Feature requests/patches that don't fit the philosophy can be more easily rejected because there is a clear document spelling out what the goals of Redis are.

Much like the Zen of Python.

Reply on news.ycombinator.com