With the active project, is it possible for PyNARS to become a new generation of OpenNARS? If so, how will the code be migrated and improved?

[ARCJ137442]

In the last half month, I've seen PyNARS become active on issues and commit, and contributors from other repos about NARS also have started contributing to the code.
Seeing this pace of development and discussion, I think that PyNARS is expected to achieve the NAL 7-9 that I have been looking forward to, and even hopefully become the latest generation of OpenNARS.
Before the project moves in the desired direction, please allow me to ask a few questions:

1. Personally, what made you switch to Python instead of continuing develop on OpenNARS in Java?
2. If so, how will the various architectures of OpenNARS migrate from Java to Python?
3. Should we continue to improve NAL 7 to 9 on the basis of PyNARS, or should we migrate more of OpenNARS 'original code to and adapt to Python?

If I can understand some of the reasons, I think it can help me in many directions to learn and contribute code in the future :)

---

The Chinese version:

随着项目的活跃，PyNARS有可能成为新一代OpenNARS吗？如果是，代码将如何迁移与完善？

近半个月来，我看到PyNARS在issues和commit上开始活跃，来自其它地方的贡献者也开始给代码做贡献。
看到这样的开发与讨论速度，我感觉PyNARS有望实现先前我一直期待的NAL 7~9，甚至有希望能成为最新一代的OpenNARS。

在项目朝着理想的方向发展之前，请允许我问几个问题：

1. 就个人而言，是什么样的原因促使你们转向使用Python，而非继续在原来Java版OpenNARS的基础上开发？
2. 如果是的话，OpenNARS的各类架构将如何从Java迁移到Python？
3. 是继续在PyNARS基础上完善NAL 7~9，还是更多地将OpenNARS的原有代码迁移到并适配Python？

如果能理解其中的一些缘由，我想这能对我后续学习与贡献代码提供很多方向上的帮助:)

[bowen-xu]

Hi, I think English is better here for communication, since it's the common language for researchers from all over the world.

For the third question:

Actualy, in PyNARS, NAL 7-9 has been supported since v0.0.2 (released one year ago). The missing part is NAL6, which is related to variable. The master branch is not updated for a long time, but we worked on dev and other branches continuously. We will merge them into master after getting a stable version. All the levels of the logic part have been finished in dev branch, though sufficient tests haven't been done yet.

The difficulty of NAL 7-9 is not about engineering but theory. In this sense, of course there is no implementation which implements NAL7-9 completely, including OpenNARS 3.0.4, but the unstable version of PyNARS has supported the same inference rules of NAL1-9 involved in OpenNARS 3.0.4.

The code of OpenNARS 3.0.4 is too messy to be maintained. So it's not a good idea to just translate the java code into python. In PyNARS maintainability is a major factor to concern on. You can also see that the structure of the PyNARS project is quite different from OpenNARS 3.0.4.

[ARCJ137442]

Maybe I get the point of it.

At least in recent times, I have been learning NAL and NARS more than contributing to them, so I am sorry for misunderstanding the current progress of PyNARS and NAL 7-9.

For NAL 7-9 implementation progress, I can initially recognize the theoretical rather than engineering difficulties: As for the practical application verification of NAL 7-8 theory and the validity verification of NAL-9, a completely stable NAL/NARS theory has not been formed at present, so "implements its inference rules" does not mean "the theory is applicable to practice", and naturally does not mean "realizing/completing NAL 7-9".

I've heard a little bit about OpenNARS 'code mess before. Moreover, based on the widely popular and easy to develop features of the Python language, I am also inclined to "develop PyNARS using Python-specific language features and the new NARS architecture, rather than simply migrating Java code to Python".

[bowen-xu]

For the other two questions:

This project starts from my masters' dissertation. One consideration of using Python is that nowadays AI researchers are used to Python, and it's friendly to programmers in the developing stage. Also it's kind of a glue language, some stable parts which might not be modifed anymore (e.g. the Narsese part) can be implemented in C/C++ or other languages to enhance the runtime efficiency.

We just want to take the python version as a standard reference which is faithful to NARS theory, so that other developers can refer to this project to implement NARS using other languages.

[ARCJ137442]

I think "Prototype in Python and then re-implement in C/C++ to improve performance" involves what is known as the "two-language problem".

I mainly use Julia, based on LLVM and JIT techniques, to avoid this problem (Julia was created primarily to solve this problem), and last month I wrote a library on Narsese data structures and syntax parsing using Julia.

However, I personally do not reject the use of "Python & C/C++" way to implement a more user-friendly, more extensible NARS, I also think it is more valuable and attractive than the original code structure of the cluttered OpenNARS 3.x.

[bowen-xu]

Hopefully, PyNARS would become OpenNARS 4.0.0. It depends on the progress in the near future.