Nigredo

I worked on this with Peter Gardenfors in my PhD thesis. If someone is interested in a mathematical model of conceptual spaces which is not machine-learning oriented, you can check this out: https://arxiv.org/abs/1608.01402

Hey everyone, we published a blog post today where we try to answer to some questions and remarks that popped out in this thread. Check it out! https://blog.statebox.org/visual-programming-what-went-wrong...

Well, I think it's not really possible to divide a concept from the way it is realized. Many implementations of visual languages were badly done, for sure. This doesn't mean we can go from "this implementation of a visual language is bad" to "for all implementations of visual languages it is that they are bad". :)

True. We implement scalability by being able to glue nets together. This allows for a modular design where you can put together many sub-nets doing different things. This is again a purely formal process: It is graphical, yes, but what you are really doing under the hood is manipulating categories (precisely, gluing things together is done via cospans of monoidal categories, I suggest to check Brendan Fong's work about this if you want to know more. There's also a nice paper by John Baez and Jade Master about gluing Petri nets together using something akin to the cospan construction!)

Luckily we do. Our diagrams are sound and complete for free symmetric monoidal categories, meaning that every diagram can be converted to a morphism in a category. :)

This is exactly why we use petri nets and then we map them to a semantics. Drafting a net represents the "diagram part". You draw what your code is supposed to do as you would do on a whiteboard. But this time you have a lot of formal tools to do checks on the net (is it deadlock? Is it live? Does it have nice properties?). Once you are satisfied with the net, you populate it with meaning: Places of the net get mapped to datatypes and transitions to functions. This is the stage where you start typing stuff in. What you gain is that the translation between ideas (diagrams) and code is formal, so way less prone to error.

What you say is true. Text is way more expressive, but sometimes it is difficult to spot the overall code structure just by using text. What Statebox does is this: It implements Petri nets as categories and maps them functorially to a "normal" functional programming semantics. What this means is that: - You draw the structure of your code in a behavior-oriented way using petri nets. This step is completely visual. - You use a ton of formal tools to verify that this net has nice properties. - You map places and transitions of the net to datatypes and functions, respectively.

You see that in this approach nets serve the purpose of giving an high-level understanding of how the code behaves. You still have the freedom that you get by using text in filling the net with meaning, but you gain also this high-level overview that saves a ton of work!

> Visual programming tools attempt to map logic to a (usually) 2D domain where there is no natural or intuitive general mapping. The representation has both too many degrees of freedom (arbitrary positions of nodes in 2D space that are not meaningful in the problem domain) and too few (connections between nodes end up crossing in 2D adding visual confusion due to constraints of the representation that don't exist in the problem domain).

In general this is true, but the diagrams we use at Statebox are different in the sense that there is a completeness theorem between the diagrammatic language and an underlying mathematical structure (a category). In this case the mapping is sound by definition.

Also, it is worth stressing that our diagrammatic calculus is topologically invariant, meaning that the position of diagrams in space is meaningless, everything that matters is connectivity. This is also the approach originally used by Coecke and Abramsky in the field of Categorical Quantum Mechanics, which is getting huge success to define quantum protocols :)