25 ms·

". . . unlike every single horror I've ever witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-do

". . . unlike every single horror I've ever witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. . . . "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, https://lwn.net/Articles/193245/ https://lwn.net/Articles/193245/

gimboland 7y ago
That last comment is absolutely golden. Once upon a time I had the privilege to spend a few years working in Swansea University's compsci department, which punches above its weight in theoretical computer science. One of the moments that made me the programmer I am today (whatever that's worth) came when I was meeting with the head of the department to discuss a book he was writing, and while we were discussing this very point of data vs code, I said to him, realising the importance of choosing the right structure, "so the data is central to the subject" (meaning computer science in general" — to which he replied emphathically that "the data IS the subject". That was a lightbulb moment for me. From then on I saw computer science as the study of how data is represented, and how those representations are transformed and transported — that's it, that basically covers everything. It's served me well.
- abtinf 7y ago
  I think part of the confusion stems from the word “computer” itself. Ted Nelson makes the point that the word is an accident of history, arising because main funding came from large military computation projects. But computers don’t “compute”, they don’t do math. Computers are simplifying, integrating machines that manipulate symbols. Data (and its relationships) is the essential concept in the term “symbolic manipulator”. Code (ie a function) is the essential concept in the term “compute”.
  - yrro 7y ago
    In Anathem by Neal Stephenson, computers are called Syntactic Devices ("syndev").
  - kmonsen 7y ago
    Hmm, interesting. In Norwegian the word for computer translates to "data machine" (datamaskin)
    - Ma8ee 7y ago
      As in Swedish.
      - hanche 7y ago
        The Swedish name is “dator”, isn’t it? Its root is certainly “data”, but I like it better than the more cumbersome Norwegian word “datamaskin”.
        nemetroid 7y ago
        Yes, it's "dator". The word was initially proposed based on the same Latin -tor suffix as in e.g. doctor and tractor, so the word would fit just as well into English as it does in Swedish.
        asjo 7y ago
        And in Danish we had "datamat", which has a nice ring to it. But everybody says "computer" instead.
        Ma8ee 7y ago
        I’ve always thought that dator was just a short form of datamaskin. But some other comments suggested otherwise, so I had to look it up. Apparently, dator is a made up word from 1968, from data and parallels the words tractor and doctor.
  - sixstringtheory 7y ago
    But what is math, if not symbolic manipulation? Numbers are symbols that convey specific ideas of data, no? And once you go past algebra, the numbers are almost incidental to the more abstract concepts and symbols. Not trying to start a flamewar, I just found the distinction you drew interesting.
- solarkraft 7y ago
  Computer science indeed sounds a lot like you're working with computers. In German the subject is called "Informatik", translating to information science. I find that quite elegant in contrast.
  - anoncake 7y ago
    It also helps identifying journalists that don't know what they are writing about. They frequently translate "computer science" literally as "Computerwissenschaft".
  - gimboland 7y ago
    Yes, I've heard it said that calling it computer science is like calling astronomy "telescope science".
- mapgrep 7y ago
  That's great. It reminds me of a comment by Rich Hickey, the inventor of Clojure: " Before we had all this high falutin' opinions of ourselves as programmers and computer scientists and stuff like that, programming used to be called data processing. How many people actually do data processing in their programs? You can raise your hands. We all do, right? This is what most programs do. You take some information in, somebody typed some stuff, somebody sends you a message, you put it somewhere. Later you try to find it. You put it on the screen. You send it to somebody else. That is what most programs do most of the time. Sure, there is a computational aspect to programs. There is quality of implementation issues to this, but there is nothing wrong with saying: programs process data. Because data is information. Information systems ... this should be what we are doing, right? We are the stewards of the world's information. And information is just data. It is not a complex thing. It is not an elaborate thing. It is a simple thing, until we programmers start touching it. So we have data processing. Most programs do this. There are very few programs that do not. And data is a fundamentally simple thing. Data is just raw immutable information. So that is the first point. Data is immutable. If you make a data structure, you can start messing with that, but actual data is immutable. So if you have a representation for it that is also immutable, you are capturing its essence better than if you start fiddling around. And that is what happens. Languages fiddle around. They elaborate on data. They add types. They add methods. They make data active. They make data mutable. They make data movable. They turn it into an agent, or some active thing. And at that point they are ruining it. At least, they are moving it away from what it is." https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureMadeSimple.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- lttlrck 7y ago
  A mentor often repeated the title of Niklaus Wirth’s 1975 book “Algorithms Plus Data Structures Equals Programs”. This encapsulates it for me and informs my coding everyday. If I find myself having a hard time with complexity, I revisit the data structures.
- blablabla123 7y ago
  I also really like this quote and his has influenced the way I work a lot. When I started working professionally as programmer I sometimes ended up with quite clunky data structures, a lot of expensive copying (C++ :-)) and difficult maintenance. But based on this, I always take greatest care about the data structures. Especially when designing database tables, I keep all the important aspects of it in mind (normalization/denormalization, complexity of queries on it, ...) Makes writing code so much more pleasurable and it's also key to make maintenance a non-issue. Amazing how far-sighted this is, when considering that most Web Apps are basically I/O - i.e. data - bound.
