> What expertise would be needed besides a person manually checking the inputs and expected outputs?
- Set standards to follow
- Setup linters, formatters, etc
- If inputs will still come from humans then how to test and ensure edge cases around those are fine (often missed by AI)
- Impacts on cost, performance, memory usage and other requirements
- Be able to manually intervene and correct code if needed. Any automation will likely have places it gets stuck in
- Provide feedback so it improves
Consider how there were farms and farmers. Manual farmers back in the days were a lot different to the farmers of today using machinery. Same with factories. It's not going to be a 101% automated.
Instead of trying to remember the literal content of the book, I try to remember the concepts.
Additionally, I don't worry about trying to remember every little detail. I also don't really take notes.
I draw a flow chart of key words as I'm reading. This does two things: 1) It keeps you active, which helps prevent your mind from wandering while reading 2) it gives a roadmap of what you read. Once you filled a page with your flow chart, stop and visit each node and recite how much you're able to remember. Star the items you can't recall and either go back and review that material or move on and come back to review later.
Part of what I'm realizing creating the flow chart does as I'm writing this, is it helps you differentiate between what was easy to remember and what was not. Also, don't try to get fancy with the flow chart, just draw basic circles (nodes) and directed edges. The flow chart should be a DAG, but avoid branching as much as possible.
I think the best place to start is by getting your hands dirty with a real deal API. https://learnopengl.com/ is a great place for that. Oh and the best part is that the book is FREE.
You'll need to be comfortable with C++, but even without in-depth knowledge of the language, the tutorial takes you quite far.
https://learnopengl.com/ is a super popular recommendation, but I found it a bit lacking when trying to understand how things work. I tried using a college book instead, Computer Graphics Programming in OpenGL with C++ and found it more approachable.
Hot take: OpenGL is lacking when trying to understand how things work. OpenGL hides a lot of state from the API because it has a lot of cruft from when Graphics cards were ASICs. DirectX 11 and especially 12 and Vulkan are closer to the actual hardware capabilities of the GPU and state is more explicitly passed between stages rather than having a state machine hiding somewhere in the driver
It's not out yet, but the light phone 3 might fit what you're looking for.
Although, it uses an e-ink display, so things like texting and gps may be a bit weird to use. Not sure if you'll get guaranteed updates for an extended period of time like 7 years though.
This is one of the top posts on /r/rust over on reddit, which details the pain points of using rust for gamedev. It's a long one, but give it a read if you have the time.
Many of the posters in that subreddit along with even developers of rust saw the critique of the language as fair and well thought out.
Yep. Try to read the article and see if it resonates with you OP. Despite that though, there still many people that is interested in writing game (or engine) in Rust. The upcoming release of Tiny Glade[0] is maybe one of the most anticipated game in Rust game space (using Bevy ECS behind the scene). On the Bevy end, there is also a plan to integrate a scripting language so you could do the game logic on it instead.
As someone else said already: Theory of Computation by Sipser is the go to intro book for this.
I'd recommend really reading the book front to back honestly. It helps to have a complete picture of everything that leads up to getting into complexity theory.
I know you're on the side of discouraging AI tools (at least that's how I'm interpreting your response), I just want to highlight that I think the calculator argument is different than the AI one.
Yes, they're both new tools here, but the calculator argument didn't have the caveat of sometimes 2+2 won't output 4. LLM tools do have that issue and it's important that junior devs don't overlook this and are able to function on their own.
I think I'm on the side of "use tools to speed up your work, once you actually know how the work ought to be done."
Calculators spit out wrong answers all the time, it's just due to user error, like fat-fingering an operation button or adding a zero somewhere. It's easy to tell when that happens if you understand how it should work, because you're not just using the output blindly.
Same idea with AI tools. It's important that you already know what the output should be, at least well enough to notice when it's wrong. But you probably don't need to type out every line of code and deal with your typos and whatever.
My guess though is that it's all just a show. I really doubt that other companies are incapable of producing devices like that. They just don't launch them because they're probably not viable one way or another (quality control, demand, ROI, etc).
And yeah they're definitely stealing. Huawei has been caught pretty blatantly doing so.
reply