3 ms·

but the same could be said for indie games developed with tools like Unity or Godot—people who make games with these tools don't really know 100% about what's g

but the same could be said for indie games developed with tools like Unity or Godot—people who make games with these tools don't really know 100% about what's going on with the actual underlying systems they're stitching together to make a game with, but they stitch things together and create a game nonetheless. on its face that's fine, but as time goes on, "making video games" has gone from being something that required intimate knowledge and understanding of the software and hardware at the foundation of the executable you're running, to domain-specific knowledge relative only to one specific tool/framework. if you've only ever made Unity games and now you want to work on a more complex simulation, you either find yourself increasingly having to fight "the Unity way of doing things", or take the plunge and unlearn your current way of thinking in domain-specific primitives such that you can learn to do things at a lower level.

noduerme 4y ago
I'd agree, with the caveat that I think it's okay to start at the top of the stack and work downwards, as long as the limitations of the tools keep you learning. I'm sure not every artist at Maxis could write Assembly code. There are more chances for visual artists now to step into the world of code than there were then. I started off as a graphic designer in an ad agency, learned the 1990s Dreamweaver way of writing web pages, and learned HTML/CSS and AS2/3 and JS and then PHP and Node and SQL as I hit various limitations with what I wanted to do. Now I write full stack business software. But I know people who went the other way, who learned the visual art and UI skills they wanted long after learning C++. So, unlearning your framework is a way of learning, too. The difference I see between interacting with a black-box AI versus any of those other things is that the AI isn't a constructor kit, it's a finished product that doesn't lead to furthering any skill set. It isn't like using Unity to build a city simulator; it's like playing the city simulator.
lmm 4y ago
Learning the minutiae of a particular piece of hardware isn't important. Learning to understand and debug a program's is very important. Unity or Godot still work on logic - if A causes B and C causes D but A and C doesn't cause B and D, there'll be a reason for that (even if that reason is just "a bug in the Unity implementation") and a programmer has a hope of learning what it is. Probabilistic tools don't have that, and I worry about the implications for learning. (For the same reason I've always been very skeptical about including tools like ElasticSearch or Splunk in a dataflow - even if they seem to work reliably, how can you be confident they will continue to do so in the future?)

noduerme 4y ago

I'd agree, with the caveat that I think it's okay to start at the top of the stack and work downwards, as long as the limitations of the tools keep you learning. I'm sure not every artist at Maxis could write Assembly code. There are more chances for visual artists now to step into the world of code than there were then. I started off as a graphic designer in an ad agency, learned the 1990s Dreamweaver way of writing web pages, and learned HTML/CSS and AS2/3 and JS and then PHP and Node and SQL as I hit various limitations with what I wanted to do. Now I write full stack business software. But I know people who went the other way, who learned the visual art and UI skills they wanted long after learning C++. So, unlearning your framework is a way of learning, too. The difference I see between interacting with a black-box AI versus any of those other things is that the AI isn't a constructor kit, it's a finished product that doesn't lead to furthering any skill set. It isn't like using Unity to build a city simulator; it's like playing the city simulator.

lmm 4y ago

Learning the minutiae of a particular piece of hardware isn't important. Learning to understand and debug a program's is very important. Unity or Godot still work on logic - if A causes B and C causes D but A and C doesn't cause B and D, there'll be a reason for that (even if that reason is just "a bug in the Unity implementation") and a programmer has a hope of learning what it is. Probabilistic tools don't have that, and I worry about the implications for learning. (For the same reason I've always been very skeptical about including tools like ElasticSearch or Splunk in a dataflow - even if they seem to work reliably, how can you be confident they will continue to do so in the future?)