[manifoldgeo]

> I find myself battling untyped/undocumented YAML/JSON configurations, syncing JSON encoders/decoders, massaging incompatible dependencies

I feel your pain on having to manage so many dependencies. I write primarily in Python, and the various pip / Pipenv / pipx / PDM / Poetry dependency managers drive me pretty crazy. That's not even accounting for the multiple Python versions I need!

That said, I'm surprised that you're trying to _alleviate_ this by implementing your FP language in Python. The Python ecosystem is full of half-documented config files, incompatible dependency trees, etc.

Have you considered implementing it in any other languages after the Python one proves its worth? For example, if the language becomes strong enough, would you consider writing a scrapscript compiler in scrapscript, itself?

[surprisetalk]

Yeah, I'm not a huge fan of Python, but Max and Chris are world-class in that domain, so that's what we're doing for now.

Max has already started working on a meta scrapscript compiler: https://github.com/tekknolagi/scrapscript/pull/100

One thing I think we all agree on is that the implementations should be simple enough to easily port themselves to other languages. For example, one could probably port the existing scrapscript.py to Rust or Javascript using GPT in a single weekend.

You can see echoes of what I'm talking about in my tiny JS POC: https://github.com/tekknolagi/scrapscript/blob/trunk/scrapsc...

Some languages like Rust and Go put a lot of weight on the "official" implementation. I think scrapscript can be more like Lisp/Json where the spec guides parallel implementations. There are obvious downsides to this in general, but I think that content-addressability makes some of those problems moot.

[tekknolagi]

None of these config/dependency problems are present in scrapscript.py because it has no external dependencies and is written in one file. This is intentional!