Hacker News Reader

Comment by altcognito | Hacker News Reader

> They pick the wrong data structures, think about code first and data is an afterthought.

It makes me so happy to read this.

Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.

View on HN

I like these two quotes on that:

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

Fred Brooks, The Mythical Man-Month.

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

Linus Torvalds

According to SICP data and code are the same! Interesting concept anyway.

http://stackoverflow.com/questions/355406/concepts-that-surp...

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...

That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions.

As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.

Unless I misunderstand your point, how do you create complex data without complex code? I agree with the sentiment, but priority queues don't organise themselves. It seems more like its about the abstractions you use.

It's more of a general rule, a rule of thumb, and the difference between data and code can be very fluid, depending on the situation... But as a general rule it's worth paying attention to.

Just a quick example -- I need to get going -- Say I have a bunch of data in a database I need to do something to once or twice, like validating imported data. It's easier to use a complex select to get it in an easy to process form, then it is to use a simple select and have a complex algorithm to process the data. Generally, given the choice, it's easier to have complicated "static" data, since it's rather static and easier to reason about, rather than complicated "dynamic" code since algorithms are generally harder to reason about.

I agree with your choice in the example, but I think of your select as code, not as data. So, you're moving the complex code closer to the data, but it's still code IMO.

Reply on news.ycombinator.com