by techplex on 4/3/22, 12:14 PM with 57 comments
by m_mueller on 4/3/22, 7:12 PM
Having one more dimension for give meaning to is awesome, and there are many brilliant ideas in there. IMO it‘s a great shame it hasn‘t (afaik) yet been fully realized.
by sedatk on 4/3/22, 8:08 PM
For example, the tree structure shown in the demo is essentially a navigation tree we're accustomed on every IDE today. Such a view didn't exist 30 years ago, but we take it for granted now. A file system layout may not always reflect the actual dependencies, but it usually reflects categorical relationships. Most IDEs also provide a type hierarchy view now which you can use as an alternative.
Similarly, there are now features for peeking to definition, "teleporting between types", having multiple windows laid out on the same IDE, multiple window support. We're slowly getting better tools to travel the source code.
At the same time, our need for grasping the full source code map has been getting less important too. Prevalence of refactoring and package management tools mostly do the work for you: they work the map, and hide the irrelevant parts.
Not to mention tools like Excel which have always been visual since forever. For some reason, many advocates of visual programming are obsessed with a certain specific Johnny Mnemonic representation of it. But, it doesn't have to be. It can coexist with our existing tools, and evolve over time, which is what's been happening so far.
by zozbot234 on 4/3/22, 2:36 PM
by jcelerier on 4/3/22, 1:25 PM
but they absolutely didn't ? there are entire industries based around VPLs. if you go in most music conservatories in france, you can take a cursus in computer music where you'll likely be learning Max/MSP (https://images.squarespace-cdn.com/content/v1/542ee0e5e4b0e1...) for instance just like you'd learn bassoon or trumpet.
Likewise, every year you can look for the twitter tag #nodevember where artists present what they did in mostly node-based VPLs, like the ones provided by Blender, Houdini, etc.: https://nodevember.io/
There are 200k posts tagged #touchdesigner on instagram: https://www.instagram.com/explore/tags/touchdesigner/ and that's only a small fraction of things
There are more LabVIEW job postings when searching on Linkedin on my country than Rust and Golang COMBINED, by quite a margin (2400 for LabVIEW, 300 for rust and 800 for golang).
It looks like there's a huge "dark matter programmers" effect at work here :)
by ps901 on 4/3/22, 6:25 PM
by Tozen on 4/3/22, 4:05 PM
I wouldn't say that is the case, because Scratch is quite popular (for example) and hangs around 20th among programming languages on the TIOBE index. If you look at the RPA world, UiPath promotes itself as a Visual Programming tool, and it's quite popular as well.
However, there are some who complain about UiPath's "boxes on top of boxes". It tends to obscure being able to reason about the code and see important details, which gets hidden under other boxes. And you have to do a lot of typing anyway.
The criteria for what it means to be a success as a VPL, is arguably inappropriate, if you are saying it must be in the top 10 of programming languages. VPLs can and have found various niches, which might be the best they can do, for now.
The problem with VPLs is often "visual overload", where at a certain level of complexity, you are dealing with an entangled spider-web, twisted spaghetti, or straight up clusterf*ck.
Also, not quite sure what the insistence on little lines for many creators are all about, which only makes devolving into eye burning spaghetti only faster. People usually don't want to deal with such a mess, thus rather read or type out the code, so they can have greater clarity and readability. In addition to that, many of us are used to reading and typing.
Consequently, it might be argued that an collapsible outline is a better way to represent code. After all, we often do this when typing (books, PowerPoint, etc...). Particularly when dealing with the imperative or functional styles, which may lend themselves better to being represented in that way, where names can be headings. Probably you want to be able to easily hide or expand to more complex representations.
It seems to me that any VPL will not be able to beat typing out code for the majority at any time in the near future. Still, at the simpler levels or for the younger, Scratch shows that certain VPLs can be usable and find a place. Maybe the way forward is to build on what has had some success, and figure out how to make it more visually manageable.
by minaguib on 4/3/22, 3:24 PM
This is also a great example where I can perfectly see VR/AR shining and perhaps indispensable in this particular use case.
by yzan on 4/3/22, 6:14 PM
by dj_mc_merlin on 4/3/22, 5:39 PM
Do you want to get a quick overview of the codebase?
git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10
Now look at the top files and read them in their entirety, then read whatever important stuff they often reference. You now know 80% of what you need without having to bust out the research grade diagrams.
by loloquwowndueo on 4/3/22, 1:43 PM
I don’t know - I like reading others’ code, I learn a lot from it and makes the code I do write a bit better.
Of course writing code is easier - you’re expressing what’s in your mind. Reading what others wrote is hard because it’s a reflection of what was on their mind but it will help you understand them more.
by jupp0r on 4/3/22, 3:26 PM
Once I have a mental model of the parts I’m working on in my head, fuzzy keyboard based navigation (cmd + shift + o in vscode) works best for me to jump between parts of the code base, but it admittedly takes some time (a day or two) to get to that point.
It gets much harder in projects that are unintuitively structured for historic reasons or because the maintainers never cared to pay attention to this.
A good example in my opinion is the Chromium code base where I spent considerable time over the last couple of years while working on an electron app and which has an excellent code navigator at https://cs.chromium.org.
by mamcx on 4/3/22, 6:55 PM
> Why is it so? An old adage tells us “A picture is worth a thousand words” and intuitively we know that text is clearly not the best way to represent everything. All those bright minds working on the visual programming languages were clearly onto something, but seems like we are missing something essential to make visual programming a reality.
Yeah, that "missing something essential" is not see that write text IS VISUAL. The examples comparing graphs and text show how much BETTER is the text side.
“A picture is worth a thousand words”
is more about how much you talk, and bam, you can show instead. You can do that with TEXT. I will summarize EVERYTHING in a single char:
∞
Done.
See? Programming is using text because text is VERY visual. Fonts are different shapes, sizes, colors, bold, italic, etc: That is a lot of visualization!
Combine with ways to do hyperlink and all that and you get something very powerful.
---
What is the real problem, IMHO, is that there are not much advance in how leverage the rich information that a compiler infrastructure has until recently (with things like language serve protocol, tree-siter, error with diagnostics, etc), and archaic editors with SUB PAR environments (shell, vim, ...) are terrible places to do nicer!
And this critique account for the fact that most are not even on par with TurboVision or FoxPro DOS!
And this combine with the fact some languages (like C) are so bad that is VERY hard to "analyze them", because if the compiler get confused and output thousands of errors then you can't make it better with fancy graphics.
In other words: You need to align everything to make the idea work great.
This is not novel: We already have in the past much better implementations like hypercard, smalltalk, fox pro, borland pascal, etc
by 0des on 4/3/22, 9:38 PM
by devmunchies on 4/3/22, 5:10 PM
by hacknews20 on 4/3/22, 5:56 PM
by lvl102 on 4/3/22, 6:29 PM
by User23 on 4/3/22, 2:49 PM
by yboris on 4/3/22, 7:47 PM
I thought it would be useful for me, especially while working using the functional programming paradigm.
by hoosieree on 4/3/22, 2:37 PM
But... it's actually useful! This is a big step forward for visualizing source code, in my opinion.
by ed-209 on 4/3/22, 6:09 PM
Go is especially well suited for this activity (disagree but irrelevant).
We can leverage 3D modeling to better facilitate this mapping process. Also it could be VR. Also we could reverse engineer these models from existing code (awesome idea, do it please, and blend it with an IDE for when I drill down into nodes).
by chabad360 on 4/4/22, 12:16 AM
by schaefer on 4/3/22, 2:55 PM
