Adam Sawicki

Lots of problems with this (https://xkcd.com/386/). "All shader languages are very similar to C". Even counting only mainstream shader languages, MSL is explicitly based on C++ and not C. There is a big difference. The non-mainstream shader languages will also be increasingly important, because who wants to be restricted to C dialects? "and have all the usual features associated with C save for pointers." MSL has strong built-in support for pointers. In addition, the future of Vulkan is increasingly pointer-friendly. HLSL compilation. This oversimplifies the story a bit. DXC only produces DXIL which is D3D12+ (and SPIR-V, so it can be used on Vulkan with little hassle). Older dialects (shader model 5) work on D3D11 as well, and can also be compiled offline, but that requires FXC [1] (FXC output, DXBC, can be used in D3D12, you just don't get as much access to newer features). "Some languages however encourage you not to compile shaders to an IR such as GLSL with OpenGL". This is no longer true as of OpenGL 4.6, which can use SPIR-V. On the other hand, it's probably best to think of OpenGL as a nearly obsolete API, only useful for compatibility. "The metallib compiler is available in the command line in any recent MacOS installation." It might also be worth pointing out that it is also now available on Windows. Thus, on a single Windows box it is possible to go from your source language to all major shader IL's. "GLSLang even supports compiling HLSL to SPIR-V, though…

That's probably more about GPUs cheating to be faster[1]. https://asawicki.info/news_1741_myths_about_floating-point_numbers [1]: Back in the day, CPU results could also vary based on path of execution; see tweet in article.

Game developers have been big on data oriented design (http://www.asawicki.info/news_1422_data-oriented_design_-_links_and_th… in recent years. It's funny, because data-oriented design examples tend to look like the original ("bad"?) array of values example in the blog post. Most of articles on DOD focus on performance, which seems of least concern to most software engineers, but I think it helps with understanding how your data is transformed and results in easier to understand code. I don't see how OOP is any more applicable to games than it is to other software. In a typical business or social CRUD app you can represent things in the same way you could in an OOP game. "Hero" becomes "User", "Monster" becomes "Friend", "Inventory" becomes "Account", etc. Otherwise I strongly agree with you. I think all software should be written in a more functional or data-oriented style. The biggest reason I'd write OOP code now is that many game designers and programmers, and most popular game engines and frameworks, prefer OOP.