I don't agree that text is the simplest way to represent a program. In fact, from experience in other areas of knowledge, the opposite is true. Math and physics has evolved from use of pure text to the use of diagrams and non-textual symbols. The problem with CS is that we don't have a shared, simple way to represent symbols and images. We feel that text files are simpler because it has become the universal way to represent computer code, and practically all tools we have are designed to work with textual representations.
I don't think that works. I think most of us here would have similar understandings of something like https://tex.stackexchange.com/questions/19941/example-of-sys..., similar to what physicists might have from a Feynman diagram. I assume physicists could illustrate a proof with one, but would actually run through the QED equations, also. Similarly, we could deeply understand a system from an architectural diagram, but we wouldn't use them as source code.
now you can. ok, well soon :) but the theory is in place and works. Also stochastic Petri nets are actually equivalent to Feynman diagrams in a precise sense (https://johncarlosbaez.wordpress.com/2012/12/20/petri-net-pr...), they could be the Feynman diagrams of functional programming :)
Well perhaps it's mathematics that could benefit from an update to its representation. Mathematical symbols have evolved over hundreds of years and aren't really suited to modern systems of representation. When it comes to computers is it really easier to look up the unicode symbol '∩' or its LaTeX representation when you're trying to write 'A ∩ B' -- or would it be better to begin noting mathematics online in a portable way such as: (intersection A B)
One of the reasons for infix notation in math is actually that it provides a 'visual' reminder of useful properties such as associativity, and possibly others e.g. commutativity or distributivity. If all we ever used was a strict LISP-like, function-based notation, such a reminder would be lost and understanding or manipulating non-trivial expressions would be quite a bit harder. The effort in OP is actually a way of generalizing this idea to broader settings, where one is dealing with something more complex than a single domain of number-like values, and a handful of operations on them. This is arguably how one should think of "graphical linear algebra" as well: the 'diagrams' one's dealing with there can be thought of as generalized expressions, so there's nothing overly strange in being able to manipulate those formally according to well-defined rules of some sort.
this is exactly where the statebox project comes from, there is updated syntax for mathematics in the form of diagrams. of course not for all of it, but certainly very applicable to CS stuff
