Fable is hard for AI to code properly

[ken-okabe]

The recent rise of LLMs, particularly Claude, has significantly boosted programming productivity. Naturally, I've been relying on Claude and Gemini for assistance with Fable code, but they find it extremely difficult to write Fable code.

The primary reason is the lack of clarity regarding the necessary library paths. Even for humans, this can be quite challenging. For instance, while attempting to implement Node's ChildProcess with AI assistance, it took me half a day to determine the correct library path:

open Node.ChildProcess

This interruption caused a significant delay in my otherwise productive coding session.

Google wasn't helpful, and neither was Gemini. They repeatedly assumed the path was:

open Fable.Import.Node

or

open Fable.Node.ChildProcess

This led to errors in the generated code or suggestions for unusable alternatives, wasting valuable time.

The NuGet package names are as follows:

<ItemGroup>
    <PackageReference Include="Fable.Browser.Dom" Version="2.16.0" />
    <PackageReference Include="Fable.Core" Version="4.3.0" />
    <PackageReference Include="Fable.Node" Version="1.3.0" /> 
</ItemGroup>

However, the actual namespaces to open are:

open Browser
open Browser.Types
open Fable.Core.JsInterop
open Node.ChildProcess

The lack of consistency and rules between package names and library names causes immense confusion for both humans and AI. It feels like a lucky guess if you can identify the correct path on the first try. This issue doesn't arise in the ESM realm, where import names are clear.

Experienced developers of Fable might not find this problematic due to their familiarity, but I believe it's an issue.

Neither the NuGet page nor the GitHub repository mentions the necessary open Node directive.

https://www.nuget.org/packages/Fable.Node
https://github.com/fable-compiler/fable-node

Without this information, even AI with vast knowledge cannot generate correct code, and the same applies to humans.

This same issue has repeatedly arisen when using Promise and other libraries as well.

Similar to the NPM ecosystem, providing clear instructions on installation methods and correct open paths should be considered a basic courtesy. The current situation is highly problematic.

[MangelMaxime]

The disparity in the naming is because Fable has been around for a long time, and most of the library have been manually crafted.

The situation should improves over time thanks to Glutinum because the namespace are going to be more consistent with the original API. We also have plans to rework Fable.Core, to make it more deterministic with the introduction of new target to Fable like JavaScript, Python, Rust, etc. #3513

I am surprised that you say that documentation about promise is a problem, when this is probably one of the library which has the best documentation available as the whole API is documented with examples.

Documentation takes time to make, and we only have a limited time to invest on it while also fixing other issues. We welcome any effort from the community to help. Adding documentation to the README with example code can be a good first step. It seems be working fine for Glutinum packages for examples:

• https://github.com/glutinum-org/Glutinum.Fuse
• https://github.com/glutinum-org/Glutinum/tree/main/glues/Express
• https://github.com/glutinum-org/Glutinum.Feliz.ReactResizeDetector

From my experience of using Github copilot, once you have 1-2 files setup correctly then copilot seems able to provides correct suggestions.

[ken-okabe]

Thank you for your elaborate explanation.

From my experience of using Github copilot, once you have 1-2 files setup correctly then copilot seems able to provides correct suggestions.

I believe your approach is highly rational. By placing such files or web pages in a prominent location within the Fable project, search engines will be able to easily recognize them, while humans can manually copy and paste the information, expecting robust support from AI.