3 ms·

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand ex

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand existing programs - for which visuals are wanted by most but they usually need concious input to be their best - programming (creating new code) itself - where the efficiency of the keyboard (with its 1d input that goes straight to spaghetti code) has never been replaced by visual (mouse based?) methods other than for very simple (click and connect) type models

sbensu 2y ago
You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program? That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program
- learn_more 2y ago
  You might be interested in: https://schematix.com/video/depmap https://schematix.com/video/depmap I'm the founder. It's a tool for interacting with deployment diagrams like you mentioned in your article. We have customers who also model state machines and generate code from the diagrams.
  - transpute 2y ago
    > Schematix provides diagrams as a dynamic resource using its API. They aren't images you export, they don't end up in My Documents. This isn't Corel Draw. In Schematix, you specify part of your model using a graph expression, and the system automatically generates a diagram of the objects and relations that match. As your Schematix model changes, the results of the graph expression may change, and thus the visual diagram will also change. But the system doesn't need you to point and click for it. Once you've told it what you want, you're done. What an interesting tool! It's rare to see robust data models, flexible UX abstractions for dev + ops, lightweight process notations, programmatic inventory, live API dashboards and a multi-browser web client in one product. Do you have commercial competitors? If not, it might be worth doing a blog post and/or Show HN on OSS tooling (e.g Netbox inventory, netflow analysis of service dependencies) which offer a subset of Schematix, to help potential customers understand what you've accomplished. Operational risk management consultants in the finance sector could benefit from Schematix, https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/the-future-of-operational-risk-management-in-financial-services https://www.mckinsey.com/capabilities/risk-and-resilience/ou.... Lots of complexity and data for neutral visualization tooling.
    - learn_more 2y ago
      Schematix is somewhat unique. Direct competitors? -- not exactly, but IT asset managers, DCIM, BC/DR tools, and CMDBs are all competitors to some degree. Some of our best users are professional consultants who use us for a project which often introduces us to a new customer. A Show HN would certainly be in order. Thanks for the thoughts!
      - transpute 2y ago
        Do your blog posts have individual URLs? I would like to share a specific post, rather than the cumulative log.
- charleslmunger 2y ago
  This can be really tricky to do. I reached the limit of my brain's working capacity designing a priority inheritance system, and sketched the state machine out in a dot file, visualized with graphviz - this worked really well for reasoning through the correctness of the algorithm and explaining it to others. I tried to structure the implementation code to match it and I was able to get pretty close; but the actual states were a bunch of bit-packing and duplicated control flow to get optimal assembly output for the hottest paths. Each one of those changes was easy to reason about as an isolated correct transformation of the original structure in code, but would have been a mess visually.
  - sbensu 2y ago
    That sounds super interesting! Did I understand correctly that the additional complexity came because you needed to emit optimal assembly? Or was implementing the logic from the state machine complicated enough?
    - charleslmunger 2y ago
      Designing the state machine was hard. The implementation of that state machine was not that bad, because I'd spent so much time thinking through the algorithm that I was able to implement it pretty quickly. The implementation difficulty was optimizing the uncontended case - I had to do things like duplicate code outside the main CAS loop to allow that to be inlined separately from the main body, structure functions so that the unlock path used the same or fewer stack bytes than the lock path, etc. Each of those code changes were straightforward but if I had faithfully copied all those the little tweaks into the state machine diagram, it would be so obfuscated that it'd hide any bugs in the actual core logic. So I decided that the diagram was most useful for someone looking to understand the algorithm in the abstract, and only once they had been convinced of its correctness should they proceed to review the implementation code. The code was a terrible way to understand the algorithm, and the visualization was a terrible way to understand the implementation.
      - sbensu 2y ago
- w10-1 2y ago
  Virtually all diagrams are representations of declarations that are the source of truth. Visual editors just help you edit that, but rarely get close to validating the underlying structure. For things like programming languages and markdown, users switch between the modes. For something like SVG, users rarely learn or solve problems at the declaration level. The real questions come with declaration re-usability and comparison. Two pdf's can look exactly the same, but be vastly different declarations, which makes comparison and component re-use essentially impossible. It turns out, much of the benefit of visual editors is built on the underlying declaration model where it supports user edit/inspection goals. So I think the point is not to have the visual be the source of truth, but to have more visualization and visual editors for the sources we have. There are/were excellent visual editors for Java and Apple GUI's that supported round-tripping (mode-dependent source of truth). But we seem to have abandoned them not just because they're old, but because of the extra scaffolding required to do the round-tripping. So my take-away has been that any visualization must be source-first and source-mainly - with no or minimal extra metadata/scaffolding, as markdown is now. That would mean the implied point is that we should visualize (or otherwise abstract to understand) the source we have, instead of using diagrams as the source of truth.
airbreather 2y ago
Yes, in order to be visual coding (or better yet specification) it needs to be executable in it's native form, or maybe a very direct translation. The concept of an executable specification first came to my attention in IEC 61499 the standard for Distributed Automation. First published in 2005 it was way, way ahead of it's time, so far ahead it is still gaining traction today. Shout out to anyone reading who was involved in the creation of IEC 61499 in 2005, it was a stroke of genius, and for it's time, orders of magnitude more so. It is also worth a look just to prompt thinking for any one involved in distributed systems of any kind. Initially I thought there was no way you could have such a thing as an executable specification, but then, over many years I evolved to a place where I could generically create an arbitrary executable specification for state based behavior (see my other post this topic). I believe I have found the best achievable practice to allow defining behaviors for mission/safety critical functionality, while avoiding implicit state.
reddit_clone 2y ago
I forget its name, but there was an IBM graphical tool , with which you create UML diagrams and it in turn created code (Java IIRRC). The intermediate representation was in sexp !
- reddit_clone 2y ago
  Replying to my own comment. The tool was called "Rational Rose" !