- robomartin 7y ago
  Many decades ago I was coaxed into signing-up for an APL class by my Physics professor. He was a maverick who had managed to negotiate with the school to create an APL class and another HP-41/RPN class with full credit that you could take instead of FORTRAN and COBOL (yeah, it was a while ago). One of the things he pounded into everyone's heads back then was "The most important decision you have to make is how to represent the problem. Do that well and programming will be easy. Get it wrong and there isn't a force on this world that will help you write a good solution in any programming language." In APL data representation is of crucial importance, and you see the effects right away. It turned out to be he was right on that point regardless of the language one chose to use. The advise is universal.
- emmelaich 7y ago
  Linus was probably exposed to Wirth's book (from 1976) at some point. I believe it was the first major CS book that emphasised data structures. https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures...
  - freddie_mercury 7y ago
    The Mythical Man-Month, published a year before Wirth's book, provides the most well-known quote on the subject (though he uses now antiquated language): "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." But I don't think Brooks was trying to suggest it was an original idea to him or his team, either. I imagine there were a decent number of people who reached the same conclusion independently.
- asjo 7y ago
  Interestingly, Computer Science is called "Datalogi" in Danish. I always liked that term better. Coined by Peter Naur (of BNF-"fame"), by the way.
  - krueger71 7y ago
    Same in Swedish. Also the Swedish word for computer is dator. Don't know if this in any way shifts the mental perspective though.
    - agapon 7y ago
      Informatika (Інформатика) in Ukrainian. Probably originated from German or French.
simplify 7y ago
"The more I code the more I observe getting a system right is all about getting the data structures right. And unfortunately that means I spend a lot of time reworking data structures without altering (or improving) functionality..." https://devlog.at/d/dYGHXwDinpu https://devlog.at/d/dYGHXwDinpu
jasonzemos 7y ago
"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." This quote is from Alan Perlis' Epigrams on Programming (1982).
- mateuszf 7y ago
  Which is also a base design principle of Clojure. There are few persistent data structures at the core, a sequence abstraction and lots of functions to work on them.
- rightbyte 7y ago
  So you would have one data structure with 10 pointers to those 10 data structures you need and 10 times the functions? Id rather split up independent structures.
  - amw-zero 7y ago
    Having a smaller amount of data structures makes the whole graph of code more comparable. Creating a bespoke data structure for 10 different elements of a problem means writing quite a lot of code just to orchestrate each individual structure, mostly due to creating custom APIs for accessing what is simple data underneath the hood. There’s a reason why equivalent Clojure code is much much shorter than comparable programs in other languages.
