Mixin VS enso

And one day maybe you'll need that to inject code into specific location, but it's to do advanced things: https://github.com/SpongePowered/Mixin/wiki

SpongePowered isn't a Mod, they're the group that maintain the Framework for Mixins. The next mod in the stacktrace is cpw.mods.modlauncher

That source was probably outdated. Forge didn't natively allow you to do that. You could do Java voodoo to allow a library that implemented(? Not sure if it implemented the feature or simply allowed it to be used in a specific way) Mixins, those allow you to modify the game's bytecode. Modern Forge has that library natively. Source: First paragraph of https://github.com/SpongePowered/Mixin/wiki/Mixins-on-Minecraft-Forge

These days Mojang provides obfuscation maps, so you can work with proper class and method names (though no parameter or local variable names). There's also been a lot of effort been put into the tooling. Nowadays there exists Gradle plugins that will download the game jar, decompile it and deobfuscate it using the official mappings. You develop against the deobfuscated code, then the plugin will turn the unobfuscated names back into their obfuscated versions when you compile. There's also been technology developed that lets you easily modify specific parts of a method in the game, so you can e.g. insert calls to your own functions at runtime.[1] This saves from you having to modify the game jar itself.

[1]: https://github.com/SpongePowered/Mixin

quilt (and fabric) take mojang's jar and preprocess it similarly, but the rest of the modifications to the code are done at runtime using a ridiculously powerful instrumenting classloader. the game is not decompiled at all, other than giving you something to look at in the IDE.

If you can't use the API, I suggest you to use Mixins or really asking yourself if your idea should worth the instability/effort of creating a coremod.

see spongepowered's mixin wiki

> At least I have yet to see one that is actually useful in the sense of a generic (or even a single-purpose-built) language

Yeah as said, https://github.com/enso-org/enso seems to be a general purpose functional programming language with visual editor, but otherwise I haven't really seen any no-code solutions worth their salt. I'm not particularly a fan of enso either, but it's the best I've seen.

Although it's not quite the same, I do like what Enso[0] is bringing to the table, especially the 1:1 visual node/language interop. Whether this is generalisable to a fully decoupled interface remains to be seen, but there's definitely potential.

[0]: https://enso.org/

I think Enso is already taken by a YC company [0]. Could get confusing.

[0] https://enso.org

COMPANY: Enso Inc. TYPE: Full time LOCATION: Europe and United States of America – fully distributed company REMOTE: Only remote VISA: No VISA required DESCRIPTION: Hi, we are Enso (enso.org, Y Combinator S21)! We are looking for an amazing Cloud engineer to join our core team. We are a remote first company, working in Europe and the USA.

Friends of mine are developing Enso (https://enso.org/), an interactive programming language with dual visual and textual representations.

Even well before Bret Victor's time, there were tools for visual programming. I have been using LabView to maintain data processing in an optical laboratory.

> I'm convinced this entire space should be visual.

At my last 2 jobs I spent entirely too much time debugging Matillion jobs, which are visual. I have my doubts that it’s the panacea that it appears to be.

That said, you may find Enso particularly interesting: https://github.com/enso-org/enso