points by whatthejesus 2 days ago | 0 comments
In real life there’s lots of bugs around and difficult to read error messages.
Re. the boilerplate just have students clone a pre-fabbed repo with the boilerplate handled for them.
The real question should be whether you want students to know how to program in a low programming language or not. Whether they should see what the reality of programming is or not.
If they can’t program in C/C++ and debug the error messages how are they going to survive in the wild? I guess they’ll use an LLM.
[–] flohofwoe 2 days ago
[–] Pannoniae 2 days ago
small nit, that's not true, since GL4.3 the modern debug message callback is core so you can rely on it. Sure that won't save you on MacOS but if you can target modern OpenGL this isn't a problem in practice
[–] lightedman 2 days ago
"unless you wire up a debug-message callback via the optional KHR_debug extension which isn't available everywhere"
The beauty of OpenGL versus say Direct3D is that OpenGL is extensible and thus you can add that feature should you so choose.
[–] flohofwoe 2 days ago
Fortunately "beauty lies in the eye of the beholder" ;) I definitely prefer the D3D model instead of the extension soup of GL or Vulkan.
[–] klodolph 2 days ago
The KHR_debug is also kind of a pain to use because it gets called asynchronously (which is what you want, yes, but the difficulty is still there).
The problem is that you don't get *any* error messages from native GL in the first place (unless you wire up a debug-message callback via the optional KHR_debug extension which isn't available everywhere), and the builtin error system via glGetError() is pretty much completely useless.
Other APIs don't suffer from this problem, D3D, Vulkan and Metal all have excellent validation layers which give very helpful messages, and WebGL or WebGPU running in browsers basically implement such a validation layer out of the box.