7 ms·
This might be an unpopular opinion, but I feel like these DOD posts should always mention that the ideas are borne out of experience in game engine development
by jebarker 3y ago
This might be an unpopular opinion, but I feel like these DOD posts should always mention that the ideas are borne out of experience in game engine development and don't necessarily easily apply in other domains.
In some general sense the principles are applicable everywhere. But trying to actually apply them in some domains is really difficult. For example, I work on developing a large scale ML training framework and I haven't seen an example where avoiding the use of objects and inheritance leads to better code. Having said that, the principles certainly apply lower down the stack when talking about implementing the GPU kernels etc on the hot path.
- js6i 3y agoThat would be fair if OO/FP posts had always mentioned that the ideas were borne out of academia and don't necessarily easily apply in other domains, but that ship has sailed..
- jebarker 3y agoWhy can't we do both? i.e. give an honest account of the pros and cons of different approaches rather than treating them like dogma
- officialchicken 3y agoThe "methodology industry-complex" thrives on consultants, authors, certification experts, courseware, etc. By definition it is funded by those who literally do not know and need/looking for something better. So while we can be honest, there is a lot of money preventing that discussion from ever happening.
- rewmie 3y ago> That would be fair if OO/FP posts had always mentioned that the ideas were borne out of academia and don't necessarily easily apply in other domains, but that ship has sailed.. OO has been widely adopted because it maps almost perfectly to most domains. FP is starting to be adopted because first class support from programming languages and frameworks lowered the barrier to entry by eliminating the need to implement all primitives and infrastructure. FP is being adopted because it maps almost perfectly to some domains. What's your point, exactly?
- loup-vaillant 3y agoNot sure if you’re being serious here: the whole point of academia is to eventually be useful to the outside world. Something that applies to academia and nowhere else is kind of useless. The very reason we take science so seriously comes from how it helped us completely transform the world. So the idea that something would only (easily) apply to academia because it was born out of it feels kind of ridiculous to be honest.
- nightski 3y agoI feel the biggest weakness of PyTorch is that everything is an object with inheritance. It makes no sense that ReLu is a class for example. Seems like ML could take a few hints.
- vore 3y agoWell, PyTorch uses classes more as a declarative way to construct your neural networks. It doesn’t get more data-oriented than pushing thousands of tensors through your GPU!
- hexane360 3y agoDeclarative vs. procedural is orthogonal to data oriented vs. object oriented. The functional way to make a declarative interface would be to have a single type, `Expression`, and all operators take expressions and return expressions. However, I would argue the declarative vs. procedural decision is much more important to the resulting code structure then whether you use a single object type or multiple object types with inheritance.
- gloryjulio 3y agoThe problem is that with python oop, the class is ur type. Therefore it comes with all the oop baggages. If u squint enough and avoid those baggages and only leverage the type system(hint), then it's kinda usable. U don't have much choices anyway.
- vore 3y agoIt's complicated because PyTorch also uses class syntax to allow you to introspect the various blocks in your modules. It's a bit of a kludge, but composing it strictly out of Expressions would remove that introspection capability.
- jebarker 3y agoI agree that often people choose to use the object versions unnecessary, but many operations (including relu) have functional versions: https://pytorch.org/docs/stable/generated/torch.nn.functional.relu.html https://pytorch.org/docs/stable/generated/torch.nn.functiona...
- vkazanov 3y agoWouldn't it be nice if people would always follow the serious whitepaper structure: abstract, summary, conclusion, measurement... But this wouldn't work for programming language ideologies. Not for the OOP proponents, anyway. The DOD crowd can at least demostrate how CPU love blasting through data layed out in arrays. The FP crowd can least explain how the languages can be formalised. PS ML is the most natural application of dod principles, no?
- jebarker 3y ago> ML is the most natural application of dod principles, no? Yes, the principles are helpful and natural in implementing the code that will execute the ML model pass with no unnecessary overhead. But in terms of writing the code that configures and defines a model and the pre- + post-processing, and to some extent dataloaders, it's natural to use objects + inheritance. Now I don't actually think using objects and inheritance are antithetical to DOD but it seems that DOD often gets presented that way.
- anonymoushn 3y agoThat sounds totally fine. There's no reason to care about the layout of data that your computer spends almost no time working on or the pointers that it chases dozens of times total.
- discreteevent 3y agoNot everything that matters can be measured.
- xiasongh 3y agoI feel that DOD is about performance, not understandability and usability, so it makes sense that the frontend of a framework, where usability is priority, doesn't benefit, and the backend and hot path does.
- johnnyworker 3y agoUsability can only ever be as good as performance allows it. I don't care where the buttons are when it takes 5 seconds before they show up, or how pretty font is if the scrolling is stuttering, and so on. From the user perspective, it really makes no difference if the same UI was hand coded in assembly or in something much higher level that is still fast because it doesn't work against the CPU, RAM, storage and other things.
- eikenberry 3y agoThere are at least 2 end users for any code, one who uses the product and one who has to work with the code in the future. The second one will care.
- morelisp 3y agoFuck the second guy, their entire job is to serve the first. And having been that second guy a large fraction of my career, fuck the original author’s OO GoF hexagonal Clean Code too.
- loup-vaillant 3y agoThis comment has a point: there are much fewer developers than there are users, and our moral weight is proportionally tiny.
- fulafel 3y agoI think the long tail of user bases makes a big difference here. Most programs have few users. Most devs work on programs with few users.
- flohofwoe 3y ago> ...where avoiding the use of objects and inheritance leads to better code... DOD isn't about "better code" but strictly about "faster code" by letting real-world hardware restrictions dictate how code accesses data (the way I wrote that it may sound like it's a bad thing, but it's really not) - writing software that doesn't fight the hardware it runs on can lead to simpler and easier to maintain code, but that's not guaranteed.