Replies: 1 comment 1 reply
-
|
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 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:
From my experience of using Github copilot, once you have 1-2 files setup correctly then copilot seems able to provides correct suggestions. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your elaborate explanation.
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
ChildProcesswith AI assistance, it took me half a day to determine the correct library path: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:
or
This led to errors in the generated code or suggestions for unusable alternatives, wasting valuable time.
The NuGet package names are as follows:
However, the actual namespaces to open are:
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 Nodedirective.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.
Beta Was this translation helpful? Give feedback.
All reactions