Tooling: Design of Meta and Underlying Rationale
Meta is a intended to improve developer ‘nous’. While all the factors in intelligence are operative, nous brings together the more disparate aspects to produce a knack, a know-how for accomplishing tasks in an optimal way.
Part of the suite of developer tooling being developed by the OpenMastery group, Meta is a backend tool to assess developer heuristics and suggest improvements, particularly improvements that will make the resulting code more readable and useful to other developers, provide keyword clouds via topic clustering and Wordnet synonyms, antonyms, pertainyms, meronyms, etc.
It accomplishes this by creating a context based on developer actions, input and correlations with the various tools and aspects of development processes. Meta runs as a headless OSGi daemon with certain non-visual Eclipse tooling, such as jACT-R and the Eclipse JDT included. API access is accomplished via the Apache Synapse instance that is part of the daemon.
Meta can be difficult to grasp initially, not least because it modifies itself dynamically on a constant basis. The following attempts to describe in simple, digestible terms what the basic notions involved are and the reasoning behind them.
___________________________________________________________________
Meta is designed such that, within specific restrictions and in a specific context, using recurring event patterns and semantic matching across relevant, often large, data sets, it can assist the developer as they work, gauge the developer’s overall state of mind, and make specific or in the absence of a fully determinate situation, generic suggestions, either in response to questions or on its own.
Part of the design of Meta is to preference too few assumptions rather than too many, to avoid the type of ‘false positive’ correlations that result in invalid and often ridiculous suggestions in generalize AI and machine learning techniques.
Tools Meta interacts with include IDE plugins, including peer-to-peer chat and code sharing, and the @torchie user interface. In the background it also uses repository metadata, issue trackers, and other related development tooling.
Meta Data Flow and Recursive Aspects
Meta initial processing code flow:
The above shows a simplification of the event to context code flow. The processing box in fact loops any number of times over data, filtering and further matching event and semantic patterns until it finds a relevant correlation or doesn’t. Patterns with relevant correlations are added to the context, while recurring patterns not yet correlated are added to a disk cache that ages them, so that patterns where a correlation is never found are eventually discarded.
Meta reconfiguration via re-creation of matching code from context flow:
The second diagram shows the recursive aspect of Meta, the main means by which the context improves by improving the matching code that processes events from the updated context.
The implementation in Java, which uses the jACT-R cognitive modeling toolkit, like most Java code, must be regenerated, pre-compiled, and reinitialized after updates to the context. Although this is also done on the fly, the time that it takes (and resulting pause in event processing) requires that it be done only after several context updates rather than on each update, which in practice means every 15 to 30 minutes when a developer is actively using development tools.
The events and correlated models in Meta include:
· OS events
· IDE events (Eclipse and Jetbrains IDE’s (IdeaJ, WebStorm, PyCharm, RubyMine, etc.)
· Source code and model
· Repository revision history
· User input text interpreted via topic word clustering
· Linting the source code
· Any refactoring tools available in the language / IDE being used
· Orion, a code refactoring simulator, that shows how much code will be affected by a proposed refactoring, run against the current code model.
· Code Query and Analysis Tools that analyze code in Java, C, C++, C#, Python, ABAP, SQL, Smalltalk, Ceylon, Scala, JavaScript and a number of other languages.
Meta supports the tag clouds and Storyweb features of the OpenMastery tool suite by enriching the underlying data with an individual, developer specific context, including timelines that allow correlation of ‘difficult’ periods of work with specific events, and correlation of topically clustered words in ‘neighborhoods’ that allow developers to assess their overall progress and identify areas that are causing undue problems, stress, and burnout.
Underlying Reasoning / Rationale for the Design
Meta provides a reasonable facsimile of intelligence, within strict restrictions and in a specific individual context, by utilizing correlations of matched, recurring event patterns across relevant, often large, data sets.
These limitations don’t make it less useful, but actively enhance its usefulness, both by only complementing rather than attempting to partially replace the active human intelligence of the developer, and by being fast enough and using sufficiently low resources to apply those limitations in areas human intelligence is not especially good at.
While other ‘AI’, ‘expert systems’, ‘machine learning’ etc. based systems try to accomplish more complex things that are closer to the way human intelligence operates, we don’t know how to ‘really’ emulate the necessary reflexivity of human intelligence. Reflection and recursion simulate certain aspects of reflexivity, but on their own fail to accomplish equivalent things. Despite that, we do know how much some of the prerequisites of actual machine intelligence would currently cost, as a correlate of the costs involved in the Blue Brain project in Switzerland
Since we already have a well-known, reliable, reasonably efficient and inexpensive means of producing human intelligence, there seems no valid reason currently to attempt to emulate it directly 😊.
