Three Dollar Quill

Things are a little out-of-control right now, but I'm trying to stop it from getting to me.

I'm starting a new category today because I seem to be going in on this whole "Hey, let's try porting Ink to Python again" idea, and that's fine with me.

I've tried a few times in the past, and my efforts have mostly just led to bug reports and PRs against the C# version. (I actually forgot about the PRs, and was really confused for a little bit, seeing the "Contributor" badge on GitHub.)

What tripped me up in previous attempts was not, as other people's attempts might have it, that Python just isn't practical for implementing a VM like Ink. I would argue that PyPy stands as a counter-example to that sentiment.

My big issues adapting the C# codebase centered around non-local reasoning, circular references, dead code, and a lack of familiarity/ease on my part with some C# features.

For the last point, I just want to understand things well enough to come up with an equivalent in Python.

The other points can be summarized as: I don't know whether a given section of code is actually used, I don't know how many times a given field is set and with what range of values, and some pairs of objects are so tightly coupled that it's not clear to me which one of them "should" have a given bit of functionality.

That probably seemed mean, but it's the truth. I really was looking at some functions thinking "Okay, what on earth is the equivalent of this in Python? Like, I can't translate this directly for all possible ways this function could be called, so I'll have to specialize it for potentially each of the call sites, of which there are... none. Well, that was a waste of time."

So, the fundamental thing I was doing wrong in my previous attempts was, I was trying to directly translate an internal bit of code before I had the context on how it was used.

Now, some people advocating for particular practices to improve software quality really like tests. "Write your tests first!" they say. "Tests are the most important code, because you can use them to recreate correct product code, but you can't derive correct tests from your product code!" I haven't had the guts to take them up on the second assertion, but it looks like my best bet for getting this project off the ground. Focus on designing an interface that I can do local reasoning about, then port the tests to handle that interface.

Here's where I am on that currently:

• I've got a file full of stub functions with type signatures that are approximately correct. I may tweak them depending on how I write the convenience functions.
• I copied 100+ Ink snippets out of the test suite for Ink. I've got some steps put together that should handle converting the snippts to story json, but I haven't ported the tests over yet.
• I've created a Poetry project for this, and got it building. The dependencies still need to be adjusted, and I haven't written most of the noxfile, but this step is something like an hour of fiddling around, tops.
• I'm going to need to add coverage, in particular.

Hopefully in a week or so, I'll be able to put up the very, very early prototype code for public consumption. Nothing else to be done right now, though.

Good night.