statictype 7y ago
There's a good bit about data structure-centric programming in The Art Of Unix Programming: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263 http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id... (Apologies for linking to esr but it's a good book)
- CDSlice 7y ago
  What's wrong with esr?
  - japanoise 7y ago
    He's become somewhat controversial due to his worldview and political writings, which include climate change denial
    - gdy 7y ago
      And this has nothing to do with programming. Imagine Einstein alive and denying climate change. Would you apologize every time when you are referring to the theory of relativity? P.S. Sorry, if you don't agree with the apologising comment and were just informing about possible reasons.
      - kqr 7y ago
        Referring to relativity and linking to Einstein's personal web page are surely two different things, no?
        gdy 7y ago
        Yes, but I don't think this invalidates my analogy
      - statictype 7y ago
        The theory of relativity is a much bigger contribution to society than TAOUP. The chapter I linked to was just a summary of ideas put forth by others - though admittedly written well. My problem with esr is more his arrogance and conceit than politics (which I also find distasteful)
billiam 7y ago
If I could say just one thing about programming to my kids, I would quote this.
rumanator 7y ago
> "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." It should be noted that the basic premise of Domain-Driven Design is that the basis of any software project is the data structure that models the problem domain, and thus the architecture of any software project starts by identifying that data structure. Once the data structure is identified then the remaining work consists of implementing operations to transform and/or CRUD that data structure.
- discreteevent 7y ago
  DDD is about modeling which is data and behaviour.
  - rumanator 7y ago
    > DDD is about modeling which is data and behaviour. It really isn't. DDD is all about the domain model, not only how to synthesize the data structure that represents the problem domain (gather info from domain experts) but also how to design applications around it.
dTal 7y ago
Ah yes, the old insight. Fred Brooks: "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious."
- combatentropy 7y ago
  Yes, and here's one by Rob Pike, "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be selfevident. Data structures, not algorithms, are central to programming." --- https://www.lysator.liu.se/c/pikestyle.html https://www.lysator.liu.se/c/pikestyle.html I think I found all these quotes on SQLite's website, https://www.sqlite.org/appfileformat.html https://www.sqlite.org/appfileformat.html
victor106 7y ago
Can anyone point to some good resources that teach how to code around data and not the other way round?
- combatentropy 7y ago
  The Art of Unix Programming, by Eric Raymond, particularly chapter 9: http://www.catb.org/~esr/writings/taoup/html/generationchapter.html http://www.catb.org/~esr/writings/taoup/html/generationchapt...
