3 ms·

The losing minority, sure, but the wrong side? AAA games? Linux? Rust? Vulkan? WebASM? Yes, some abstraction is beneficial. But too much abstraction leaves you

The losing minority, sure, but the wrong side? AAA games? Linux? Rust? Vulkan? WebASM? Yes, some abstraction is beneficial. But too much abstraction leaves you with, you know, the decrepit state of modern software. Abstraction as you actually see it isn't letting us solve "progressively harder problems", it's letting GMail take up more RAM than my OS does from boot. Meanwhile most of the really interesting problems are still done in fairly primitive languages.

stouset 9y ago
> AAA games? You mean the ones built on a handful of abstracted 3D engines like Unreal, Source, id Tech, CryEngine, Unity, etc? > Linux You mean the operating system that abstracts away from us things like filesystems, hardware access, shared memory, time sharing, networking protocols, access control, multicore processors, etc.? > Rust You mean the programming language that adds a new abstraction of "borrowing and ownership" to help simplify the confusing existing abstractions of memory management and data race detection? > Vulkan You mean the API that abstracts away parallel computation on graphics hardware, upon which they intend for dedicate graphics abstractions like OpenGL and WebASM to be abstracted? > WebASM? You mean the API that abstracts away running low-level machine code — not on your own machine, but sandboxed on remote machines via web browsers. > Meanwhile most of the really interesting problems are still done in fairly primitive languages. Do you want to take a guess why I'll argue that you consider the obscenely complicated task of "delivering secure, multiuser, interactive applications with offline persistent data storage to hundreds of thousands of remote clients" a non-interesting problem? It's only because of the incredibly successful and complex network of abstractions that are Ethernet, IPv4, TCP, DNS, TLS, HTTP, HTML, JavaScript, SQL, graphical image formats, web browsers, database servers, caches, switched networks, load balancers, and so on that these kinds of achievements that would have been considered monumental even thirty years ago are not "really interesting problems" today. Abstraction has allowed us to break apart the component parts of this incredibly complicated problem into small, independent, coordinating layers. The fact that you think that something like delivering web applications is a non-interesting problem practically makes my argument for abstraction all by itself.
- jstimpfle 9y ago
  Your points are good, but parent's comment has mostly been about OO which is not necessarily a successful abstraction in these areas. AAA or kernels games are traditionally written on a low level, i.e. C with maybe some convenience C++. Especially for memory management there just isn't a good one-size-fits-all abstraction. Look for AAA games or kernels in Java. Another problem of OO for high-performance or complex architecture is the mindset it inflicts upon developers. It motivates decomposition in "independent" objects, while this is just not possible. You have to think about processes in the large, about dataflows, about how to structure information and how to handle cross-cutting concerns, etc. Getting at these problems with an OO mindset leads right into desaster. Look up data-oriented programming. Look how a game engine is architected. There are lots of memory and resource managers, for example. But nobody would think of a Vertex as an individual "object". Or break his head how to design a character object, when related data really has to sit all over the project (character world position and state, associated 3d resources, sound resources, ....). >> Rust > You mean the programming language that adds a new abstraction of "borrowing and ownership" to help simplify the confusing existing abstractions of memory management and data race detection? So far, it's just an attempt to enable mindless OO-style programming without inflicting a runtime, but I guess with very limiting mechanics. And it inflicts a huge syntactic overhead. I predict the applications of Rust are very limited. Game programmers are usually (as far as I know) not very busy with memory management problems.
- Veedrac 9y ago
  I'm certainly not arguing for no abstraction! Use as much as you need; nobody argues with that. These are just places where the bar for "need" isn't an afterthought, and effort is taken to keep abstractions minimal to avoid their cost. > Ethernet, IPv4, TCP, DNS, TLS, graphical image formats, switched networks, load balancers These abstractions exists because they are necessary. They are a bit of a mess, admittedly, but invested people have worked hard to make what they were given as small a mess as they can manage, and what is left exists because it has to historically. When your packets get pulled through hardware specifically designed to do exactly that, the abstraction almost ceases to be. (Disclaimer: not a network person) > HTTP, HTML, JavaScript These abstractions are why 12 billion instructions per second per core counts as slow now.

