A project that has been a sort of a side-task for years, is starting to bear some fruit. Probably because this last month has been one of the rare instances when I had a little bit of time to actually focus on it.
For lack of a better term – I’m calling it Mindth for now.
Human-like thought had been a rather tough nut to crack. It was my feeling that most of the contemporary research directions were off-track, and I’ve been exploring into a different direction. There are myriad practical uses that are in need of something that brings to the table a more intelligent capability.
One area of practical use is that of machine configuration, such as for servers, workstations, and virtual machines (VMs).
The open-source project Muppet is a great example. It targets an area for which there is a great, immediate need — trying to simplify the process of setting up and configuring a server (or workstation, or VM — let’s use the term “box”). With Linux lamentably split into multiple diverging camps, and within each (for example, the Ubuntu family) relying upon multiple disparate ways of installing software, it becomes a bit of a nightmare to try to get things done. Add to this mix Windows, and then VMware or other virtualization environments, and you have a combinational-explosion of routes to explore to encompass all of the possible avenues and methods you need to know, to get even a fairly simple box set up to begin using it. But even Muppet does take a bit of researching to learn how to use it, and to set it up.
For small teams, or the lone worker — there just is not enough time to fiddle and tinker and google and nab books and ask colleagues for every little step of the way. Even for a substantial development or IT team, this complexity is a major obstacle. Certain tasks are easy — to you, or to someone who has spent many months working on this one area of expertise. But for those whose responsibilities span wide areas — taking the time to gain that expertise is just not feasible.
And it is quite unnecessary.
As one of the initial, practical applications of Mindth (outside of the proprietary applications which were done in the past) — I am creating a program with the ability to understand plain-English descriptions of what we want it to do. Specifically, to set up and configure a box, to install the requisite software applications, create VMs, optimize it and apply the known personalizations that the user likes — and to do some troubleshooting of problems. The knowledge upon which it draws, is expressed in plain simple English (I’m focusing on just English for the purposes of this discussion, but it is not limited to this one human language). For brevity I’ll use NL to refer to plain natural language (again, in this instance – that happens to be English).
To clarify: unlike most programming and script languages, with Mindth — the NL is unstructured other than the requirement of being understandable by a reasonably-knowledgeable human being. If a person can understand it, then Mindth should.
Mindth has a facility for comprehending your desires (ie, the goals), and can search what it knows, and what it can access and understand — to try to implement your desires.
One major facility is it’s crowdsourced-knowledge network. For example, within a given organization — you normally have knowledge that applies only to that organization, but which everyone needs to know. For example, the email addresses of various officers and IT specialists. The URLs of the team wiki. The servers that serve up web pages or run tests or hold the databases. Database passwords. Database schema. The location of the codebase. The components your code uses. How to access your version-control. Etc. It can be a non-trivial amount of work to just get this information – to track down who knows what, and to keep up with changes. To address this need, the Mindth system includes a set of online services that are available only to this organization, that the instance of Mindth running on anyone’s desktop can access. When a server-address changes, that information is put into the Intranet Mindth knowledge-base (a fancy way of saying ‘you tell it to Mindth’) – and that information is transparently pushed down to every Mindth-instance that needs it.
Actually, this crowdsourced-knowledgebase (let’s call this KB-Net, for network-derived knowledge-base) exists at several levels, each of which has a definite scope. The lowest scope is at the level of the solitary developer himself. That information is private to him or her — it serves as a recorder for his notes (I’m going to adopt the convention of just using the masculine gender here, to refer to either gender: no discrimination is intended). The next higher scopes would apply to the organization, which may have multiple levels of scope (immediate team, department, company). And then the widest scope is Internet-connected and applies world-wide, as for example information that denotes how to install a given application.
Currently, Mindth is being implemented on Ubuntu and Windows, using the programming-languages C#, F#, Python, and C++ where necessary. The main user-facing application is a desktop GUI that on Windows is composed using WPF. I am using Test-Driven-Development (TDD) for the lowest-level routines, where that makes sense. For exploring major ways of accomplishing things, I keep the TDD on hold, since following that to an excess would seriously slow down progress. Individual functions – those which are well-defined, must work without fail – I simply don’t have time to do extensive debugging with each change, and this is a system that must achieve consistent correctness, thus that is where TDD makes sense: a good balance of experimentation and disciplined process is essential. For the code that implements what we would call “thinking”, or feeling, or perceiving — I need the ability to tinker and experiment and to quickly evolve in new directions.
There are functions within Mindth that are taking a rather long time to run, despite my having re-implemented portions in C++ and exploiting every CPU-thread available. I’m exploring the possibility of taking advantage of the computing power of a high-end GPU card to make this faster.
With regard to programming languages, I personally am feeling a very good relationship with C# — it is turning out to be the best possible overall-systems programming language. F# presents an awesome opportunity to succinctly express some of the pattern-matching and logical-rule-resolution paradigms, and it mates very well with C#. C++ is the original, barebones pedal-to-the-metal (as in, very efficient) programming language; it falls a bit short when you need to express complex data-structures, but for speed and interfacing with electronics it is unsurpassed. Python.. what can you say about Python? At first it feels like a rather odd fellow, but it IS a great tool for tinkering interactively, for gluing things together, and for exploring some of the excellent open-source assets that are available. The toolbox needs all four.
The architecture itself, is a topic for later discussion.
We’ll see where this goes. I am having some fun.