2 Matching Annotations
  1. Mar 2023
    1. Most data flow programming environments cannot represent lambdas, and this is why the graphs always end up turning into spaghetti: you don't actually have tools to reduce repetition in the graph's structure, using the graph itself.They are successful in artist and music contexts because the graphs tend to be simple pipelines at heart. Having dealt with sufficiently complex grasshopper graphs, I disagree that it's good at arbitrary list processing, certainly compared to ordinary list operators and iterators in code.My conclusion is that a dataflow environment that does allow for lambdas and proper n-way forking would necessarily have to be an effect system in the FP sense. It's a data flow graph that computes its own continuation and which has no fixed or preset topology. It can rewire itself based on the data flowing through it.

      Quizás por eso es que se requiere la programación multimodal, simbólica, icónica y enactiva, entre otras. Las ventajas de un modo, compensan las desventajas de otro.

    2. Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.Visualize data, not code. Dynamic behavior, not static structure.”http://worrydream.com/#!/LearnableProgramming

      El asunto es que debido al homomorfismo, el código puede ser visto como datos y viceversa. Las mismas técnicas empleadas en visualizar el uno pueden ser usadas en los otros, como de hecho ya hemos experimentado varias veces en la comunidad de Grafoscopio a través de las narrativas de datos.