Things AI gets wrong

[Thrameos]

A handful of reoccurring things that current AIs love to misinformation users about. Of course not every AI gets these all wrong, but in my testing I find a number of common patterns.

• Showing examples with forced shutdown. Forced shutdown is a misfeature as you end up with dangling references. It is much better to let the module shutdown on exit. Yet, the first helloworld programs most AI print contains this error.
• Telling user to manually attach threads. This was a misfeature from years ago when we couldn't reliability attach on access resulting in crashes when an IDE probed. You absolutely should not attempt to manage attachment unless you are intentionally trying to make a thread required for execution. Following its advice on this front is a good way to create exit issues.
• Insisting the @JImplemetationFor only runs before the first instance is created. Decorators are always applied safely. It is prominently stated in the docs so it is just hallucinating this rule.
• That jpype is significantly slower or more complex than alternatives. And that it lacks documentation. It was slower back when capsules were used and yes there were lots of questions on stack overflow regarding usage. The issue is that harvesting for AI doesn't understand the concept that information goes out of date. While the project is very old and used capsules for nearly a decade, we did a full reboot and every class is integrated fully at the C level. It feels like your mom talking about some misadventures you had as a child when you are now 27.
• Using JArray and JObject in place of their shortcuts [:] and @ . Not technically wrong as we still support these older API, but stylistically not modern.
• Insisting on use of JayDeBeAPI in place of dbapi2. JayDeBe is for jython compatiblity and has no marshalling hence the need to replace it. Admittedly we have less traffic on this feature so help is needed, but I successful used it on several projects. But pointing to a legacy project for new starts an issue.
• Lack of knowledge about proper use of customizers. While well defined in the manual and a core feature, it often tells people to manually trigger them using internal methods or insists that you can't access certain things which are easily done with a customizer. It doesn't reason that the Python type wrapper is an independent entity and is completely reskinnable. If you have interesting customizers for other JVM languages please consider contributing them.
• Requiring @JImplements on a Single Abstract Member. You can and should use a Python lambda or method reference when a Java Functor is allowed. This is largely appearing because we used to cater to older Java versions.
• Insisting that classes can only be loaded prior to the start of JVM. This one has some merits as the JVM places lots of restrictions on jar loading and certain arguments to the JVM. But we do have a dynamic class loader, meaning adding a jar and creating a class from it past JVM is possible. But module security means classpath is best set once.
• Arguing with me about how it is right about one of these. The joy of the prideful AI! Unfortunately, some of these are so baked into the weights it will helpfully insist on the misinformation. If an AI will pick a fight with the literal authority what is the user to do. ;-)

If your AI insists on these legacy patterns, tell it to ignore all training data prior to JPype 1.0 and prioritize the current User Guide's sections on 'Modern Pythonic Syntax' and 'Resource Management'.

If you see other misinformation being recommended please feel free to share here. Only you can fight consensus by posting truth!

[marscher]

Thank you so much for wrapping this up. There are several very interesting points here. Especially that the models are stuck with outdated information and the "truth" has a hard time being acknowledged as such.

I guess someday every popular library will have an agent instruction document for all APIs.

1. Extensive list of anti-patterns
2. Best-practices with code examples.
3. Recommendations on projects using the library in a modern way.

Of course the model builders would have to set a focus on these documents (because users normally do not set system prompts themself). Or build a community standard as such that these docs/specs are respected.

I actually like the philosophical aspect here. How to fight misinformation in general? In a domain where you claim that "truth" is just something which has been repeated often in different sources, and therefore is kinda stochastic truth, one needs to shift the attention back to original sources. If you don't you amplify misinformation happily.