Interesting idea! I appreciate the org/plaintext driven approach, not that different from wm config bindings.

I like the idea of behavior (in this case keybindings) updating from documentation/data changes without needing to edit the code, tho there are tradeoffs and added complexities to mitigate

Dang, haven’t heard of this, looks pretty cool!

In fact i did not know that! Thanks for the vid, will check it out!

We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it

Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade's influx of typey-langs and -devs.

I think most love for types is folks being happy they don't need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It's hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you've even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It's also frustrating b/c types don't guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it's like pleasing the wrong boss, or some metaphor like that.

I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages... similar to type-favoring opinions suffering b/c of langs like typescript.

Nil-punning makes me very happy - that's a hill I will actually die on. Almost every project i've worked on, there's no reason to go out of the way to specifically handle every case of not the right input or oh-no-it's-null! Whenever you have null, you just return null from this function too, and guess what, everything's fine - no need to crash and blow up b/c one thing wasn't there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.

Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.

100%! It was mind-blowing to realize lisps are actually syntactically simpler than all the non-lisps so popular today

Takes a bit of love from editor standpoint unfortunately, so most devs will just never attempt that hurdle

Nice. Classic rust reimplementation.

yup! you can do something like godot -e from the same directory as your project.godot to launch the editor for that project directly

I upgraded without issues… i wonder what kind of scenes these are that aren’t working.

I’d expect manually editing the tscn files could fix it, but wouldn’t know what to change without more info. Is there any detail/errors on why they are corrupted? Sometimes i launch godot on the command line to try to see more error info from the logs/output, tho the same should show up in the editor after startup.

Worst case you might have to recreate them… maybe that’s not too much work? I had to recreate tilemaps in the 3.x -> 4.0 migration, was pretty annoying

Yes! I love using x (and xs) for functions over whatever the thing is (or things are).

One thing i undervalued for most of my career was just reading code.

Get into the habit of digging into open source repos that catch your curiousity, and try to grok the way the project is layed out, what namespaces/files exist, what some of the core functions are, where the complexity is housed.

It’s all about getting exposure to patterns, especially if there aren’t other people to work with in your day to day.

So glad this landed! One of my all-time faves!