- rienbdj 7y ago
  Switch to a language that emphasises functional programming (F#, Clojure, OCaml, etc) and it will happen naturally.
- rramadass 7y ago
  Surprisingly there is no one book AFAIK but techniques are spread across many books; The first thing is to understand FSMs and State Transition Tables using a simple two-dimensional array. Implementing a FSM using a while/ifthenelse code vs. Transition table dispatch will really drive home the idea behind data-driven programming. There is a nice explanation in Expert C Programming: Deep C secrets. SICP has a detailed chapter on data-driven programming. An old text by Standish; Data Structure Techniques. Also i remember seeing a lot of neat table based data-driven code in old Data Processing books using COBOL. Unfortunately i can't remember their names now. Just browse some of the old COBOL books in the library.
YeGoblynQueenne 7y ago
>> Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Tsk. Now I'll never know if I'm a good programmer. I do all my programming in Prolog and, in Prolog, data is code and code is data.
gameswithgo 7y ago
These are ideas echoed by some of the top people in the game development community as well. there is a nice book about these kinds of ideas: https://www.amazon.com/dp/1916478700 https://www.amazon.com/dp/1916478700
rstuart4133 7y ago
> I'm a huge proponent of designing your code around the data That same comment was made to a class I was in by a University Professor, only he didn't word it like that. He was discussing design methodologies and tools - I guess things like UML and his comment was he "preferred Jackson, because it revolved around the the data structures, and they changed less than the external requirements". (No, I have no idea what Jackson is either.) Over the years I have come to appreciate the core truth in that statement - data structures do indeed evolve slower than API's - far slower in fact. I have no doubt the key to git's success was after of years of experience of dealing with VCS systems Linux hated, he had an epiphany and came up with the fast and efficient data structure that captured the exact things he cared about, but left him the freedom to change the things that didn't matter (like how to store the diff's). Meanwhile others (hg, I'm looking at you) focused on the use cases and "API" (the command line interface in this case). The end result is git had a bad API, but you could not truly fuck it up because the underlying data structure did a wonderful job of representing a change history. Turns out hg's API wasn't perfect after all and it's found adapting difficult. Git's data structure has had hack upon hack tacked onto the side of it's UI, but still shines through as strong and as simple as ever. Data structures evolving much more slowly than API's does indeed give them the big advantage of being a solid rock base for futures design decisions. However they also have a big down side - if you decide that data structure is wrong it changes everything - including the API's. Tacking on a new function API on the other hand is drop dead easy, and usually backwards compatible. Linus's git was wildly successful only because he did something remarkably rare - got it right on the first attempt.
- tonyarkles 7y ago
  My memory is a little fuzzy, but I think Jackson was/is an XML serializer/deserializer that operates on POJOs (potentially with annotations). You define your data structures as Java objects, and Jackson converts them to XML for you. As opposed to other approaches where you define some schema in non-Java (maybe an XSD) and have your classes auto-generated for you.
- lstamour 7y ago
  Perhaps Jackson refers to https://en.wikipedia.org/wiki/Jackson_system_development https://en.wikipedia.org/wiki/Jackson_system_development
euske 7y ago
I remember that Richard Hipp (SQLite creator) once cited a bunch of similar quotes including the Linus' one. https://www.percona.com/sites/default/files/hipp%20sqlite%20percona-raleigh-20150212.pdf https://www.percona.com/sites/default/files/hipp%20sqlite%20... "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, The Mythical Man-Month, pp. 102-103
erikpukinskis 7y ago
Jonathan Blow is also talking about data-oriented programming as a basis for designing his Jai programming language.
- amw-zero 7y ago
  Data-oriented programming in games is a completely different concept though. It’s about designing your data to be able to be operated on very efficiently with modern computer hardware. It speeds up a lot of the number crunching that goes on in extremely fast game loops. The Linus comment is about designing your programs around a data representation that efficiently models your given problem.

gimboland 7y ago

That last comment is absolutely golden. Once upon a time I had the privilege to spend a few years working in Swansea University's compsci department, which punches above its weight in theoretical computer science. One of the moments that made me the programmer I am today (whatever that's worth) came when I was meeting with the head of the department to discuss a book he was writing, and while we were discussing this very point of data vs code, I said to him, realising the importance of choosing the right structure, "so the data is central to the subject" (meaning computer science in general" — to which he replied emphathically that "the data IS the subject". That was a lightbulb moment for me. From then on I saw computer science as the study of how data is represented, and how those representations are transformed and transported — that's it, that basically covers everything. It's served me well.

abtinf 7y ago
I think part of the confusion stems from the word “computer” itself. Ted Nelson makes the point that the word is an accident of history, arising because main funding came from large military computation projects. But computers don’t “compute”, they don’t do math. Computers are simplifying, integrating machines that manipulate symbols. Data (and its relationships) is the essential concept in the term “symbolic manipulator”. Code (ie a function) is the essential concept in the term “compute”.
- yrro 7y ago
  In Anathem by Neal Stephenson, computers are called Syntactic Devices ("syndev").
- kmonsen 7y ago
  Hmm, interesting. In Norwegian the word for computer translates to "data machine" (datamaskin)
  - Ma8ee 7y ago
    As in Swedish.
    - hanche 7y ago
      The Swedish name is “dator”, isn’t it? Its root is certainly “data”, but I like it better than the more cumbersome Norwegian word “datamaskin”.
      - nemetroid 7y ago
        Yes, it's "dator". The word was initially proposed based on the same Latin -tor suffix as in e.g. doctor and tractor, so the word would fit just as well into English as it does in Swedish.
      - asjo 7y ago
        And in Danish we had "datamat", which has a nice ring to it. But everybody says "computer" instead.
      - Ma8ee 7y ago
        I’ve always thought that dator was just a short form of datamaskin. But some other comments suggested otherwise, so I had to look it up. Apparently, dator is a made up word from 1968, from data and parallels the words tractor and doctor.
- sixstringtheory 7y ago
  But what is math, if not symbolic manipulation? Numbers are symbols that convey specific ideas of data, no? And once you go past algebra, the numbers are almost incidental to the more abstract concepts and symbols. Not trying to start a flamewar, I just found the distinction you drew interesting.
solarkraft 7y ago
Computer science indeed sounds a lot like you're working with computers. In German the subject is called "Informatik", translating to information science. I find that quite elegant in contrast.
- anoncake 7y ago
  It also helps identifying journalists that don't know what they are writing about. They frequently translate "computer science" literally as "Computerwissenschaft".
- gimboland 7y ago
  Yes, I've heard it said that calling it computer science is like calling astronomy "telescope science".
mapgrep 7y ago
That's great. It reminds me of a comment by Rich Hickey, the inventor of Clojure: " Before we had all this high falutin' opinions of ourselves as programmers and computer scientists and stuff like that, programming used to be called data processing. How many people actually do data processing in their programs? You can raise your hands. We all do, right? This is what most programs do. You take some information in, somebody typed some stuff, somebody sends you a message, you put it somewhere. Later you try to find it. You put it on the screen. You send it to somebody else. That is what most programs do most of the time. Sure, there is a computational aspect to programs. There is quality of implementation issues to this, but there is nothing wrong with saying: programs process data. Because data is information. Information systems ... this should be what we are doing, right? We are the stewards of the world's information. And information is just data. It is not a complex thing. It is not an elaborate thing. It is a simple thing, until we programmers start touching it. So we have data processing. Most programs do this. There are very few programs that do not. And data is a fundamentally simple thing. Data is just raw immutable information. So that is the first point. Data is immutable. If you make a data structure, you can start messing with that, but actual data is immutable. So if you have a representation for it that is also immutable, you are capturing its essence better than if you start fiddling around. And that is what happens. Languages fiddle around. They elaborate on data. They add types. They add methods. They make data active. They make data mutable. They make data movable. They turn it into an agent, or some active thing. And at that point they are ruining it. At least, they are moving it away from what it is." https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureMadeSimple.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
lttlrck 7y ago
A mentor often repeated the title of Niklaus Wirth’s 1975 book “Algorithms Plus Data Structures Equals Programs”. This encapsulates it for me and informs my coding everyday. If I find myself having a hard time with complexity, I revisit the data structures.
blablabla123 7y ago
I also really like this quote and his has influenced the way I work a lot. When I started working professionally as programmer I sometimes ended up with quite clunky data structures, a lot of expensive copying (C++ :-)) and difficult maintenance. But based on this, I always take greatest care about the data structures. Especially when designing database tables, I keep all the important aspects of it in mind (normalization/denormalization, complexity of queries on it, ...) Makes writing code so much more pleasurable and it's also key to make maintenance a non-issue. Amazing how far-sighted this is, when considering that most Web Apps are basically I/O - i.e. data - bound.
robomartin 7y ago
Many decades ago I was coaxed into signing-up for an APL class by my Physics professor. He was a maverick who had managed to negotiate with the school to create an APL class and another HP-41/RPN class with full credit that you could take instead of FORTRAN and COBOL (yeah, it was a while ago). One of the things he pounded into everyone's heads back then was "The most important decision you have to make is how to represent the problem. Do that well and programming will be easy. Get it wrong and there isn't a force on this world that will help you write a good solution in any programming language." In APL data representation is of crucial importance, and you see the effects right away. It turned out to be he was right on that point regardless of the language one chose to use. The advise is universal.
emmelaich 7y ago
Linus was probably exposed to Wirth's book (from 1976) at some point. I believe it was the first major CS book that emphasised data structures. https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures...
- freddie_mercury 7y ago
  The Mythical Man-Month, published a year before Wirth's book, provides the most well-known quote on the subject (though he uses now antiquated language): "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." But I don't think Brooks was trying to suggest it was an original idea to him or his team, either. I imagine there were a decent number of people who reached the same conclusion independently.
