Q: Why focus on NLP interface rather than an internal format documentation language – e.g. some sort of XML description of the modules?

A: The goal is to enable fast, expert integration of cutting edge engineering & research modules that the IDE user is not expected to be familiar with as his toolset. Robust NLP libraries should make the results faster & less error prone. Experts will still be able to view & potentially edit/correct scripts in a clean language like Python + libraries that implement the familiar data access conditions.

Some tool like Keras might be invoked in different ways at many different points in a workflow & the interface modules used to configure those different stages might well be different, reflecting different specific foci & concerns. This is not problematic, but care should be taken to avoid hidden assumptions about environmental uniqueness & needless multiplication of docker containers where that is not necessary or desirable.

Specifying & dealing with variable that are pipes, or files/databases to be selected for updates is part of the environment/language. Also parallelization features.

I believe it can be helpful for NLP/AI research to look & save the frustrations that people will run into. They have some basic case that works & they are trying to tell the software that they want it a bit different in such & such a way. Why doesn’t it understand? If it’s not understand a word then the interface should be able to clarify & work through that. But there will be cases where the conversational concept is not grasped that are more interesting.

Generalizing notification triggers & timers for potentially long running task pipelines is a good feature that can be useful in unexpected ways.

Users can assign special names to input/output variable positions & specific result versions. For usability the environment should provide user friendly styles by default for referring to & recalling the variable names in conversation and the resulting scripts.

Workflow coordination, scheduling, & prioritization issues can affect both algorithms & overall performance. The issues & complexities different than but parallel to OS level issues with thread & process coordination. At this point in time, we do not recognize a single leading or near best set of conventions for arranging coordination. We believe that lock-free algorithms are more robust, without significant drawbacks if they can be automatically constructed in a correct way from the environment.

Our recommendation is to the let specific sets of conventions for scheduling be a parameter of IDE modules so that competing systems can be implemented until a leading candidate emerges as best & most popular. Many different systems may refer to a global blackboard of IPC-like semaphores and such that is manipulated in a lock-free way that defaults to private per work unit & then private per pay of coordinating work units.

Q: Can NLP AI handle patterns of automating log reports for application msgs/exit conditions etc?

A: Should be possible

From conversational descriptions & requests, there may be many situations in which some versions of this pseudo-algorithm is viable:

Identify the context as one where some sort of repeating treatment should be meched.

Circumscribe the set of input materials to consider for some mapping relation

Circumscribe the set of output formats to consider

Identify process candidates where there is some sort of homeomorphism from a subset of the input materials to the functional arguments to a mech process that creates the desired output format.

Among all the identifiable chains like that, rank them from most promising to least promising based on features like using most of the input materials mentioned, context, typicality, etc.

Ask the user if the most promising candidates fit the request.