You are right about this, it is exactly what is hard to do!
it is possible to do some form of this, where you have well behaved "macros" that create diagrams of particular shape "at runtime" (forall n. the diagram with n copies of n)
39 karma · joined January 10, 2011
so we can go: diagram -> expression -> code of your choice from expression we can go back to diagram, but code to expression not necessarily.
the problem now is that if the picture is the leading representation, then we need to lift all the tools to the diagram realm, so comments, higher order diagrams, grouping, closures, variables, etc
but once that's working, I'm all for neuralink + VR for "diagram dreaming"
certain cases are still much better done in text and statebox itself is written in text, so nobody is claiming programming itself should be 100% pictures, but then again, I think it can be done and I think there is merit to it.
after all, text is also some sort of picture; on the screen but also in your head
when done right, we claim, you can target many different things ("semantics")
what we claim is something like, the compositional aspect of many such node based systems can be described as a certain type of mathematical object (monoidal category) ~ we can build an editor for that and then map that "dsl" to particular targets (image processing, state machines, etc)
no wires, composition of boxes, no vi bindings yet, but def. something wanted and what we are going for
I want vi/emacs/spacemacs for diagrams
Error handling is not really a problem, in fact, a lot of the time is spend thinking hard about each and every error that can occur and modelling it out ~ making sure the machine behaves well.
Problems are rather about machine synchronisation and how processes communicate (or rather, can we autogenerate proofs about their behaviour under communication).
thanks for the comments
I definitely want a good demo video on the page.
but listen, I get it, I tried literally 50 different such tools, they all suck. Nobody in their sane mind decides to write one if you don't have a good reason. Certainly not in Idris :-)
but we have good reasons:
1) compositional theories of diagrams exists 2) such diagrams can express many "topologically equivalent" expression in the same diagram, this is a huge win! and very different from (AFAIK) all existing node-based editors 3) use cases in decentralised computing require fault-free tools that work like this
but really, I think generally applicable usable 2d-syntax exists...
in order to make diagrams _as_ composable as functional code, you need proper theory of diagrams and a "compiler" that checks your diagrams for "type errors"
> Why does category theory magically transform node diagrams into something usable from something not? Unreal blueprints/Reactor schematics/whatever are quite fine in their current form, even if their usage falls apart in advanced constructions. Is statebox going to magically make huge node-and-graph-designed programs reasonable? Your writeup didn't convince me that "category theory" adds any significant value, and neither does it help inform as to what category theory actually is. How does statebox improve upon existing node-based programming implementations?
nothing magical, just good engineering and UX design and solid theoretical underpinnings.
cat. th. does add value: there are many ways to build diagrams and build syntaxes for diagrams, but they are not all equivalently powerful or general. but it turns out that there are diagrams that _are_ suitable, and this is what we use.
It will improve upon existing diagram tools in that it gives a formal theory of how they work, so you can really build huuge diagrams and still be sure everything works.
I didn't write the blog post, but I could try to write one about the value of category theory, because it is often misunderstood. It is however very abstract and takes the mind a while to see the value off, which is not so easy to convey.
> CS formality and big words misses the point of visual programming entirely, in that it is to simplify the process of software creation to make it more approachable to non-programmers. Unless your UX is absolutely top-notch you are going to lose these novice users as they struggle to deal with the constraints without a good reason to UX to do so.
oh, yeah this is something often misunderstood, we are not trying to target novice developers (yet). we need to develop a lot of stuff and CS formality is right now still the simplest way to understand the system. I mean, we are not trying to be arrogant or puffy or something, but for instance the way we realise our compilation is with "functorial semantics". we have a functor between categories that does the trick. We could call it something else, but it doesn't help (at this stage).
anyway, if we do our job well then all the category theory would be under the hood and you just get a nice UX for coding with diagrams.
> Also- The memetastic design of statebox's main page is a pretty big turnoff :(
opinions differ :) I thought it was quite funny 2 years ago and many people thought so as well and then it got turned into this homepage.
at the moment we don't really have time to spend time on the site, but it will def. be changed in the future
this is the point exactly
we are really trying to avoid coming to this style of visual programming
write once, read never
this is why we work in a typed, purely functional setting.
spaghetti is difficult to deal with, for starters, you need "compositionality", so that you get no undefined or emergent behaviour.
then second you need some form of "graphical macros", or a "meta-language" for diagrams, code that generates diagrams or "higher order functions" for diagrams.
also stream processing is possible, we can (at least in theory) use the same diagram to compose state machines or stream processing functions or DB queries or ...
It is certainly more complicated in the beginning, partly because it is a paradigm shift, and partly because of the abstract nature. But then again, linear algebra isn't particularly natural when you see it the first time, I'd say..
But graphical linear algebra gives other powerful insights, such as the meaning of division by zero. btw. we use a very similar calculus
but add (formalised) graphical scaffolding to glue parts together.
exactly, every picture represents an "equivalence class" of expressions (or code).
I say equivalence class, because the picture represents many formulas: by topologically distorting the picture you get different code. however, they all behave in the same way. 2+3 = 1+4 = 5
I would say the spaghetti aspect of max is the main complaint with visual programming.
To modularise it (small diagrams), you need to contain the behaviour of the boxes (ie. typed purely functional code).
And to generalise it (audio, video, microservices, ...) you need to separate the syntax from the semantics.
(took me about 15yrs to figure out a way to do this properly :-)
anyway, I would argue both are valid examples is graphical progamming, but they happen at different levels.
the "node based" tools usually define some sort of function or system, ie. a "type"; for this you need category theory to describe how the diagrams look and this is not what any editor I know does, but it means a whole of difference.
And the map editors are for defining "terms of a type", given a definition of a "map datatype" there is a graphical way to edit it.
when we talk about graphical programming we are initially focussing on the first, well defined graphical protocol definitions. you can think of it as type checked event sourcing, where the "behaviour" or "type" is described by a (sort of) graph representing a (sort of) state machine)
but we have relatively clear idea's to extend this to the second case as well.
The difference with other (older) approaches is that in the last 20 years a lot of mathematics appeared dealing with formal (categorical) diagrams or proof nets, etc. that we leverage. I claim we (the world) now finally really understand how to build visual languages that do no suck.
hence statebox :-)
> scalability and maintainability > easy for very small examples but it doesn't scale.
this is very true, that is why we do it differently; we clearly define the semantics of our diagrams and take guidance from category theory in this. this is different from other graphical languages; we try to assume the minimum but then guarantee you that some stuff is always preserved.
think of it like deterministic, pure functional programming, but with diagrams.
> usually lacks good mechanisms for abstraction, reuse and hierarchical structure. > f versioning, diffing or merging
very important points, we try to address this by having everything based on immutable, persistent data structures with built in content addressing; similar to git for instance.
diffing and merging is very complicated and still research but there are many hints that this can be done
but I come pretty much from the same standpoint: that visual programming sucks; but it doesn't have to be, that is what we are trying to demonstrate.
but this is mainly because those BI tools themselves and the graphical languages they use have issues.
when done properly, diagrams can be searched similarly to Haskell's hoogle, Purescript's pursuit, etc... in addition you could specify a template diagram it should match
Grothendieck certainly knew what it means for p to be prime. I don't know, but maybe his thoughts went along the line of "primes are some substructure of the natural numbers and such and such changes happen in the functions that we can build on them".
So he was obviously able to speak about some collection of primes, yet whether an actual number is prime he probably doesn't think much about.