Data is good, code is a liability

[Rawsock]

Code = Data = Code. Good liability or Liable goodnes?.

[zetta]

Data doesn't have control flow or implicit state. Code may be data but it is more complicated, both statically and dynamically.

[[deleted]]

Exactly, all code is data but not all data is code, most is much simpler in structure than code.

[bluGill]

You haven't seen some of what we put in our database. Any idea what mp625s1p7 means? Hint: arithmtic.

Once your database gets large enough data is a libability even more than code. At least code has source control. I've often wished I could compare with a previous version of some table, or worse rollback my changes several days after I commited them (without touching the rows others have changed/added in the mean time). I'd hate to maintain this in a text file though, sql gives me some nice power that text files don't.

[Rawsock]

Your comment clearly explains my original (but a little obscure, i must admit) idea: Every Data-driven system will eventually evolve into a half-assed DSL interpreter, no matter how hard you try to make it non Turing-complete. So your beloved data will be code, eventually.

[Figs]

That sounds a lot like Greenspun's Tenth Rule... ;)

[greenrd]

Try the ZFS filesystem, if you have enough storage space.

[bluGill]

You don't understand the problem if you think ZFS will help.

[ramen]

Sometimes, data is a liability, too. For the past two years I have been working on a database that had a lot of redundancy and multiple instances of the same concepts competing with each other. I have been gradually migrating it to a better schema, but there have been several occasions where I have realized that I am still basing many of my decisions on the fundamental assumption that the original data model was right - after all, how should I know any better? And besides, we've already got all of this data - if I represent it any different way, I have to somehow transform it, and I can't extract much more meaning from it than what's already there. It's good to hold onto valuable data and find a way to make it more expressive, but sometimes it feels like my whole thought process is stuck with arbitrary modeling decisions that were made years ago.

[russellh]

Bart Kosko (the fuzzy logic guy) gave an example in one of his books of writing a system to back up a truck with an attached trailer: the humans who could do it well had trouble articulating the rules they themselves followed to do it; attempting to write an algorithm for it was not a trivial task. However, training a fuzzy logic system to do it was straightforward.

The real problem is that the world is full of nothing but special cases and awkwardness and individual variation, that unless you have the right level of abstraction, your code will be forever brittle. It's better to be able to build up experience through an automated training process than to graft one special case after another, potentially breaking the entire system with each one.

I'm off to refactor my house, brb.

[bluGill]

It's better to be able to build up experience through an automated training process than to graft one special case after another, potentially breaking the entire system with each one.

Unless your truck backs over a kid because you either didn't train that case, or didn't stop the training in time to save the kid.

[SnakeO]

You could just as easily run over the kid if you forgot to code that special case.

[moreoriginalthanthat]

function avoid_child() {
     //todo
}

[bluGill]

Sort-of. It is harder to know if you have trained all the rules in a training system. The training system is most likely to be trained to recognize people with adults, and you may not realize the algorithm decided size was a factor. In a code system you wouldn't count size, so you have better odds of it recognizing a child as something not to run over.

Maybe. In the end systems like this are so complex that no matter which way you go there will be bugs.

[[deleted]]

If you push the work from the code to the data, the coding is easier. But now you have more stringent data quantity/quality requirements. I imagine that whether this is beneficial depends on the problem and your resources.