Why VisualSoar?

[analog-cbarber]

Just curious, but why work on VisualSoar, when you could instead update the Eclipse plugin or on bringing comparable features to JetBrains or VSCode IDEs?

It seems like you can never hope to provide the same level of features that established IDEs give you. I used to work on a programming language that had its own IDE, but we eventually decided to stop wasting time reimplementing features that already are better implemented in other IDEs and so we switched to providing an Eclipse plugin and never looked back.

[garfieldnate]

Hi, Andrew could probably comment better than me, but here's my perspective:

Soar tool development is currently sponsored by the Center for Integrated Cognition, and previously was sponsored through the University of Michigan, and the researchers at these institutes primarily use VisualSoar.

The one thing you get from VisualSoar that you do not get elsewhere is datamap validation, which is essentially a way to do static type-checking of your Soar code. Datamap validation will save you hours of torment looking for typos in large (or small!) codebases. The project structuring also embodies the current "best practice" for Soar projects, and there's a lot of built-up momentum for using it in a research context.

Funding also tends to come in small pieces, which means that it's generally more practical to make a step improvement in VisualSoar than to try to do a re-write of any kind, which requires larger resource allocations.

Long ago there were datamap validation and generation scripts included with Soar, but it was difficult to keep them up-to-date with Soar, so they were removed.

If you're interested in contributing, you might like #6. I would love to have the project-management and datamap stuff extracted into a re-usable library for use in other editors (via LSP or some other mechanism).

[PLatCIC]

I agree with both of you. Indeed Visual Soar has important features, especially the datamap, that are not available anywhere else.

On the other hand, there are a large number of things in Visual Soar that are very clumsy and annoying. Individually, they are just a pain in the neck, but all together they are very annoying. The new feature for important datamap elements is very limited, and overall there are no good tools for working on a large project with multiple modules.

My opinion is that it would be best to build a Soar plugin for VSCode and including the datamap in that. For sure that would take some effort, but it would contribute a lot for making Soar easier to learn and use.

[analog-cbarber]

The problem is that you can never really hope to implement even a fraction of the IDE features that professional programmers are going to expect to be there. Implementing a full featured IDE requires many people-years of effort. Why spend all that effort on features that are already implemented in existing IDE's rather than on plugins that provide the specific features needed for Soar?

Right now, it appears that the Eclipse plugin has the best support for Soar, despite the fact that it has not been updated for 5 years. It seems like the shortest path to the IDE features you want would be to take over that plugin and then consider how to provide similar plugins for VSCode and JetBrains IDEs, since those are the ones that most programmers use these days.

As for the datamap, I would MUCH prefer an actual language for declaring data constraints. Not only would that be much easier to author and understand, it would allow this knowledge to be checked into text based source control in a way that would provide meaningful diffs when changes are made.

[garfieldnate]

The datamap and project structure files are plaintext already, and we do check them into source. They aren't very human-friendly, though, and resolving conflicts requires some specialized knowledge.

I think most current users would prefer to edit the datamap through a UI, but difficulty with merges is a good reason to iterate in the era of shared source control.

I've played around with the idea of a unified JSON format, which would have the following advantages:

• Better string specification support, including character escaping.
• Doesn't use line breaks to separate pieces of information, which is problematic because they differ by system, and sometimes extras get inserted.
• Right now we have .dm, .vsa and comment.dm, and sometimes they get out of sync. It would be nice to eliminate all accounting related to the number of lines in a file, and eliminate chances of out-of-sync errors.

Additionally I would like to stop generating sequential node IDs, as two users editing the same project will end up generating the same IDs, leading to a conflict. Random strings would suffice. If ever desired, string IDs can also be set to something meaningful, unlike integer IDs.

If this sounds interesting, I'll add it to a new ticket.

[scijones]

@garfieldnate -- It sounds interesting to me.

I've even used that Eclipse plugin and like it, but VisualSoar has the datamap. When projects get big, that matters more to me than the creature comforts I'm accustomed to when working in a mainstream language. But if we can find a way to pay to get intelligible-when-resolving-merges datamaps that could be compatible with mainstream IDEs, well, I'm all for it.

[analog-cbarber]

I think the first priority should be to get an implementation of datamaps that uses an actual declaration language and that provides a command line tool for checking compliance that could be used alongside any IDE (or used in CI jobs). The next step would be to push support for that into the various plugins.

After having VisualSoar crash on me a couple of times and blow away my file changes, I really want to stick with an established IDE.

[garfieldnate]

I find that position very understandable! I can't change the priorities but I do share the vision of having good Soar support in mainstream editors.

I'm really sorry that you're losing data. We're trying to track down cases that lead to data loss currently, so please file bug reports when it happens to you. Also, several data integrity fixes have been merged into master, and I would recommend using a newer build than what was included with Soar 9.6.3.

What do you mean by an "actual declaration language"? Datamaps are already stored in a plain-text declaration language (so it does go in source control), but it is indeed unwieldy and not suited to manual editing.

[garfieldnate]

@analog-cbarber Please comment on #38 with any further requirements for the project file format if you can think of any.