Been thinking about this as well. Working on language native libs to react to eBPF telemetry and scale logic forks appropriately to avoid exhausting the host, motivated by disdain for Docker/k8s. I’d rather just import a dep and develop the behavior.

But I don’t have to time to write all that. So I have actually been writing helper scripts to generate object code and function signatures via ast libs.

This is how I originally “learned programming” in the 90s. The industry zeitgeist shifted to “churn out code” and all that wizardry was lost. I have no idea how to prove it but I sometimes think it was intentional to capture worker agency.

It’s been fun reconnecting to it but the ecosystem of helper tooling … well there is none. Tons of blogs with basics about for loops though.

Interesting! I would love if you could expand on your recent problem and also how this applies to OP!

I think F# could do this well.

.NET can do it:

https://learn.microsoft.com/en-us/dotnet/framework/reflectio...

See also - Source Generators, which can replace some forms of reflection.

https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/s...

A big reason why this kind of stuff doesn't quickly become unreadable in C# is that the output of a source generator must be a new file. So the ability to extend existing code is limited to the facilities that the language specifically provides for this purpose (partial classes & members, extension methods etc). It also means that tooling can treat all such generated code as virtual files, allowing them to be inspected, debugged etc.

I meant this which is different: https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/ty...

For example, there is an SQL provider that gives you generated types and auto-complete but it does this without running a source generator that emits files. It just happens inside the compiler.