4 ms·

I believe that a visual programming environment or state visualizer for concurrency will be essential for a next generation programming language. The need to be

I believe that a visual programming environment or state visualizer for concurrency will be essential for a next generation programming language. The need to be filled is the need for representing many dimensions of computation simultaneously. It's 2020 and you've just written a program to run on 1024 machines with 1024 cores each. How do you reason about that?

barrkel 16y ago
How do you visualize a subspace delimited as segments in 1024 axes? Visualization doesn't scale in this way. You need to focus on the small, and have strong and reliable guarantees about those fundamental particles; combined with a safe and reliable way to compose those particles, and combinations, and so forth. You need proofs, and easy ways of asserting that certain properties are true, with help from the machine such that it can tell you - for certain - whether your assertion is true or not for all possible numbers of threads. Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.
- silentOpen 16y ago
  You certainly don't make each processor or core a dimension if that is what you are suggesting. The small is type systemic. Machine proofs show that you have written your typable logic correctly. This is still not at the level of concurrency or machine assistance to which I am referring. You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed. Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references. Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends. Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.
  - barrkel 16y ago
    > In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor This has been in the future for at least 30 years, by my knowledge of the literature. In fact, it's been in the future for so long by now that it seems to be in the past, by my reckoning.

barrkel 16y ago

How do you visualize a subspace delimited as segments in 1024 axes? Visualization doesn't scale in this way. You need to focus on the small, and have strong and reliable guarantees about those fundamental particles; combined with a safe and reliable way to compose those particles, and combinations, and so forth. You need proofs, and easy ways of asserting that certain properties are true, with help from the machine such that it can tell you - for certain - whether your assertion is true or not for all possible numbers of threads. Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.

silentOpen 16y ago
You certainly don't make each processor or core a dimension if that is what you are suggesting. The small is type systemic. Machine proofs show that you have written your typable logic correctly. This is still not at the level of concurrency or machine assistance to which I am referring. You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed. Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references. Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends. Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.
- barrkel 16y ago
  > In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor This has been in the future for at least 30 years, by my knowledge of the literature. In fact, it's been in the future for so long by now that it seems to be in the past, by my reckoning.