[deleted]
We need visual programming. No, not like that
51–60 of 505 posts
Re: We need visual programming. No, not like that
#52I just want an IDE that abstracts my code just enough so that I can work with tokens, not individual characters. I spend way too much time fixing syntax and formatting when moving things around.
You're using the wrong ide then - any serious ide will do exactly that (have an ast representation that it uses for refactoring). Eg jetbrains ides do.
Re: We need visual programming. No, not like that
#53Where is the example of the “ very nice visual programming language” he gave from?
Re: We need visual programming. No, not like that
#54The first link in the "Codebase visualization" section is broken. The linked talk is intended to be C++Now 2018: Eberhard Gräther - The Untapped Potential of Software Visualization, available at https://www.youtube.com/watch?v=fnIFVYFspfc
Thank you! Should be fixed in a minute
Re: We need visual programming. No, not like that
#55> Developers say they want "visual programming", which makes you think "oh, let's replace if and for". But nobody ever made a flow chart to read for (i in 0..10) if even?(i) print(i). I'm not convinced by this particular example. Wouldn't a visual programming language just represent the logic here as a pipeline connecting two more atomic operations: you'd have a visual representation where you pipe the (0..10) range…
It is certainly possible and that is how most of these visual languages do it. But is that how _you_ want to program that logic?
Re: We need visual programming. No, not like that
#56Earlier quoted context omitted.
Swimlane diagrams are from the 1940s[0]. IGrafx trademarked it in 1996. They're often used to model process' that span people, roles or security boundaries [1][2][3]. Sequence-diagram participants[4], and gantt-sections[5] are sometimes used to represent the same. [0]: https://en.wikipedia.org/wiki/Swimlane [1]: https://swimlanes.io/ [2]: https://www.lucidchart.com/pages/tutorial/swimlane-diagram [3]: https://www.dra…
another good one is https://sequencediagram.org/
Thanks to both of you!
These are useful resources.
I have always illustrated my systems and interactions, but have seldom used formal methods. I would use them, if they are required, but usually find that my subsets are more useful.
I did use “Booch Blobs,” back in the day, followed by UML, but always ended up using a tiny subset of the spec.
Re: We need visual programming. No, not like that
#57[deleted]
Re: We need visual programming. No, not like that
#58It seems odd to me not to mention things like MaxMSP or PD in an article like this. Arguably Max is one of the most successful standalone visual programming languages (standalone in so far as it’s not attached to a game engine or similar - it exists only for its own existence).
Those two are both primarily for real time signals and music right? That is a great domain for wires, transforms, and pipelines.
Have you ever seen them used in a different context?
Re: We need visual programming. No, not like that
#59I am surprised I have not seen LabView mentioned in this thread. It is arguably one of the most popular visual programming languages after Excel and I absolutely hate it.
It has all the downsides of visual programming that the author mentions. The visual aspect of it makes it so hard to understand the flow of control. There is no clear left to right or top to bottom way of chronologically reading a program.
Re: We need visual programming. No, not like that
#60Earlier quoted context omitted.
Specifically, textual programs use symbols to build a graph of references between computations, where the average visual language tries to use explicit lines between blocks. But the reference graphs of non-trivial programs are often decidedly non-planar, which only becomes a problem when you try to lay them out on a plane.
Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?
The spatial reasoning on reading code does not happen on the dimensions of the literal text, at least not only on these. It happens in how we interpret the code and build relations in our minds while doing so. So I think that the problem is not about the spatial reasoning of what we literally see per se, but if the specific representation helps in something. I like visual representations for the explanatory value they can offer, but if one tries to work rigorously on a kind of spatial algebra of these, then this explanatory power can be lost after some point of complexity. I guess there may be contexts where a visual language may be working well. But in the contexts I have encountered I have not found them helpful. If anything, the more complex a problem is, the more cluttered the visual language form ends up being, and feels overloading my visual memory. I do not think it is a geometric feature or advantage per se, but about how brains of some people work. I like visual representations and I am in general a quite visual thinker, but I do not want to see all these miniscule details in there, I want to them to represent what I want to understand. Text, on the other hand, serves better as a form of (human-related) compression of information, imo, which makes it better for working on these details there.