5 ms·

Not a single mention of data structures. It really is the heart of software when done properly. You can often tell if someone is a subscriber of that view depen

Not a single mention of data structures. It really is the heart of software when done properly. You can often tell if someone is a subscriber of that view depending on where they place their data structures in the source files. Once the data layout is properly designed, the data transformations required become clear and the rest of grunt work.

monocasa 5y ago
> Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. ~ Fred Brooks > I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. ~ Linus Torvalds
robotpony 5y ago
> "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." ~ Rob Pike
ItsMonkk 5y ago
All programming is made up of data structures and algorithms. A program could be all data structure, a mixture of the two, or all algorithms. In a perfect world, where a team has infinite time and money and a perfect understanding of the problem, it would be all data structure and no algorithm. Algorithms are technical debt.
- sidpatil 5y ago
  This sounds interesting to me. Can you please provide an example so I can understand this better?
  - ItsMonkk 5y ago
    Well no one has infinite time and money and a perfect understanding of any complex problem yet, but I think the F# DDD[0] overview can show an example much closer to more data structures and less algorithms. [0]:https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/
- shnock 5y ago
  What sidpatil said. This whole comment section is indicating there is a yawning gap in my understanding of system design.
- rogers18445 5y ago
  This may sound good to someone but it doesn't make good sense. Data structures aren't free, they take space. Therefore there is a trade-off between space and compute complexity. And ultimately data structures don't transform themselves, an algorithm has to do the transformation... Once you modeled your problem into some data structures you now need to make the decision of whether or not the transformation between input and output is easily achievable with an algorithm, if not then you need to further break down the problem into more data structures or your design is flawed.
  - ItsMonkk 5y ago
    Yeah, I agree with most of what you put here. I'm mostly speaking to the articles point where we are in an alternate reality with different built up structures. When thinking about going purely data structure, I was thinking something like Church Encoding[0] or Prolog. Is that practical today? No. The effort required to get a full program created at that level of detail would be enormous. Technical debt is in itself not a bad thing, and I'm not saying anyone in this realities goal should be no algorithms. [0]: https://blog.ploeh.dk/2018/05/22/church-encoding/ https://blog.ploeh.dk/2018/05/22/church-encoding/
bcrl 5y ago
Agreed 100%. What are the common cases we need the data structures to optimize? How does this penalize other parts of the system? How do we make the data structures extensible for new features in the future? Does this data structure prevent us from making any other use-cases work well? How complex is the resulting system going to be, and will this cause us any future maintenance issues? Does everyone on the team understand the approach we are taking? My experience is that good teams start by asking lots of questions. The design may not be entirely formal, but good developers do go through the process of figuring out their internal list of requirements needed to satisfy the requirements of the system as a whole, and try to make sure that the decisions made are well thought out and don't box the codebase into a problem space in the future.

monocasa 5y ago

> Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. ~ Fred Brooks > I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. ~ Linus Torvalds

robotpony 5y ago

> "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." ~ Rob Pike

ItsMonkk 5y ago

All programming is made up of data structures and algorithms. A program could be all data structure, a mixture of the two, or all algorithms. In a perfect world, where a team has infinite time and money and a perfect understanding of the problem, it would be all data structure and no algorithm. Algorithms are technical debt.

sidpatil 5y ago
This sounds interesting to me. Can you please provide an example so I can understand this better?
- ItsMonkk 5y ago
  Well no one has infinite time and money and a perfect understanding of any complex problem yet, but I think the F# DDD[0] overview can show an example much closer to more data structures and less algorithms. [0]:https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/
shnock 5y ago
What sidpatil said. This whole comment section is indicating there is a yawning gap in my understanding of system design.
rogers18445 5y ago
This may sound good to someone but it doesn't make good sense. Data structures aren't free, they take space. Therefore there is a trade-off between space and compute complexity. And ultimately data structures don't transform themselves, an algorithm has to do the transformation... Once you modeled your problem into some data structures you now need to make the decision of whether or not the transformation between input and output is easily achievable with an algorithm, if not then you need to further break down the problem into more data structures or your design is flawed.
- ItsMonkk 5y ago
  Yeah, I agree with most of what you put here. I'm mostly speaking to the articles point where we are in an alternate reality with different built up structures. When thinking about going purely data structure, I was thinking something like Church Encoding[0] or Prolog. Is that practical today? No. The effort required to get a full program created at that level of detail would be enormous. Technical debt is in itself not a bad thing, and I'm not saying anyone in this realities goal should be no algorithms. [0]: https://blog.ploeh.dk/2018/05/22/church-encoding/ https://blog.ploeh.dk/2018/05/22/church-encoding/

bcrl 5y ago

Agreed 100%. What are the common cases we need the data structures to optimize? How does this penalize other parts of the system? How do we make the data structures extensible for new features in the future? Does this data structure prevent us from making any other use-cases work well? How complex is the resulting system going to be, and will this cause us any future maintenance issues? Does everyone on the team understand the approach we are taking? My experience is that good teams start by asking lots of questions. The design may not be entirely formal, but good developers do go through the process of figuring out their internal list of requirements needed to satisfy the requirements of the system as a whole, and try to make sure that the decisions made are well thought out and don't box the codebase into a problem space in the future.