31 ms·
Data-oriented design or why you might shoot yourself in the foot with OOP (2009)
- pulse7 5y agoOveruse/misuse of inheritance has triggered hatred of OOP among many software developers...
- brobdingnagians 5y agoYeah, I've loved classes and OOP for a long time, but lately I've been on a project that is going into more and more contortions and complexity to make everything fit a theoretical ideal. It's revived my interest in learning FP languages to avoid the arcane complexity that some people make out of OOP.
- lelag 5y agoI feel complexity creep is often inevitable regardless of the paradigm or technology you use. Programmers have varying levels of complexity they can handle and the systems generally naturally grow to match the complexity that the people that work on them can support. Experienced programmers will manage to keep that complexity creep under control for longer and smarter programmers will manage to keep working on complex systems that lesser peers would have no chance to understand. But eventually, unless the software has a very clear functional boundary which is often not the case for business software, software will start to become increasingly complex and dev velocity will slow down, quality will drop... I've seen this happening at all skill levels regardless of the languages and paradigms used.
- qayxc 5y ago> I feel complexity creep is often inevitable regardless of the paradigm or technology you use. This. I always love toy examples that look so nice, concise, and elegant. Until you add proper error-handling and corner cases that is; then all of a sudden it doesn't look half as concise, elegant, and beautiful anymore...
- MillenialMan 5y agoThe problem with inheritance-heavy OO is that complexity creep rapidly makes the code completely unreadable and incredibly hard to work with (and basically impossible to refactor), rather than just making it more branchy and complex.
- throwaway894345 5y agoI’ll go out on a limb and posit that there are virtually no valid uses of (implementation) inheritance. Perhaps one valid use is getting rid of delegation boilerplate (e.g., normally you would compose one object inside another but you want the outer object methods to delegate to the inner object methods but you don’t want to have to write N function definitions that just call the same methods on the inner object so instead your outer object inherits from your inner object). This problem is better solved by something like Go’s struct embedding since it doesn’t do anything more than this kind of automatic delegation. And if you get rid of inheritance, there is very little left to distinguish OOP from procedural programming like one would do in C or Go. And this is the semantic problem: no one really agrees on what OOP is and proponents will rebut any criticism with “that’s not true OOP”. Any definitions of OOP that aren’t easily assailable are also indistinguishable from other existing paradigms. Downvoters: i’m very interested in your opinions about why I’m wrong and specifically when you think inheritance is appropriate. Everyone says “there’s a time and a place!” but no one articulates when/where beyond cat/dog/animal toy examples.
- pulse7 5y agoSome cases where inheritance may be useful: UI widget libraries, graphical/drawing objects, (very similar) stream implementations. All this can of course be done without inheritance, but with inheritance it is much more elegant.
- throwaway894345 5y agoThank you for responding. I probably agree with the widget library example, but even here a widget library is just one way of implementing a GUI toolkit and perhaps it’s just the emergent result of an OOP-based approach (and consequently there are some really brutal tradeoffs in using a widget-based approach for a toolkit). To that point, with respect to general drawing libraries, I don’t think that OOP/inheritance yields a more elegant design than a reactive or intermediate mode approach (perhaps these terms only apply to GUI, but I imagine there are parallel terms for graphical APIs in general). Even though I concede narrowly on the widget GUI library point, these libraries are so very rare that I don’t think it’s a very compelling case for OOP proponents. I suspect they’d like to argue that there are appropriate uses for inheritance in most applications and not just the odd GUI library. Otherwise I don’t think it even merits first-class language support (why bother with an `extends` keyword if it’s only going to be useful in the rarest of libraries?).
- AdieuToLogic 5y ago> Overuse/misuse of inheritance has triggered hatred of OOP among many software developers... "It is not the tools we use that make us good, but rather how we employ them."[0] 0 - https://en.wiktionary.org/wiki/a_bad_workman_always_blames_his_tools https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h...
- orangepanda 5y agoBit of a nitpick - what's with the "[headline] or [jk, here's the real headline]" pattern? Pick one headline and use it.
- mssundaram 5y agoI think it's user submitted vs mods editing the title
- mssundaram 5y agoI see I misunderstood the question
- monocasa 5y agoIt's a meme from older media for instance "Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb"
- n4bz0r 5y agoYou have an article that falls under some broad category and an issue that the article aims to address. There are not too many ways to put these together. One of them is to use an established, recognisable pattern that makes an article look like it's from a newspaper or a book. I'm no expert in this area, but my suspicion is that recognisable title patterns bring higher viewership (or at least writers think so). Another thing with recognisable patterns is that they are being more firmly imprinted in the back of your head the more you see them. Perhaps it's not the views the author have pursued, but a mere usage of whatever seemingly suitable pattern popped out of his head first. My vomiting reflex kicks in when I see repeating title patterns too frequently, too. They make for an impression that the articles are shallow. It's up to you to use this as an indicator. I'm, for instance, rather fine with occasional false-positives.
- bob1029 5y agoYou can get some pretty unbelievable performance gains out of a single writer and arrays of structs. Bonus points if you figure out a way to have an array per type of struct pre-allocated with more elements than you will ever need. Even if you use a GC language you can almost eliminate collections with this approach.
- PicassoCTs 5y agoEven the array of structs is a non-ideal approach, as structs are usually viewed as a static collection of data. But if you look at the hot loop, it usually boils down to a funnel - not unlike a furnace. Lots of highly spacious needing raw materials are gathered and passed through, to be condensed into relatively small output. So the ideal structure is a sort of union-struct, that compresses the results down each step of the algo, keeping it all in cache, while keeping it slim..
- moldavi 5y agoWould love to hear more about that kind of compressing, how does that go?
- axilmar 5y agoThere is some middle ground between data-oriented design and OOP: just organize your objects in such a way that: a) objects of the same type occupy continuous blocks in memory, b) messages are passed to objects of the same type, then to objects of another type etc. In this way, you don't lose the advantages of encapsulation, inheritance, polymorphism etc but you also don't sacrifice cache coherence much. OOP does not enforce a 'random' memory access order, you can very will organize your objects in such a way that speed is not sacrificed much.
- bruce343434 5y ago> objects of the same type occupy continuous blocks in memory, Depending on the language, a single object may have a lot of overhead that adds up in an array. What you often see is one ArrayObject with arrays of properties, kind of like a transposition. A problem there is that in memory the arrays are of course laid out one after the other, which actually destroys cache locality if you need to access more than 1 property inside a loop (it will need to load back and forth to the different property arrays), so it's a somewhat dumb approach. But, at least it saves the overhead, so maybe not too bad. And in a high level interpreted language like php you likely weren't gonna get cache locality anyway. The point is to group all properties you are going to be accessing in a hot loop together in a small-ish array. C has structs for this, 0 overhead "entities" (although they may be padded to multiples of 4 bytes, so keep that in mind). You have compiler specific keywords to forego padding ("struct packing"), or maybe you're lucky and the data just fits exactly right. Either way, in such cases an array of structs is imo the most sane way to go. In fact, C++ offers classes and structs. In my opinion, struct should be used for entities like "weapon" or "car". CLASSES (or objects) should be unix-philosophy adhering miniprograms that do one task and do it well (oh hey, it's the single responsibility principle!). They way most programmers write OOP is a pretty convoluted way to model actual entities anyway. car.drive()? Oh? The car drives it self? No. agent.drive(car) should be the actual method. Agent, mind you, can be a driving AI, or a human driver, or whatever. Maybe the agent is a part of the car? In that case, use composition, not inheritance. (oh hey, entity component system!)
- skocznymroczny 5y ago
- talolard 5y agoIsn’t the middle ground writing custom allocators ? Allocators allocate blocks continuously and developers keep developing with standard OOP?
- PicassoCTs 5y agoImagine if compilers could detect a usescase for custom allocation by flag and speed up the OOP mess
- ratww 5y agoHow you allocate data is only half of the solution. The other half is also organising access patterns. In games, for example, DOD requires you to break up a hypothetical Update method into multiple methods that get called at different times (first do all the collision for all objects, then do all movement for all objects, then all rendering, etc). If you skip this step, you get the neatly organised memory but the same random access as before. Changing the data structure to the way presented in the article without changing the way you access it might even degrade your performance compared to what it was with normal OOP memory organisation.
- meheleventyone 5y agoTo echo your point which is why ECS isn’t data-oriented by default. Merely stuffing component data into flat arrays is not enough. You need as best as possible to have those arrays organised to fit access patterns. Which turns out is quite tricky. For example organising arrays by entity archetype (shape of entity from its components) or some other form of grouping.
- moldavi 5y agoI've never heard this, but it seems so obvious now! Just to be sure, can I get an example? Is it like: we want to group a spaceship's fuel tank and engine together, because theyll be accessed at the same time?
- 5y ago
- mytailorisrich 5y agoMany of the claimed advantages of "data-oriented design" and especially drawbacks of OOP in this article have nothing to do with data-oriented design or OOP... They are symptoms of bad design. For instance, good design, and in fact a key concept of OOP, will get you modularity. Especially "When you write code specifically to transform data, you end up with small functions, with very few dependencies on other parts of the code" is the objective of good OO design! Likewise for testing, I don't see how OOP is a problem if you've designed your system well and kept objects nicely encapsulated (likewise a badly-designed system will always be problematic). Cache utilization is neither here nor there. It all boils down to memory allocation and, again, choice of objects. Do data-oriented design to work out your dataflow, and then apply OO principles. A key issue is always to choose your objects 'wisely' and a data-oriented analysis will help towards that goal.
- ChrisMarshallNY 5y agoThis is one reason that I’m always skeptical of dogma. My only tool is a hammer… But that said, many new techniques (I clearly remember when OOP was the “new paradigm”) can offer radical improvements to the status quo. I use OOP all the time, but I also don’t do data processing engines. Most of what I do is GUI and/or device control/communication. For these types of things, OOP is still very much a mainstay, and probably always will be. I won’t sniff at DDD, but get really tired of being lectured about the way I do things; just because it doesn’t involve “buzzword du jour.” BTW: I remember a guy at a conference, telling me about exactly this problem with OOP, in the late 1980s. That was back when OOP was a relatively new kid on the block, and he was arguing against using it. He was correct, but it did not apply, in my use case. The massive improvement in complexity management and quality, offered by OOP, far outstripped any speed advantages of classic procedural programming (which is what he was arguing for).
- beigeoak 5y agoHow much time do you allocate to HN? I see you almost every day in the comments.
- mytailorisrich 5y ago
- radiospiel 5y agoThis article was "originally printed in the September 2009 issue of Game Developer." Any news since then?
- ratww 5y agoSince then, it has definitely become mainstream. For games, it kind of "merged" with Entity-Component-System architecture, which is used by lots of mainstream engines and is kind of popular these days. IMO, DOD+ECS is not only a good performance hack but also a great architectural pattern for organising game code in general, compared to more traditional techniques.
- alpanka 5y agoI think it is popular mainly _because_ how it can work in game engine editors (unity, UE, ...). You can't really do much OOP from the graphical editor but ECS is basically drag and drop
- worldsayshi 5y agoAs a react developer I find the OOP prevalence hard to tolerate when I try to learn unity. I'm really hoping that the Dots architecture can make things more enjoyable. I've tried it a bit but there's a lot to learn and from what I understand the APIs are not to be considered stable yet (?). Meanwhile I've discovered react-three-fiber which feels like the way I want to build 3d stuff.
- bregma 5y agoFor most game developers in the scene these days, DoD + ECS is the traditional technique. The dogma also requires chanting in unison how much better than OOP it is.
- meheleventyone 5y ago> Since then, it has definitely become mainstream. For games, it kind of "merged" with Entity-Component-System architecture, which is used by lots of mainstream engines and is kind of popular these days. This isn't really true, it's extremely popular on the Internet but much less so in commercial game development land. Data-oriented design on the other hand is extremely common as things need to run fast. But that's almost exclusively in the underlying engine rather than for gameplay code. Outside of that there are a lot of in-progress implementations in popular engines (likes DOTS in Unity), lots of very early open-source general game engine projects using them (like Bevy) and loads of open source implementations of which I believe one has actually shipped in a commercial game (EnTT in Minecraft Bedrock Edition). The other famous shipped game using an ECS was Overwatch.
- HugoDaniel 5y agoOne of the cool things in C is the space it leaves for the compiler to perform optimisations. Beyond what is observable, C compilers have almost free reins to do whatever they want, so long as the observable things are kept the same (output/memory address values, etc...). Data oriented design was a smart-kid anti-pattern thing back then, but I wonder if compilers have evolved enough so that it is useless nowadays? It is by all measures a useless optimization, since it can be placed hidden from the observable object properties. (i.e. who cares if it is an array of structs or a struct of arrays, so long as the vec3 is still a { x, y, z }?)
- hsn915 5y agoOne of the core principles (truths?) behind data oriented design is that compilers can never and will never be able to compensate for unoptimized data layouts.
- HugoDaniel 5y agobut they do, from the simplest automatic structure padding to the more complicated flow analysis and packing/vectorization
- cnity 5y agoHow could a compiler possibly optimize for cache hits in an array of structures? The only way it could do so is by disobeying the programmers intention with the described memory layout.
- HugoDaniel 5y agoHow can you? Do you know of a CPU that has specific instructions to handle cache allocations?
- cnity 5y agoYou simply take advantage of the fact that an entire cache line is fetched when reading from memory, and keep data that is frequently used together close to each other in memory.
- Bancakes 5y agoI still firmly believe the compiler should transpose your code from array-of-structs to struct-of-arrays, and optimise for temporal and spacial cache utilisation. After all, it is the tool that knows every CPU arch on the planet and can run millions of code transformations per second. This could be achieved with C/C++ compiler directives, then pass some PGO.
- ratww 5y agoTransposing the data structures is trivial, but transposing the code that access them might be impossible: inside your methods you're still doing random access. You'd have to not only break your "Update" method into many, but also call those broken parts separately.
- astrange 5y agoRearranging memory accesses is very difficult due to usually not having enough info to do the alias analysis. Also, C/C++ compilers really don't know that much about their target architectures, especially not their memory performance - they barely do scheduling anymore since it's better to let the CPU reorder it.
- FpUser 5y agoI've been "shooting myself in the foot" for 40 years already to, thank you. OOP, FP, Data Oriented, insert your favorite here are just a friggin' tools in the arsenal and all are fine when used appropriately. One does not negate the other. You just do not use the approach used when writing firmware for low power microcontroller for writing Solidworks. And it is ok to mix and match if type of software to be written benefits. There are no silver bullets in this world and one must learn what to use and when, Trying to convince people to stick to just one is a great disservice and looks more like a religious propaganda: if I do it this way the others should do the same disregarding. Oh and btw OOP can be cache friendly as well. Nobody forces one to organize internal data representation in any particular way.
- gnuvince 5y ago> Oh and btw OOP can be cache friendly as well. Nobody forces one to organize internal data representation in any particular way. This is part of the argument of the article, that although nothing forces you to, there is a culture that strongly suggests a way of doing things.
- FpUser 5y ago>"there is a culture that strongly suggests a way of doing things" Sorry but I would not take "strong suggestions" coming from prophets with vested interests for granted. Or if said culture comes from generic ignorance / lack of knowledge.
- dgb23 5y agoOne thing that is interesting about this, is that people sometimes end up building an (incomplete) implementation of relational algebra to achieve this, where any given system in the game logic pipeline might join over multiple components.
- epage 5y agoThats what made ECS click for me: its an in-memory, natively typed database with a feedback loop.
- davedx 5y agoI was expecting to see some example code, or some actual performance metrics to show why data-oriented design is better. I actually have written a game that was pure functional style with a single giant state object for the game data and it worked well for me. But I'd want to see some evidence for this approach before changing the entire architecture of my game.
- meheleventyone 5y agoThis graph made the rounds on Twitter last week and I think encapsulates the answer really well: https://twitter.com/eric81766/status/1407393532562841607 https://twitter.com/eric81766/status/1407393532562841607 Most games won’t benefit. Most AAA games won’t benefit for their gameplay code and are otherwise very data-oriented already.
- davedx 5y agoECS isn’t the same thing as data-oriented programming is it? I’ve worked on AAA games and this whole discussion is quite confusing, lol.
- meheleventyone 5y agoNope! If you want a concrete example I’d recommend looking at the Unity DOTS stuff which is their data-oriented stack and does include an ECS as part of it.
- urthor 5y agoPeople forget what the intent of OOP originally was. OOP was envisioned as a way to manage software projects with many contributors at a time when we didn't have half the tools for hiding context that we do now. Micro-services and micro-kernels are far far far more prevalent these days. Garbage collection was also far less of a thing in that era, as all programmers were squeezing every last iota out of the hardware. Hence rogue pointers were far more of a risk. Multi-core? Haha. I know this is not particularly relevant to the original article, but if you don't know the history and the intent behind why something exists, you are reasonably likely to misapply it. Most of the mistakes of OOP are from a lack of understanding of why things got invented in the first place.
- beders 5y agoThe original intent had nothing to do with "many contributors". The main ideas: encapsulation, message passing and late binding i.e. dynamic binding.
- Zababa 5y agoYou're talking about solutions when they were talking about problems. What problems does encapsulation, message passing and late binding solve?
- BoiledCabbage 5y agoAlso, the article does a really poor job of describing any drawbacks of Data Oriented Design. It's a real pet-peeve of mine. > Drawbacks of Data-Oriented Design Data-oriented design is not the silver bullet to all the problems in game development. Ok, they don't view it as a silver bullet. This seems promising for an evenhanded discussion. I'm curious what the author thinks the drawbacks are. > The main problem with data-oriented design is that it’s different from what most programmers are used to or learned in school. So the first drawback is that nobody knows your silver-bullet? That's a cop out. > Also, because it’s a different approach, it can be challenging to interface with existing code, written in a more OOP or procedural way. And the second drawback is that code was written without using your silver-bullet? Seriously? If the only two things you believe are drawbacks about your tech are that not enough people know it, and not enough people are using it then it's not an even handed discussion of your tech. Discuss the actual trade-offs you've learned from using it. Not nonsense like nobody knows how wonderful it is, nor is using it. And that's coming from someone who agrees that OOP has huge flaws and with the most common applications of inheritance creates many flawed program architectures.
- lmilcin 5y agoSigh... This again. I am going to repeat this for what seems like a ten thousandth time. "OOP is a tool to solve a particular type of problem. It is your responsibility to know the tool, to understand its strengths and weaknesses and when it is applicable and when it is not. If the tool does not work it is not the tool that is faulty, it is you who are the problem -- by using the tool in a wrong situation or incorrectly." In particular I detest "we are OOP shop" type of approach. This immediately advertises they have absolutely no idea how to use stuff -- by saying you know only one tool and sure you are going to use it to solve every kind of problem. Those languages that were supposed to be "everything is an object" like Java? Now are learning that maybe that is not the most sound approach and trying to evolve to allow other paradigms under one roof.
- throwaway894345 5y agoThis is boilerplate that can be used to defend any idea. First of all, the article is trying to explain a domain for which OOP is not well-suited. Secondly, it’s unhelpful to write-off this article with “there are places for which OOP is well-suited” without any specifics about when it is the better approach, especially how it compares and contrasts with other approaches.
- lmilcin 5y agoWhat I object to is this "OOP is good / bad" type of approach. OOP is neither good nor bad. What is good or bad is your selection of technique for the problem at hand. That's the same misguided discussion as on whether strong typing is good or bad. It is neither. What you want to select depends on the kind of project you are trying to use it for. Also, just because this template can be used for practically any idea doesn't make it less valid. Greatest laws tend to have universal applicability.
- throwaway894345 5y ago> Also, just because this template can be used for practically any idea doesn't make it less valid. Greatest laws tend to have universal applicability. I don’t think it’s invalid, but useless. “There’s a time and a place!” is not very enlightening. It doesn’t help anyone understand when to use it nor does it indicate how frequently it is helpful (e.g., in every application or only very rarely?). > That's the same misguided discussion as on whether strong typing is good or bad. It is neither. What you want to select depends on the kind of project you are trying to use it for. Isn’t this a straw man? TFA illustrates in detail the problems with OOP in game development (e.g., performance), so presumably for applications that care about those things, then you have an idea about when it should be used. This is far more helpful than “but there’s a time and a place!” protestation or the “but OOP is neither good nor bad!” protestation nor for that matter the “But that’s not true OOP” protestation. TFA substantially criticized OOP—if we can’t rebut the criticism substantially, instead resorting to pithy sayings, then maybe we should consider the criticism more carefully?
- ferdowsi 5y agoIn all my experience with OOP, it's always been inheritance that is the root of all evil. Rust and Go got this correct by having class-like objects with no inheritance, to achieve encapsulation without fragility. Unfortunately, all the other languages that included inheritance in their design can't wish it away. Devs are going to keep reaching for inheritance as the closest, most comfortable abstraction.
- Zababa 5y ago> In all my experience with OOP, it's always been inheritance that is the root of all evil. I have this "theory" in the back of my head that trees are usually the wrong things to model thing in life but it's what come to us naturally. For example, a blog with categories and sub-catogories for articles (a tree, inheritence) can often describe the content better by using tags (a graph, composition). I think that's because trees are easy to deal with and understand, but graphs are more "open" with what you can do.
- shadowgovt 5y agoSomething I really enjoy about golang was the design decision to make structured data stay separate from function, but then provide a simple mechanism for defining functions that worked in the context of structured data. It feels like a good split between the two desired uses for structured data... On the one hand, it's easy to encapsulate the data for common use case, and on the other hand I can generally trust that if I need to bit-bash a data structure (i.e. use only a piece of it, or introspect it, or serialize it), I can do that with a minimum of care as to ny object-like metadata it might be carrying.
- 0xbkt 5y agoWhat is “flat” codebase, if you don't mind? Is it opposite to the hadouken-style nested code?
- stephc_int13 5y agoIn my opinion, the most important aspect of data-oriented design is to always consider collections instead of so-called "objects". It is then logical to optimize for access pattern instead of the processing of a single entity.
- freddealmeida 5y agoI always hated OOP. thank god for this.
- menotyou 5y agoMe too. Lot's of superfluous concepts called "abstractions" to make simple things complex. Interestingly all discussions about other paradigms on HN end very fast in "Oh, I can solve this somehow with [put in your favorite design pattern in here]" (Big deal, both paradigms are obviously turing complete). "Design Pattern" was for me always short for "Complex workaround for a problem you would not have if you wouldn't use object oriented paradigm". But more generally, OOP is for developers whose mental model of the world is categorizing things into object hierarchies. For them it is the most intuitive approach to model the world. For me this is as counter-intuitive as it can be. My mental model of the world just does not work like that.
- jayd16 5y agoWhy are we always so dogmatic? Struct of Arrays is a great pattern if you need the speed and have enough items to make it worth it. Otherwise just use OOP. Are you going to make an array of singleton data? No, of course not. >How many places in the code did you have only one of something? One socket, one host, one pool, and assuming a single player game, there are a lot of ones... Just relax and use the strengths of both patterns.
- moth-fuzz 5y agoHonestly I find ECS dogmatic and difficult. Data oriented design as a general practice is a good thing, but there’s layers to all things. OOP is a very broad category of practices and designs, and ECS usually refers to one specific architecture. The specific architecture in question tends to be full of soft dependencies - most ECSes don’t allow you to simply store a piece of data without opting in to all systems matching the data type executing arbitrary code on it. So much for separation of data and behaviour. No, now they’re even More dependent than they are in the usual OOP sense and you might not even know it. Furthermore, usually when you want to think about in-game entities, you want to look at a single class. Now all entities’ data is split into numerous components and all entities’ behaviour is split into numerous systems and you don’t know frame by frame how they’re gonna interact, provided you even know about all systems in the first place. It’s total spaghetti code. I’m much more inclined lately towards a shallow actor system . If I want to know how player’s behaviour functions, I need only look at player.cpp and nothing else. Then, to reap the benefits of data oriented design, certain objects can use a certain allocation scheme that makes sense for the object in question. In the general sense, any Component<T> can just have a vector<T> or an unordered_map<T> of all components and the memory access is abstracted away without it being detrimental. That’s C++’s whole deal actually, zero cost abstractions. I wouldn’t call an entire paradigm shift in which one rewrites everything from memory allocation all the way up to ‘use WASD to move’ zero-cost in any sense. In C++ it is trivial to overload new, or derive from some class which does, or to write a custom allocator, and frankly there is zero need for the same person who’s writing ‘use WASD to move’ to know about memory management.
- lamontcg 5y agoAfter studying ECS for all of a week, I was left wondering if there wasn't a way to reintroduce strong typing to an ECS system (without reintroducing all the problems of inheritance). So you have a player_entity factory that ensures that a player_entity only wrap entities that are actually players. Then you can pass that around to strongly typed functions, but keep the overall design reasonably inheritance-free so it was more like rust/go's strong typing systems.
- jms55 5y ago
- SonOfThePlower 5y agoLooks like Fortran programmers have been doing data-oriented design since forever.
- ncmncm 5y agoThe great mistake is to believe there is something useful called "Object-oriented", or "Data-oriented", or "Functional", or what-have-you-oriented programming. Carpenters don't learn "hammer-oriented" building; or "saw-oriented", "screwdriver-oriented", "chisel-oriented", or "glue-oriented". They learn to use hammers, saws, screwdrivers, chisels, and glue, and use them all at different times, sometimes one more than others. Machinists don't learn "lathe-oriented", "drill-oriented", "mold-oriented", or "welding-oriented" fabrication. They do all or any of them strictly according to what they are making, and what they are making it out of. It is as utterly stupid to design a whole language around one of them as it would be for a carpenter to try to run a screwdrivering business. A language is useful exactly to the degree that it enables building whatever you might be called upon to build. That is not to say any generally useful language is equally good for any purpose. Wood is better for some products, metal for others. A metal violin would be weird, a wooden gun action would be stupid. But violins often have metal bits and guns often have wood stocks.
- marviel 5y agoI don't have a substantive response except to thank you for giving me a helpful analogy in future discussions on the topic.
- teakettle42 5y ago> The great mistake is to believe there is something useful called … "Functional", or what-have-you-oriented programming. It’s a remarkably substantial mistake — “the great mistake”, even — to blithely discard a concept so fundamental to computer science and programming language theory that we literally could not progress in the field without it. You may as well be an earth-bound carpenter denying the existence of “gravity-oriented design”.
- ncmncm 5y agoYet, we did progress without it. Learning a program organization style is helpful for beginners, if the toy problems they get are more easily solved using the style. But you progress, ultimately, by transcending it. A mature programmer mixes elements freely without labels. Crawling-oriented locomotion is fine for babies. Adults walk, run, swim, drive, pilot, ride, sometimes even crawl. Learning to run does not make you worse at crawling, or make you run when you should crawl.
- cryptica 5y agoCan someone please point me to an example of a well-designed (modular, maintainable) FP project (e.g. on GitHub)? I've only had negative experiences so far and I can't imagine how to use FP in a modular way (high cohesion, loose coupling) so I'd like some examples to look at. A simple game would be nice.
- dang 5y agoDiscussed at the time: Data-Oriented Design (Why You Might Be Shooting Yourself in The Foot With OOP) - https://news.ycombinator.com/item?id=1004569 https://news.ycombinator.com/item?id=1004569 - Dec 2009 (28 comments)
- tabtab 5y agoSomewhat related: it's time to toss out file trees as our primary module management technique: https://news.ycombinator.com/item?id=25347043 https://news.ycombinator.com/item?id=25347043 We've outgrown file trees.
- mamcx 5y agoWhat I wish to know is how apply this in a normal CRUD-like scenario against a db. It truly will help for, like, a shopping cart app?