asjo 7y ago
Interestingly, Computer Science is called "Datalogi" in Danish. I always liked that term better. Coined by Peter Naur (of BNF-"fame"), by the way.
- krueger71 7y ago
  Same in Swedish. Also the Swedish word for computer is dator. Don't know if this in any way shifts the mental perspective though.
  - agapon 7y ago
    Informatika (Інформатика) in Ukrainian. Probably originated from German or French.

simplify 7y ago

"The more I code the more I observe getting a system right is all about getting the data structures right. And unfortunately that means I spend a lot of time reworking data structures without altering (or improving) functionality..." https://devlog.at/d/dYGHXwDinpu https://devlog.at/d/dYGHXwDinpu

jasonzemos 7y ago

"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." This quote is from Alan Perlis' Epigrams on Programming (1982).

mateuszf 7y ago
Which is also a base design principle of Clojure. There are few persistent data structures at the core, a sequence abstraction and lots of functions to work on them.
rightbyte 7y ago
So you would have one data structure with 10 pointers to those 10 data structures you need and 10 times the functions? Id rather split up independent structures.
- amw-zero 7y ago
  Having a smaller amount of data structures makes the whole graph of code more comparable. Creating a bespoke data structure for 10 different elements of a problem means writing quite a lot of code just to orchestrate each individual structure, mostly due to creating custom APIs for accessing what is simple data underneath the hood. There’s a reason why equivalent Clojure code is much much shorter than comparable programs in other languages.

