corysama

I have been working for a while on a tutorial based on 4.6. When I get close to a first release, I’ll have to ask you for a review :)

My take is that older versions of GL feel nicer to teach to beginner programmers because they have so many specific functions to do each specific thing. You can have a lot of verbose, step-by-step instruction. But, much of what you have to convey is understanding of a convoluted interface to a hidden state machine. And, the one-step-at-a-time nature of the old interfaces build bad habits that don’t scale when you get serious.

With 4.6 we can get Direct State Access, Programmable Vertex Pulling and MultidrawIndirect. With that we can move the complexity from “lots of functions to manipulate a state machine” to a few functions that strongly resemble using malloc and memcpy to work with arrays of structs. That’s not trivial. But, it should be extremely familiar. It’s visible, flexible, scalable, and it sets you up to move on to Vulkan after you’ve learned the essentials of 3D rendering.

Several Amiga/DOS era games used a similar system for image compression.

Motivation doesn't replace working for 60 hours. It causes working for 60 hours.

I’m a cheerleader for the Khanmigo AI tutor effort. But, apparently so far they are discovering that the hard part is getting the kids motivated to actually ask the AI any questions.

3Blue1Brown does an amazing job of making math interesting to learn in itself. As opposed to the hundreds of millions of kids told “You just have to learn it or you’ll be dumb. Keep up or you’ll fall behind forever. Go!”

The vid calls out explicitly that math education is a primarily a motivation problem and I agree. One way or another, we need a lot more focus on that.

Someone could write an OpenGL layer directly on Metal. There have been a few incomplete starts at that.

Meanwhile, writing an OpenGL-on-Vulkan layer has been a plan for deprecating/simplifying driver support for OpenGL for quite a while now. Might as well focus efforts on that.

Being light in every sense of the word is a primary feature of the language.

Lua is great for high-level control of a program written in C/C++. When setting that up, I’ve often appreciated that I could removed features like file I/O from the Lua standard library and the rest keeps on trucking.

Lua is terrible for writing programs by itself. People keep trying to make it happen. But, for anything non-trivial, it’s a fool’s errand.

Power efficiency.

Long ago I worked on a project where the whole team was so productive I gave myself cubital tunnel from typing so fast for so long. I'd feel needle jabs in my forearms randomly. Like while standing around. Doctor recommended surgery.

Avoiding surgery involved months of finger stretches, forearm massage, 2 keyboards and 2 mice at different elevations, typing with my hands hanging slack like a zombie. It worked. But, even typing this out 20 years later I can still feel the RSI hiding in the shadows. Since then I've avoided RSI by spending 10x more time thinking about code than typing it.

All that is setup for: There have been many times recently where I've thought "I know exactly what I want this code to look like. But, damn. That's going to be a lot of keypresses..." The effort is nothing. Risking nerve damage is the concern.

In those cases I have been thrilled be able to tell AI exactly what to make, how to refactor it, how to clean it up, clean it up more, yet more, still not done. All in less than 10% of the keypresses that would have been required to type it by hand.

I write a lot of C++. A long time ago, I learned the basics of writing assembly. Even though I haven't written much assembly, it still helped me a lot over the years. I understand how it works. I can read the assembly output of my compiler and judge how well my C++ translates to machine actions. I can debug individual assembly instructions when stuff isn't going as planned or the C++ is not available.

I write a lot of high-performance code. To do that, I had to learn the details of how devices (drives/NICs/GPUs) work, how buses (PCI) works, how RAM, CPU caches, instruction pipelining work. Now I know how to structure data flow to work well with the machine instead of against it.

I write a lot of APIs. In doing that, I had to learn the hard way about how different API trade-offs drive client decisions. How to foresee problems in the future stemming from interfaces I'm writing now. How to argue with clients to get them what they need in the long term and not just want they want for the next milestone.

At all of these levels, I had to learn how each level works by doing it. By trying it lots of different ways. And, by optimizing it all the way down from "More productive client discussions" to "More performant assembly instructions" :P

Now whenever I do vibe-code, it's because I know exactly what I want and I can get AI to type it faster and with less RSI (carpal tunnel). Or, I know I want to prototype a few options rapidly before committing to implementing one design for realz. In neither of these cases am I telling the AI "Make it performant and easy to use." Because I know how I want to structure the code to make it performant. And, I know how to set up the API to make it easy to use. So, I'm telling the AI how to structure the data flow and how to set up the API. Because, if I didn't, I'd just be generating a big ball of noisy mud that's neat to gawk at, but has no long-term value.

So, what should you learn? You need to learn how the stuff you are interested in actually works under the hood by experimenting with it manually. Not just "Hey chat, make it work somehow..." You need to focus on architecture and systems thinking because otherwise you won't know how to prevent AI from holding your hand deep into a maze neither of you can escape from. And, you should be spending the majority of your tokens on step-by-step refactoring, never one-shotting. One-shotting is for AI tech demos. Not for learning or production.

Greybeard coder here. There are two separate problems you get to solve. 1) If AI writes your code, you didn't learn anything about the code. 2) If you don't use AI, you won't learn how to use AI. You need to learn how stuff works and how to code well. And, you can't do that passively. If you didn't type it with your own fingers, you didn't learn it. And, that includes learning "How to use AI?"

You want to learn web dev? Start typing HTML and JS. You want to learn how to use AI? Start typing specs and prompts. You'll need to learn both. But, you can't learn web dev by typing specs and prompts.

You can learn using AI as a research assistant, a tutor, a reviewer, a critic. You can use it to bang out quick tools, prototypes, deal with the hassles that are not your focus at the moment. But, whatever you are trying to learn, you need to do the actual implementation manually. There is no such thing as passive learning.