sbensu 2y ago

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program? That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

learn_more 2y ago
You might be interested in: https://schematix.com/video/depmap https://schematix.com/video/depmap I'm the founder. It's a tool for interacting with deployment diagrams like you mentioned in your article. We have customers who also model state machines and generate code from the diagrams.
- transpute 2y ago
  > Schematix provides diagrams as a dynamic resource using its API. They aren't images you export, they don't end up in My Documents. This isn't Corel Draw. In Schematix, you specify part of your model using a graph expression, and the system automatically generates a diagram of the objects and relations that match. As your Schematix model changes, the results of the graph expression may change, and thus the visual diagram will also change. But the system doesn't need you to point and click for it. Once you've told it what you want, you're done. What an interesting tool! It's rare to see robust data models, flexible UX abstractions for dev + ops, lightweight process notations, programmatic inventory, live API dashboards and a multi-browser web client in one product. Do you have commercial competitors? If not, it might be worth doing a blog post and/or Show HN on OSS tooling (e.g Netbox inventory, netflow analysis of service dependencies) which offer a subset of Schematix, to help potential customers understand what you've accomplished. Operational risk management consultants in the finance sector could benefit from Schematix, https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/the-future-of-operational-risk-management-in-financial-services https://www.mckinsey.com/capabilities/risk-and-resilience/ou.... Lots of complexity and data for neutral visualization tooling.
  - learn_more 2y ago
    Schematix is somewhat unique. Direct competitors? -- not exactly, but IT asset managers, DCIM, BC/DR tools, and CMDBs are all competitors to some degree. Some of our best users are professional consultants who use us for a project which often introduces us to a new customer. A Show HN would certainly be in order. Thanks for the thoughts!
    - transpute 2y ago
      Do your blog posts have individual URLs? I would like to share a specific post, rather than the cumulative log.
charleslmunger 2y ago
This can be really tricky to do. I reached the limit of my brain's working capacity designing a priority inheritance system, and sketched the state machine out in a dot file, visualized with graphviz - this worked really well for reasoning through the correctness of the algorithm and explaining it to others. I tried to structure the implementation code to match it and I was able to get pretty close; but the actual states were a bunch of bit-packing and duplicated control flow to get optimal assembly output for the hottest paths. Each one of those changes was easy to reason about as an isolated correct transformation of the original structure in code, but would have been a mess visually.
- sbensu 2y ago
  That sounds super interesting! Did I understand correctly that the additional complexity came because you needed to emit optimal assembly? Or was implementing the logic from the state machine complicated enough?
  - charleslmunger 2y ago
    Designing the state machine was hard. The implementation of that state machine was not that bad, because I'd spent so much time thinking through the algorithm that I was able to implement it pretty quickly. The implementation difficulty was optimizing the uncontended case - I had to do things like duplicate code outside the main CAS loop to allow that to be inlined separately from the main body, structure functions so that the unlock path used the same or fewer stack bytes than the lock path, etc. Each of those code changes were straightforward but if I had faithfully copied all those the little tweaks into the state machine diagram, it would be so obfuscated that it'd hide any bugs in the actual core logic. So I decided that the diagram was most useful for someone looking to understand the algorithm in the abstract, and only once they had been convinced of its correctness should they proceed to review the implementation code. The code was a terrible way to understand the algorithm, and the visualization was a terrible way to understand the implementation.
    - sbensu 2y ago
w10-1 2y ago
Virtually all diagrams are representations of declarations that are the source of truth. Visual editors just help you edit that, but rarely get close to validating the underlying structure. For things like programming languages and markdown, users switch between the modes. For something like SVG, users rarely learn or solve problems at the declaration level. The real questions come with declaration re-usability and comparison. Two pdf's can look exactly the same, but be vastly different declarations, which makes comparison and component re-use essentially impossible. It turns out, much of the benefit of visual editors is built on the underlying declaration model where it supports user edit/inspection goals. So I think the point is not to have the visual be the source of truth, but to have more visualization and visual editors for the sources we have. There are/were excellent visual editors for Java and Apple GUI's that supported round-tripping (mode-dependent source of truth). But we seem to have abandoned them not just because they're old, but because of the extra scaffolding required to do the round-tripping. So my take-away has been that any visualization must be source-first and source-mainly - with no or minimal extra metadata/scaffolding, as markdown is now. That would mean the implied point is that we should visualize (or otherwise abstract to understand) the source we have, instead of using diagrams as the source of truth.

airbreather 2y ago

Yes, in order to be visual coding (or better yet specification) it needs to be executable in it's native form, or maybe a very direct translation. The concept of an executable specification first came to my attention in IEC 61499 the standard for Distributed Automation. First published in 2005 it was way, way ahead of it's time, so far ahead it is still gaining traction today. Shout out to anyone reading who was involved in the creation of IEC 61499 in 2005, it was a stroke of genius, and for it's time, orders of magnitude more so. It is also worth a look just to prompt thinking for any one involved in distributed systems of any kind. Initially I thought there was no way you could have such a thing as an executable specification, but then, over many years I evolved to a place where I could generically create an arbitrary executable specification for state based behavior (see my other post this topic). I believe I have found the best achievable practice to allow defining behaviors for mission/safety critical functionality, while avoiding implicit state.

reddit_clone 2y ago

I forget its name, but there was an IBM graphical tool , with which you create UML diagrams and it in turn created code (Java IIRRC). The intermediate representation was in sexp !

reddit_clone 2y ago
Replying to my own comment. The tool was called "Rational Rose" !