statictype 7y ago

There's a good bit about data structure-centric programming in The Art Of Unix Programming: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263 http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id... (Apologies for linking to esr but it's a good book)

CDSlice 7y ago
What's wrong with esr?
- japanoise 7y ago
  He's become somewhat controversial due to his worldview and political writings, which include climate change denial
  - gdy 7y ago
    And this has nothing to do with programming. Imagine Einstein alive and denying climate change. Would you apologize every time when you are referring to the theory of relativity? P.S. Sorry, if you don't agree with the apologising comment and were just informing about possible reasons.
    - kqr 7y ago
      Referring to relativity and linking to Einstein's personal web page are surely two different things, no?
      - gdy 7y ago
        Yes, but I don't think this invalidates my analogy
    - statictype 7y ago
      The theory of relativity is a much bigger contribution to society than TAOUP. The chapter I linked to was just a summary of ideas put forth by others - though admittedly written well. My problem with esr is more his arrogance and conceit than politics (which I also find distasteful)

billiam 7y ago

If I could say just one thing about programming to my kids, I would quote this.

rumanator 7y ago

> "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." It should be noted that the basic premise of Domain-Driven Design is that the basis of any software project is the data structure that models the problem domain, and thus the architecture of any software project starts by identifying that data structure. Once the data structure is identified then the remaining work consists of implementing operations to transform and/or CRUD that data structure.

discreteevent 7y ago
DDD is about modeling which is data and behaviour.
- rumanator 7y ago
  > DDD is about modeling which is data and behaviour. It really isn't. DDD is all about the domain model, not only how to synthesize the data structure that represents the problem domain (gather info from domain experts) but also how to design applications around it.

dTal 7y ago

Ah yes, the old insight. Fred Brooks: "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious."

combatentropy 7y ago
Yes, and here's one by Rob Pike, "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be selfevident. Data structures, not algorithms, are central to programming." --- https://www.lysator.liu.se/c/pikestyle.html https://www.lysator.liu.se/c/pikestyle.html I think I found all these quotes on SQLite's website, https://www.sqlite.org/appfileformat.html https://www.sqlite.org/appfileformat.html

victor106 7y ago

Can anyone point to some good resources that teach how to code around data and not the other way round?