stouset 9y ago

> AAA games? You mean the ones built on a handful of abstracted 3D engines like Unreal, Source, id Tech, CryEngine, Unity, etc? > Linux You mean the operating system that abstracts away from us things like filesystems, hardware access, shared memory, time sharing, networking protocols, access control, multicore processors, etc.? > Rust You mean the programming language that adds a new abstraction of "borrowing and ownership" to help simplify the confusing existing abstractions of memory management and data race detection? > Vulkan You mean the API that abstracts away parallel computation on graphics hardware, upon which they intend for dedicate graphics abstractions like OpenGL and WebASM to be abstracted? > WebASM? You mean the API that abstracts away running low-level machine code — not on your own machine, but sandboxed on remote machines via web browsers. > Meanwhile most of the really interesting problems are still done in fairly primitive languages. Do you want to take a guess why I'll argue that you consider the obscenely complicated task of "delivering secure, multiuser, interactive applications with offline persistent data storage to hundreds of thousands of remote clients" a non-interesting problem? It's only because of the incredibly successful and complex network of abstractions that are Ethernet, IPv4, TCP, DNS, TLS, HTTP, HTML, JavaScript, SQL, graphical image formats, web browsers, database servers, caches, switched networks, load balancers, and so on that these kinds of achievements that would have been considered monumental even thirty years ago are not "really interesting problems" today. Abstraction has allowed us to break apart the component parts of this incredibly complicated problem into small, independent, coordinating layers. The fact that you think that something like delivering web applications is a non-interesting problem practically makes my argument for abstraction all by itself.

jstimpfle 9y ago
Your points are good, but parent's comment has mostly been about OO which is not necessarily a successful abstraction in these areas. AAA or kernels games are traditionally written on a low level, i.e. C with maybe some convenience C++. Especially for memory management there just isn't a good one-size-fits-all abstraction. Look for AAA games or kernels in Java. Another problem of OO for high-performance or complex architecture is the mindset it inflicts upon developers. It motivates decomposition in "independent" objects, while this is just not possible. You have to think about processes in the large, about dataflows, about how to structure information and how to handle cross-cutting concerns, etc. Getting at these problems with an OO mindset leads right into desaster. Look up data-oriented programming. Look how a game engine is architected. There are lots of memory and resource managers, for example. But nobody would think of a Vertex as an individual "object". Or break his head how to design a character object, when related data really has to sit all over the project (character world position and state, associated 3d resources, sound resources, ....). >> Rust > You mean the programming language that adds a new abstraction of "borrowing and ownership" to help simplify the confusing existing abstractions of memory management and data race detection? So far, it's just an attempt to enable mindless OO-style programming without inflicting a runtime, but I guess with very limiting mechanics. And it inflicts a huge syntactic overhead. I predict the applications of Rust are very limited. Game programmers are usually (as far as I know) not very busy with memory management problems.
Veedrac 9y ago
I'm certainly not arguing for no abstraction! Use as much as you need; nobody argues with that. These are just places where the bar for "need" isn't an afterthought, and effort is taken to keep abstractions minimal to avoid their cost. > Ethernet, IPv4, TCP, DNS, TLS, graphical image formats, switched networks, load balancers These abstractions exists because they are necessary. They are a bit of a mess, admittedly, but invested people have worked hard to make what they were given as small a mess as they can manage, and what is left exists because it has to historically. When your packets get pulled through hardware specifically designed to do exactly that, the abstraction almost ceases to be. (Disclaimer: not a network person) > HTTP, HTML, JavaScript These abstractions are why 12 billion instructions per second per core counts as slow now.