"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 (1975)<p>via "Objects have not failed" -- Guy Steele, <a href="http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html" rel="nofollow">http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html</a>
Or, start from the user experience.<p>Both are good places to start, and both should be given serious consideration early in the project.<p>Code is usually the worst place to start. If you do need code early on, I think it's fine to write it as quickly as possible, even ignoring edge cases and simplifying algorithms.<p>If you have good data structure design (and understand the invariants) and you understand the problem space well from a functional standpoint (including functional edge cases), you can get the code into shape later. The bugs you encounter will be mostly the trivial kind.<p>But if you misunderstand the user experience, or the data structures are a mess, then it's difficult to recover.<p>That's one of the reasons SQL databases are so great: they help you get the data design up and going quickly, and will enforce a lot of your invariants (through schema normalization, PK/FKs, and CHECK constraints). If anything goes wrong, rollback returns you to a known-good state.<p>I don't know anything equivalent at the user experience level, though.
Ah yes, takes me back to the time when 'Data Analyst' was an actual profession, and organizations planned their workloads in order to place an appropriate order for 'enough' IBM hardware and dasd. Back then, during the first wave of business automation via computer, the processes being automated were so well defined, this level of understanding was acheivable; when you have rooms full of clerks calculating monthly payroll, you KNOW what the data is.<p>In so many domains today, you don't know, and the business is forgiving enough (or amateur enough?) that THEY don't even fully understand their processes.
Code samples or GTFO. No seriously: an article that brings up messy real-world OO code and then handwaves it away with "just use FUNCTIONS, yo!" and some box-and-arrow diagrams is useless and borderline unhelpful. Something like:<p><a href="http://prog21.dadgum.com/37.html" rel="nofollow">http://prog21.dadgum.com/37.html</a><p>is, IMO, more valuable in the discussion. It points out the tradeoffs explicitly: pure functions mean (in this case) immutable data, which means more-complex data structures - which means the OPPOSITE of the micro-optimization stuff this article closes with.<p>It's also worth noting that if you're fussing about the cache efficiency of code you haven't written yet, STOP. JUST STOP. Write the code and MEASURE IT.
Does the conclusion boil down to "use functional programming"? The author doesn't specify the way data or functions are encapsulated in the final figure. But my gut reaction is that this describes FP better than OO or any other paradigm.
It's interesting that he's advocating this on games.<p>I've been annoyed at most OOP codebases, but conceded that games and GUIs were the canonical applications of OOP. Perhaps you could say that highly stateful apps running on a single machine can use state encapsulated in objects.<p>In contrast, for web UIs and their "big data" back ends, I believe you also want to use a data-oriented approach, rather than a code-oriented approach (or at least this is the style that my code has converged upon). You don't need to wrap everything up in objects all the time when you're really just passing strings through the network and doing light processing. And when you're not even using a type-safe language to begin with.<p>But he's advocating the same style on games, just with structs and functions rather than buffers and processes. This makes me think OOP is more of a mistake, although I will admit that I use objects as modules now (a longer conversation, but the idea is to instantiate almost all your objects at startup, and not allocate during normal program flow).<p>I've long thought there was this interesting historical oddity in that we came up with languages in the 90's and designed them for GUIs, but we're using them the 2010's for web and server programming. Then you get web apps that are a mess of misleading objects, when really the architecture is stateless (or stored in a database, which is not programmable using your language).
When I took my first APL class the prof drilled into our heads to focus on data representation before writing any code. Over the years and across a dozen languages or so this has proven to perhaps have been the most valuable thing I learned in CS. I lost count of how many problems I've seen go from difficult to manageable and even simple to solve by devoting more effort towards finding the best way to represent the data or the problem than simply taking things as presented and writing code right away.
Hey there! First off, beautifully written. Thank you for a lot of food for thought.<p>Second--I can't help but think of the notion of mechanical sympathy.[1] Very useful.<p>Finally, I want to put on [2] but my wit is eluding me.<p>[1] <a href="http://martinfowler.com/articles/lmax.html" rel="nofollow">http://martinfowler.com/articles/lmax.html</a><p>[2] <a href="https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf" rel="nofollow">https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf</a>
I feel the author has chosen poor examples for illustrating 'bad code'. Does he really think so little of the id software team that they aren't aware of these things? There's no mention of the fact that in the real world, all the patterns and <i>weird tricks</i> there are won't save you from compromising on a perfect design to get stuff done & shipped.
This idea of data-oriented design has been influencing much of how I write code and approach problems these days. In dynamic GC'd languages it's all too easy to trick yourself into believing that all problems are unbounded. However most problems are not. And doing the math ahead of time allows you to write the minimal amount of code to do the transformation required.<p>It's really cool.
I think the author has some great points to begin with, but the finale is a little.. lacklustre.<p>It's all well and good to say we can separate process from objects, but in reality it's not uncommon to require instantiating new objects/components dynamically or changing structure in ways that don't map so easily to the input->process->output diagram shown.<p>I also think that maintaining code and building up testable modules was one of the niceties of OOP ahead of all the inheritance spaghettis that started happening in many poorly-OOPed projects.<p>Kudos though to the author for showcasing his first few points by commenting on Doom's code- you don't often see that.
The author had some pretty good points there.
But I have to wonder if these are somewhat cherry picked.<p>I mean, where is the other side of the coin? Where do the advocated philosophies break?<p>Has any big project been built using that approach? With no problems at all?
Two relevant blasts from my past:<p>"Algorithms + Data Structures = Programs" by Wirth<p>The Jackson Design Methodology, which essentially said that the structure of the data will produce the structure of the program.
Couldn't agree more. Whatever program we write, it is manipulating and transforming data. If our code is revolving around data, it couldn't make more sense to formulate data before actually start code which is supposed to work on that data.
I used to think I can communicate the architecture (including code) of an entire website using just the tables. And a good enough developer+designer could turn the schema into a website.
I so wish c++ would let me code like this without getting in the way with it's OOishness. Recent gripes:<p>- got a few bit flags per struct, need to know if there is at least one instance with the flag set (a counter per flag). I cannot bit-pack the flags without duplicating the flag getter/setter/destructor code.<p>- no way to declare static linkage funcions as friends (the linkage is forced to external). so i need to expose types that are implementation detail in public header.<p>would be nice if c++ could get some RAD-slanted design work, instead of trying to get all RUSTy
> The boss comes in and says "Hey, change of plans. The player is now a car."<p>Stupid decision-making is why I will never work in games. With regular coding, you can iterate towards the domain and so long as you keep your wits about you and never make the same mistake twice, never be subjected to such a demand.<p>In the arts, everything's got to hew to some asshole's vision. The people building it can never really know what's going on in his head and the asshole never understands how much work it is to change things to fit the evolving vision. Killer features on games are rarely evident from day one, game shops seem to always wind up looking like sausage factories.