combatentropy 7y ago
The Art of Unix Programming, by Eric Raymond, particularly chapter 9: http://www.catb.org/~esr/writings/taoup/html/generationchapter.html http://www.catb.org/~esr/writings/taoup/html/generationchapt...
rienbdj 7y ago
Switch to a language that emphasises functional programming (F#, Clojure, OCaml, etc) and it will happen naturally.
rramadass 7y ago
Surprisingly there is no one book AFAIK but techniques are spread across many books; The first thing is to understand FSMs and State Transition Tables using a simple two-dimensional array. Implementing a FSM using a while/ifthenelse code vs. Transition table dispatch will really drive home the idea behind data-driven programming. There is a nice explanation in Expert C Programming: Deep C secrets. SICP has a detailed chapter on data-driven programming. An old text by Standish; Data Structure Techniques. Also i remember seeing a lot of neat table based data-driven code in old Data Processing books using COBOL. Unfortunately i can't remember their names now. Just browse some of the old COBOL books in the library.

YeGoblynQueenne 7y ago

>> Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Tsk. Now I'll never know if I'm a good programmer. I do all my programming in Prolog and, in Prolog, data is code and code is data.

gameswithgo 7y ago

These are ideas echoed by some of the top people in the game development community as well. there is a nice book about these kinds of ideas: https://www.amazon.com/dp/1916478700 https://www.amazon.com/dp/1916478700

rstuart4133 7y ago

> I'm a huge proponent of designing your code around the data That same comment was made to a class I was in by a University Professor, only he didn't word it like that. He was discussing design methodologies and tools - I guess things like UML and his comment was he "preferred Jackson, because it revolved around the the data structures, and they changed less than the external requirements". (No, I have no idea what Jackson is either.) Over the years I have come to appreciate the core truth in that statement - data structures do indeed evolve slower than API's - far slower in fact. I have no doubt the key to git's success was after of years of experience of dealing with VCS systems Linux hated, he had an epiphany and came up with the fast and efficient data structure that captured the exact things he cared about, but left him the freedom to change the things that didn't matter (like how to store the diff's). Meanwhile others (hg, I'm looking at you) focused on the use cases and "API" (the command line interface in this case). The end result is git had a bad API, but you could not truly fuck it up because the underlying data structure did a wonderful job of representing a change history. Turns out hg's API wasn't perfect after all and it's found adapting difficult. Git's data structure has had hack upon hack tacked onto the side of it's UI, but still shines through as strong and as simple as ever. Data structures evolving much more slowly than API's does indeed give them the big advantage of being a solid rock base for futures design decisions. However they also have a big down side - if you decide that data structure is wrong it changes everything - including the API's. Tacking on a new function API on the other hand is drop dead easy, and usually backwards compatible. Linus's git was wildly successful only because he did something remarkably rare - got it right on the first attempt.

tonyarkles 7y ago
My memory is a little fuzzy, but I think Jackson was/is an XML serializer/deserializer that operates on POJOs (potentially with annotations). You define your data structures as Java objects, and Jackson converts them to XML for you. As opposed to other approaches where you define some schema in non-Java (maybe an XSD) and have your classes auto-generated for you.
lstamour 7y ago
Perhaps Jackson refers to https://en.wikipedia.org/wiki/Jackson_system_development https://en.wikipedia.org/wiki/Jackson_system_development

euske 7y ago

I remember that Richard Hipp (SQLite creator) once cited a bunch of similar quotes including the Linus' one. https://www.percona.com/sites/default/files/hipp%20sqlite%20percona-raleigh-20150212.pdf https://www.percona.com/sites/default/files/hipp%20sqlite%20... "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, The Mythical Man-Month, pp. 102-103

erikpukinskis 7y ago

Jonathan Blow is also talking about data-oriented programming as a basis for designing his Jai programming language.

amw-zero 7y ago
Data-oriented programming in games is a completely different concept though. It’s about designing your data to be able to be operated on very efficiently with modern computer hardware. It speeds up a lot of the number crunching that goes on in extremely fast game loops. The Linus comment is about designing your programs around a data representation that efficiently models your given problem.