4 ms·

Same boat, checking in. My notebooks are full of scribbles even though I do lots of non-visual programming. It’s my primary thinking aid. I’ve found this to wo

by klabb3 4y ago

Same boat, checking in. My notebooks are full of scribbles even though I do lots of non-visual programming. It’s my primary thinking aid. I’ve found this to work out well for me: - Use languages and tools that let you defer correctness while prototyping. I lose track of “the bigger picture” if I have to context switch to thinking pedantically about syntax and type systems. That’s ok when everything is in place, but is disruptive when experimenting. - Find good visualization aids, such as sequence diagrams, dependency trees, call graphs etc. Even if you just do it on paper, they can be great tools. - Read up a bit about dataflow programming. It fits my brain very well, and you can apply the thinking in any language. (Unfortunately existing dataflow oriented programming environments are quite limited and come with other downsides). Let me know if you have tips to share as well.

TuringTest 4y ago
Yeah, I've worked with dataflow languages and they're a very good fit for data transformations (not so much for complex runtime control flow). Functional-reactive languages like spreadsheets also make it way easier to reason about than imperative programming. I like environments where you can keep visualization aids close to the code to which they apply; nowadays, that means using online notebooks a la Jupyter and ObservableHQ, or at least markdown files with a preview plugin integrated in your IDE. There you can represent diagrams as code, like Graphviz and Mermaid. I long for the day that those visual representations can be accessed programmatically and used as part of the code itself, like VB6 interactive widgets were created graphically yet usable in the application; e.g. creating state machines visually by representing states and transitions as boxes and arrows, then compiling the diagram to add conditions and access their values from code (there are some libraries doing this in some environments and languages, but I'm not aware of one that is portable to many languages). I think we're really close to that being possible with modern languages.

by klabb3 4y ago

TuringTest 4y ago

Yeah, I've worked with dataflow languages and they're a very good fit for data transformations (not so much for complex runtime control flow). Functional-reactive languages like spreadsheets also make it way easier to reason about than imperative programming. I like environments where you can keep visualization aids close to the code to which they apply; nowadays, that means using online notebooks a la Jupyter and ObservableHQ, or at least markdown files with a preview plugin integrated in your IDE. There you can represent diagrams as code, like Graphviz and Mermaid. I long for the day that those visual representations can be accessed programmatically and used as part of the code itself, like VB6 interactive widgets were created graphically yet usable in the application; e.g. creating state machines visually by representing states and transitions as boxes and arrows, then compiling the diagram to add conditions and access their values from code (there are some libraries doing this in some environments and languages, but I'm not aware of one that is portable to many languages). I think we're really close to that being possible with modern languages.