wires

9 ms·

31.
by wires 8y ago
FWIW, I found that we can develop a "business process" with a client and get very valuable feedback from the domain expert, who might know very little about computers. I don't really see myself live coding with a non technica
32.
by wires 8y ago
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
33.
by wires 8y ago
Valid point, but this is why there is category theory. That is really about the "compositionality of systems", we need that more than diagrams. Just turns out diagrams are a good way to do things with categories
34.
by wires 8y ago
I think the conclusion is because one diagrams has many different syntactical expressions, but the theory tells us they all behave the same, so we can just pick the most efficient, most compact, whatever. ie. the diagram is the best represe
35.
by wires 8y ago
Stay tuned! It is not any kind of design but specific diagrams and for a certain large class of programs we can do it. It might take a while before we've implemented all the needed runtimes, but JS should be release sometime this year
36.
by wires 8y ago
I totally agree with you & thanks for that nice GIF! I used LabVIEW a lot and always enjoyed it... so anyway we have keyboard input for the diagrams / blocks, its very important. also a minimum of wires, they are annoying to draw
37.
by wires 8y ago
yo totally agree, keyboard input to build the diagrams is mandatory. we are going much more for a text editor feel than some VR-style swipe-a-wire but once that's working, I'm all for neuralink + VR for "diagram dreaming&quot
38.
by wires 8y ago
there is some pretty solid theory on how to translate between the kind of diagrams statebox uses and digital circuits. In fact we are doing some experiments with direct diagram to wafer (chip) translation using LibreSilicon http:/&#x2
39.
by wires 8y ago
I don't think I agree. We know that there are diagrams that come from category theory that behave very well, this is what statebox uses. It enforces certain constraints, so we pivot everything around this and see if we can recover some
40.
by wires 8y ago
so I started my studies in animation actually, I used a lot of those tools, you can think of statebox as applying category theory to restructure aftereffects or https://en.wikipedia.org/wiki/Shake_(software) when done
41.
by wires 8y ago
ohey. you came to the right place :-) 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
42.
by wires 8y ago
Hi, the ATM is mega simplified, we tried modelling the entire machine and it not easy. But we are quite convinced it is possible, but it demands features from the language that we have not implemented yet tho. Error handling is not really a
43.
by wires 8y ago
check back in a few weeks... we are working hard on the tools and you should be able to try it yourself. 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
44.
by wires 8y ago
right! statebox tries really hard to strike a balance between these two. 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 er
45.
by wires 8y ago
hi tomc1985 > 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 ap
46.
by wires 8y ago
100% this is the point exactly
47.
by wires 8y ago
love that blog, great anti-examples, thanks for sharing! we are really trying to avoid coming to this style of visual programming write once, read never
48.
by wires 8y ago
the tools for reasoning about text can be limited if the text is in a language unsuitable for reasoning this is why we work in a typed, purely functional setting. spaghetti is difficult to deal with, for starters, you need "composition
49.
by wires 8y ago
yep, the diagrams are like typed purely functional programs 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 ...
50.
by wires 8y ago
and thanks for posting the blog article on HN
51.
by wires 8y ago
Awesome stuff right? Pawel is great at explaining things! 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 particu
52.
by wires 8y ago
awesome comments, and we want to get that experience: a sound type-system and model checker that tells you when things go wrong (statebox' rustc) but add (formalised) graphical scaffolding to glue parts together.
53.
by wires 8y ago
:rock: 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. howev
54.
by wires 8y ago
Totally! I imagine a web of types and function definitions (as diagrams)
55.
by wires 8y ago
:) I also did a lot of Max/MSP and many similar systems, [nord modular]( http://nmedit.sourceforge.net/ ) , and also wrote such tools back then, for audio and 3d and video, which is what led to statebox ultimately. I wou
56.
by wires 8y ago
awesome comments, really cool to read all of this. 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,
57.
by wires 8y ago
Great points, > 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 cate
58.
by wires 8y ago
:) valid point! We are not quite ready for HN prime-time, we are still working hard on the tools and will def. show a demo once we are there but I come pretty much from the same standpoint: that visual programming sucks; but it doesn't
59.
by wires 8y ago
Yeah, I feel you, been there myself. 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 p
60.
by wires 8y ago
Hi, Statebox founder here :-) awesome to see this on the HN frontpage. Will read your comments and give feedback, meanwhile, feel free to ask me things!

More ›