modulojs

@modulojs@programming.dev
1 Post – 4 Comments
Joined 10 months ago

I remember this one. It seems as spot on now as it was then, IMO. It's not trying to say that object detection is magic or impossible, since it was totally possible then as well. It just requires a dedicated team + time + money to pay them, which is what this comic was trying to express. It is true there are more off-the-shelf software available for newer programmers now than there was before, so dev time is shorter, but that's more just degrees of comfort / budget as opposed to anything fundamentally different.

3 more...

Absolutely. C# in Unity always seemed to me like a square peg in a round hole.

From my perspective (teaching game programming classes), it's incredibly clunky for beginners when compared to others. Unity needed a tightly integrated, noob-proof scripting language. Despite C# being the primary language, it's integration and setup with the rest of Unity seems surprisingly lacking, and, like you're referencing, you don't even get convenient use of the broader C# / Mono / .net ecosystem, which makes skills more portable. Even the "bad old days" of Flash/ActionScript were much easier for students, and results in more portable coding skills (e.g. at least transitioning to Web / JavaScript from Flash / ActionScript is easier)

It's much easier to teach same lessons / concepts using Godot, though sadly Unity is much better known. Hopefully the present pricing chaos might shift the needle a bit on this!

1 more...

Thanks so much for the feedback! Yeah, glad to see it look familiar! My goal was exactly that, to be kind of in between Vue, Svelte, React, and backend SSG templating, so it's "skill-compatible" in both directions, e.g. pro devs can pick it up and feel expressive with it right away, and newbies can learn it during class, and then transition to something else and feel less overwhelmed during the entire process.

What have been your biggest challenges as you’ve developed this?

Ooh, good question! Since I developed it while "dogfooding it" internally for a while, the main issue was knowing when something was "user error" or "framework error", and when to just fix this for the site, when to document it as a "gotcha", or when to add a feature or fix a bug in the framework itself. I suspect this is probably a general problem of writing your own framework while using it!

Thanks! One of the oldest goals was a super clean "literate programming" version of the code. Right now the source is still messy / in development / riddled with TODO's, but still might be useful to read through and fork for your own framework ideas!