Please reject this pull request. The only intent is to request for a discussion.

[sambitdash]

Dear @mikhail-j @norvig

Thanks a lot for developing the sample programs in Julia. However, when I read through the code particularly on the Chapter 2 items, I realized the developed code is a good implementation of the topics but is not able to highlight the Abstractions that are intended in the chapter. For example, abstract concepts of the AgentProgram patterns could not be interpreted from the source code that easily.

Hence, I checked in a version of agent.jl with minimal code to show case the abstractions.

https://github.com/sambitdash/aima-julia/blob/master/agents.jl

The code is just a sample and has not been tested. However, if you are in agreement to the proposal, I will be happy to modify the source code to a more presentable structure to keeping to the book's intent to best of my knowledge and abilities.

Secondly, I feel agent.jl is becoming a bit overwhelming with lots of concepts. It may be ideal if the core concepts are developed like a core library while the concrete examples like VacuumEnvironment, WumpusEnvironment are created as separate files. That may improve clarity and readability and keep the abstractions intact at a central location. I believe the Java samples are to certain extent thought out in that model.

Wishing to hear from you soon.

regards,

Sambit

Note: I am fairly a novice to GitHub. So requested a discussion through a pull request. If there are other collaboration tools that can be used, please let me know. I will be happy to use those.

[mikhail-j]

@sambitdash @norvig I am aware of the approach taken by aima-java as you have mentioned.

I believe however, that it would be in the wrong direction and not according to Julia and Lisp programming philosophy. This project is implemented and organized in a way based on aima-python and aima-lisp, which emphasizes metaprogramming, functional programming paradigms, and lazy evaluation which is not amenable to the usual C/C++/Java programming philosophy.

I hope you understand.

[sambitdash]

@mikhail-j I personally feel the book emphasizes a lot on abstract concepts. Completely eliminating those in-light of language constraints may not be the right approach when the languages now have some mechanism of representing abstract concepts. My intent is not to copy blatantly from aima-java but provide a good middle ground so that concepts are not lost or get burried in implementation details.

[mikhail-j]

@sambitdash I understand what you are saying about abstract concepts. But those are not eliminated because of language constraints as programming is rarely a one-to-one mapping of human models to code interpretable by a computer. It is the responsiblity of the programmer to understand how to implement a model in a specific domain/language that allows for idiomatic style adherence while not sacrificing the essence of the model.

When I began working on aima-julia. I looked at the style section in CONTRIBUTING.md in the Python 3 aima project and used it as a guideline:

The first rule is that the code should correspond directly to the pseudocode in the book. When possible this will be almost one-to-one, just allowing for the syntactic differences between Python and pseudocode, and for different library functions.

Don't make a function more complicated than the pseudocode in the book, even if the complication would add a nice feature, or give an efficiency gain. Instead, remain faithful to the pseudocode, and if you must, add a new function (not in the book) with the added feature.

I use functional programming (functions with no side effects) in many cases, but not exclusively (sometimes classes and/or functions with side effects are used). Let the book's pseudocode be the guide.

I also looked at the section in aima-java on Architecture and Design to get an idea of how that project proceeded.

Where it says in "General Goals",

Architecture and design decisions within AIMA3e are driven by the follwing design goals:

1. Algorithms should semanically be implemented as close as possible to the textbook.

2. The design should be flexible and extendable. A wide range of experiments with existing algorithms should be supported as well as experiments with own extensions / variants of existing algorithms.

3. Redundancy should be avoided where possible.

4. Object-oriented design is assumed to be key for reaching goals 2 and 3.

5. The implementation of the core algorithms should not depend on example applications, GUI stuff etc.

6. The implementation of the core algorithms should be efficient enough to be applicable in serious application scenarios, not just for demonstration purposes.

Goals 2 and 3 force to add architecture to the set of algorithms presented in the textbook. Common aspects of algorithms must be factored out. In an object-oriented design (Goal 4) this leads to a distribution of responsibilities to different objects. This is why a one-to-one mapping from pseudocode to Java code cannot always be expected.

The reason aima-java is structured the way it is, is because of legacy design decisions (emphasizing object oriented design) that don't really make sense for a project like aima-python or aima-julia.

In Python and Julia, one is encouraged to implement and organize things as higher order functions and rather classes that are extended or interfaced.

Implementing concrete examples like VacuumEnvironment, WumpusEnvironment as separate files would inevitably go against the terse readability that Julia code is able to achieve, a conciseness similar to the way agents.py is implemented in the aima-python project.

As a person who studied "AI - A Modern Approach", learning from the exercises and pseudocode found in the textbook figures, I have found the aima-python project most faithful to pseudocode of the algorithms.

The design decisions taken by the aima-python authors also had the benefit of introducing me to the functional programming philosophy and style whereas I was previously concerned with the fragmentation of classes in multiple files in Java. The functional programming philosophy enhances the clarity of the concepts found in the textbook considerably.

Regarding style, the way the Julia language is designed encourages the programmer to organize abstract structure implementations (types/mutable structs) in a single relevant file seen in the main JuliaLang project here: event.jl I have strove to write aima-julia to be idiomatic Julia code style so that the user not only learns about AIMA concepts but also learns the Julia equivalent of Python's PEP-8 style convention.

For the remainder of the aima-julia project, my intention is to implement it syntactically and spiritually close in line with the Python 3 aimacode project as I believe that is the best representation of what the authors of AIMA feel has the maximal pedagogical value for the majority of students.

[sambitdash]

@mikhail-j I guess you have your reasons of doing what you are working on. I am not quite aligned to the approach. However, it was important for me to highlight the gaps I personally felt. Thanks for this discussion. You can reject the pull request as there is no further discussion needed on the topic.