Hive system for visual programming

[Sjoerd de Vries]

Hi everyone,

I just found your group, and I recognize some names from some thoughtful posts elsewhere on the web. This looks like a perfect place for deep discussions. 

For the last four years or so, I have been working on Hive, a general-purpose system for visual programming, aimed towards scientific protocols as well as game logic (Blender Game Engine). 

Hive tries to be a serious system covering the whole spectrum from point-and-click node diagrams to custom-coded components. It has been built from the low level up, and its mechanics are essentially completed, but the GUI is still in its infancy. 

On the one hand, Hive's mechanics are quite advanced for a node system. In its current state, Hive assumes quite some programming skill, and is not yet ready for non-programmers who are used to simpler systems like Kismet. 

On the other hand, its mechanics are not nearly as sophisticated as some of the ideas I have seen here.

I would love some feedback and discussion on visual programming mechanics and interfaces. In particular, how to make them general-purpose, i.e. useful and appealing for beginners all the way up to very experienced programmers.

Here are a few links on the Hive system:

https://launchpad.net/hivesystem/+download

http://www.blenderartist.org/forum/showthread.php?256747-The-Hive-system-version-0-91-released

http://www.blenderartist.org/forum/showthread.php?313868-The-purpose-of-Hive

cheers

Sjoerd

[David Barbour]

Your work on Hive looks useful for its target community. I hope you've had success sharing it. 

Visual programming has, of course, been done quite often. To me, most visual PLs tend to look the same or very similar in terms of features, and it is often difficult to find the subtle but significant differences. (The same is true for OO/Procedural text PLs.) Can you explain which aspects of the programming experience you believe significantly distinguish Hive from other visual PLs?

 

--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/groups/opt_out.

[Sjoerd de Vries]

On Thursday, October 24, 2013, David Barbour <dmba...@gmail.com> wrote:
> Your work on Hive looks useful for its target community. I hope you've had success sharing it. 
> Visual programming has, of course, been done quite often. To me, most visual PLs tend to look the same or very similar in terms of features, and it is often difficult to find the subtle but significant differences. (The same is true for OO/Procedural text PLs.) Can you explain which aspects of the programming experience you believe significantly distinguish Hive from other visual PLs?
>  
>
>

This is not easy to explain without writing a wall of text, but since you all have devoted a lot of thought to it, I hope some aphorisms may suffice. Here's my attempt at a 'Zen of Hive'.

- A hive consists of bees and their connections, nothing more.
- Bees are components, not functions.
- The bees do. They do all the work, they don't do connections.
- The hive is. It does connections and then nothing at all.
- No constructors for bees. Every single bee can become data.
- All static typed data can be visual.
- No constructors for hives. Hives construct themselves.
- A hive is a bee is a hive, down to an alphabet of primitives.
- Visual form is an option, and so is text form.
- Where there is text form, all rules can be violated.

Walls of text are available upon request.

Cheers

Sjoerd

[David Barbour]

Interesting. I like the recursively structured aspect of it.

Can you provide a typical example of your text form, annotated with types?

[Sjoerd de Vries]

On Thu, Oct 24, 2013 at 1:21 AM, David Barbour <dmba...@gmail.com> wrote:

Interesting. I like the recursively structured aspect of it.

No recursiveness, I am afraid, just hierarchy:  

A hive is a namespace. 

A hive is a class, it must be instantiated.

Hive class definition is equal to filling its namespace with bees. A hive is itself a bee (hierarchical nesting)  *

Bees come in three flavors: composite (hives), descriptive (connections, configuration) and primitive. 

Hive is a configuration/coordination system, not a computation system. Therefore, primitives don't compute, they interface with code that computes **. 

After class definition, the hive namespace is constant. Instantiation of the hive is nothing more than instantiation and connection of the bees. The bees never modify the parent namespace.

Every hive also contains an additional "context" namespace for horizontal (bee-bee) connections within the hive. After initialization, bees may define named sockets and plugins inside the context. 

Vertical (parent-child) connections are also supported: a hive can define a descriptive entry point, which must map onto an entry point of an embedded bee. Sockets and plugins can also be exported and imported from and to a parent hive.

The context is then closed, connecting all sockets to all plugins of the same name ***. No other connections are allowed. After the context is closed, it is not modified further.

Implementation details:

* = The Hive system is implemented in Python, which has a natural correspondence between classes and namespaces (a class is a dict), as opposed to C-like languages (each class instance is a struct). 

** = "drone" primitives are thin wrappers around a Python class. "Segment" primitives give fine-grained control over the execution order, and may embed a few lines of code. "Workers" are composite bees that contain only segments ("miniature hives"), and all segments are inside a worker. 

*** = Some descriptive bees declare a socket/plugin where the type name is part of the socket name, implementing a form of static type checking. Drones and workers may also declare sockets/plugins directly.

Can you provide a typical example of your text form, annotated with types?

Here is the implementation of a selector bee, as text-form (code-form) worker:

http://bazaar.launchpad.net/~sjdv1982/hivesystem/trunk/view/head:/dragonfly/logic/selector.py

This hive (also in text-form) shows how the selector is used:

http://bazaar.launchpad.net/~sjdv1982/hivesystem/trunk/view/head:/manual/movingpanda/panda-12d.py#L194

The selector bee has also been ported to a visual-form (data-form, XML-like) workermap. 

http://bazaar.launchpad.net/~sjdv1982/hivesystem/trunk/view/head:/dragonfly/logic/selector.workermap

cheers