
Rethinking Visual Programming with Go - ValentineC
https://divan.dev/posts/visual_programming_go/
======
keyle
As someone who's heavily used Blueprints, I can tell you they really work. You
have no need to write a single line of code to program the behaviour of an
entire game including physics.

You do need C++ though if you're going to write stuff like A* pathfinding,
complex scene setup like hex based 3D platforms. Again it's all doable in
Blueprint and I'd often do it first in BP and then rewrite it in C++ for perf
sakes.

So visual programming isn't broken and it works, and not necessarily at DSL
level. The UX of the editor has to be fantastic though, for noobs as well as
experts. That means good support for quickly producing nodes, finding existing
code, refactoring support and Git support. You may think it's tedious but with
habits and patterns, with a few key stroke I could program an entire
component's behaviour in no time.

One thing that was magical is that with a heavy code base of visual nodes, the
brain can find entire sections very quickly, a bit like that cave analogy in
the article. You could group nodes with coloured rectangle etc. and the way
they were laid out you'd have instant recollection of its internal workings.
By seeing a vague layout of nodes I knew this was about joystick controller,
player controller, shader, etc. It's a massive advantage and takes less strain
on the brain to "READ" again the code. It makes code re-discovery so much
easier. If I had some gnarly behaviour it would instantly show in the pattern
of nodes as how they were laid out.

I'm convinced that if we had "as good" editor for web technologies, we could
produce microservices and front-end code in the exact same fashion without
writing a single line of code. It's just such a massive investment to _do it
well_ I don't see it happen any time soon.

~~~
pjmlp
Here is one, but usually only for customers with enterprise pockets.

[https://www.outsystems.com/developers/](https://www.outsystems.com/developers/)

~~~
Crinus
The "enterprise pockets" requirement usually ends up with (practically) nobody
learning it themselves, nobody knowing about it, nobody knowing how to use it
and nobody considering using it.

Any programming tool your average joe programmer cannot try for themselves in
their own computer might as well not exists nowadays and at this point it'd
only rely on how good the marketing drones of the development company are at
convincing non-programmers of other companies that they should use that tool,
which in turns means that the tool doesn't really have a need for actually
being good, just give that feel to whoever makes the decision to get it.

~~~
pjmlp
As enterprise developer, there are plenty of ways to learn such tools, and
make oneself tasty to many HR departments.

Just not the way many FOSS driven devs like to work, while not paying for the
tools they use.

Big boys club has a very different kind of rules, and politics for that
matter.

~~~
Crinus
If a developer cannot use these tools themselves they wont know them, in turn
they wont promote them to others, they wont propose them to companies, the
companies wont need them and they wont seek developers with knowledge of those
tools and as a result knowledge of those tools wont be "tasty" to many
companies.

The only way to break this dependency loop is to convince non-developers
(executives, etc) to use those tools but at that point the incentive shifts
from making those tools good for use by developers to making those tools good
in convincing non-developers to buy them.

The only "big buys club" i see working on here is one of people who couldn't
learn something else.

You should already have seen this with Turbo Pascal and Delphi and how these
products moved from cheap $50-$100 products even students could afford and
focused providing a simple yet comprehensive package to grossly priced
overbloated, hype-driven, bullet-point executive-presentation-friendly
monsters with tons of bugs and an over-reliance on bundling 3rd party
components. And how this sort of move made their products instead of being
widely known and loved by developers to become relics that only stay alive
because their owners are preying on those who at the past chose them (because
they were good at the time) and cannot move off.

~~~
pjmlp
True I have seen it happen with Turbo Pacal/Delphi, but the biggest issue
there was Borland almost going broke and continuous change of hands, which
destroyed the trust on the product.

There aren't "toy" versions of Cisco, Oracle, DB2, SQL Server OLAP, Sitecore,
AEM, LifeRay, WebSphere, SAP, Hybris, PTC, Aicas, Ricoh JVM, Gemalto M2M, ....

And yet there are plenty of projects available to work on with those stacks,
including green field projects in companies adopting them.

~~~
Crinus
Borland was going broke because they abandoned their core target market for
chasing after the enterprise - and that was during a time before open source
even got its name and developers expecting tools for free was a thing.

And have you seen the reputation these systems you mention have among
developers (assuming they know about them, after all my original point was
that the "enterprise pockets" requirements lead to obscurity - with the
obvious exception of those that have been around for a very long time) and how
clunky they are? Turbo Pascal and early Delphi never had the reputation that
Oracle has nowadays.

And sure, you can find works with them but these systems are a minority and
when they are used they are practically never chosen by developers themselves.

~~~
pjmlp
The reputation among FOSS devs sure.

I have been working in enterprise world since 1999, where most folks don't
even know that HN exists.

They don't even think twice about buying something like Oracle.

~~~
Crinus
I'm not sure i follow, you mean that only FOSS devs dislike stuff like
Oracle's?

~~~
pjmlp
Mostly.

------
turbinerneiter
> At least I’ve never seen properly conducted studies involving psychologists
> or neuroscientists upon introducing yet another new fancy feature into a
> programming language.

I studied Mechanical Engineering, but did my Master Thesis on "Evaluation of
MicroPython as Application Layer Programming Language on CubeSats"* - way out
of my depth.

I tried to find some prior work on how to chose programming languages for
specific domains, and how to judge if a language is the right tool for a task
- and there wasn't much.

I even tried to measure how "easy" a programming language is, in a hilariously
misinformed user study. There were 8 people, I was measuring the time it took
them to implement small snippets in Python vs. C. I had this one dataset with
weird outliers, where a person who performed really well, just took forever
for some of the tasks ... later one of the participants told me he texted
during the study.

And although I felt really bad about my really bad study, I also felt like the
avantgarde of the field^^

Anyway, if we can find someone to fund it, I'd like to see brain activity
scans of programmers using different languages. We already know smartphone
usage rewires our brains. I wanna see the brain of JavaScript developer
compared to a Lisper, Rustacean, ... .

* conference paper: [https://www.researchgate.net/publication/319525786_Evaluatio...](https://www.researchgate.net/publication/319525786_Evaluation_of_MicroPython_as_Application_Layer_Programming_Language_on_CubeSats)

~~~
Seanny123
The Qorum people have been doing psychology-informed Programming Language
Design for a while now.

[https://quorumlanguage.com/evidence.html](https://quorumlanguage.com/evidence.html)

~~~
turbinerneiter
That would have been great input for my thesis!

~~~
Seanny123
As someone who also completed a Master's thesis, I really hope that feeling
goes away at some point.

~~~
turbinerneiter
Not if liked our topic and would like to do more work like that :)

------
beders
I like the distinction between spatial and temporal aspects of programming
languages. I'm wondering if the author knows Lisp though, which helps
translating between those two views of code in important ways (like
Homoiconicity).

Also, when trying to understand code, we typically run a simulation of that
code in our head. Since we have limited capacity doing so, having a simple
flow with simple data is helpful. If we hit the limits of our internal code
processing capabilities, we are switching to a different mode:
Experimentation, supported by tools.

In non-interactive languages that typically is a 'unit' test or a sample app
or a debugger.

In interactive languages it is the REPL. A REPL allows you to experiment with
the mental models we acquired from reading the code. Confirming hypotheses by
letting the machine run experiments, validating the outcome, deepening our
understanding of the code.

This is where I see visualization being most useful. Show the data before our
hypothesis, show the data after we've run the experiment (i.e. v'=f(v)). Not
just the type of data.

That's where I'd like to see better tools. (One example of this I'm currently
using is re-frame-10x, which shows data epoch oriented and has neat diffs of
what changed when an event was processed (i.e. time has moved forward).

~~~
jmiskovic
I find it baffling that Lisp is still written in text. It's pure AST, so it's
easy visualize and manipulate it as a tree. Small trees (definitions of
functions and data structures) are composed into big tree that forms
application. Why not do all development work (reading/writing) on this tree
directly? In my view the Lisp should be first candidate for visual
programming.

Agreed, re-frame and its tooling is awesome. BTW is there any way to drop into
REPL from context of event handler?

~~~
Retra
I don't understand your surprise. Text has many compatibility, readability,
and uniformity advantages. How are you going to diff a tree? How are you going
to make the display consistent across platforms & tools? How are you going to
represent the details of the program?

In the end, you're still just projecting abstract objects onto a 2d plane, and
text already does that in a maximally flexible way. Anything else is less.

------
shabbyrobe
The author of this post is also the author of the fantastic "Visualizing
Concurrency in Go" [1] article.

[1]:
[https://divan.dev/posts/go_concurrency_visualize/](https://divan.dev/posts/go_concurrency_visualize/)

~~~
erikig
Thanks for sharing this. It is pretty intuitive and quite helpful for
developers that are visual thinkers to see what go is "doing"

------
currywurst
To get to the next level and scale of bigger programs, you need to leverage
the tons of work information visualization researchers have done.

I always point people to Prof. Tamara Munzner's work[1][2] that allows you to
skip over all the dead ends that people have tried over the decades and gives
you a "thinking framework" on how to design visualizations.

[1] VIZBI 2011 Keynote: Visualization Principles
[https://vimeo.com/26205288](https://vimeo.com/26205288)

[2] Visualization Analysis and Design (Book)
[https://www.crcpress.com/Visualization-Analysis-and-
Design/M...](https://www.crcpress.com/Visualization-Analysis-and-
Design/Munzner/p/book/9781466508910)

~~~
everybodyknows
Index of Munzner's scholarly work:

[https://www.semanticscholar.org/search?q=%22Tamara%20Munzner...](https://www.semanticscholar.org/search?q=%22Tamara%20Munzner%22&sort=relevance&fos=computer-
science)

------
goto11
Visual programming have been quite successful in some constrained domains. The
fundamental imitations is that visuals does not represent arbitrary levels of
abstractions very well. The visual way to represent abstractions is symbols
(e.g symbols on a map), but when you go a level deeper to create symbols
representing other symbols, then you end up with text.

~~~
blablabla123
Yeah, I've tried a handful of visual programming tools in the 90s before I got
fluent in a normal programming language. It seemed very easy to start with the
first steps and it was motivating how all the possibilities seemed to be one
click away. But in reality the fun stopped really quickly and getting further
would require deep understanding of the tool, i.e. reading a lot of -
incomplete - documentation.

Another tool, I forgot the name but it's used in certain parts of science, in
particular it at least used to be in use at the LHC. It seemed quite complete
but complex things would easily be difficult to see, at least in the short
time I did something with it.

IMHO Borland Delphi is the furthest visual programming went so far. I never
really understood why IDE developers didn't pursue that path any further. (I
know there's still a Delphi but almost nobody uses it.)

~~~
Retra
It seems you understand why perfectly well: it's a lot of work to do for
little actual benefit.

>Another tool, I forgot the name

I suspect you might be referring to labVIEW?

~~~
blablabla123
Yeah probably. Still this is something I think of, also wondering whether
eventually programming might become commoditized by new tools. So the question
was already asked by other commenters, maybe there's an argument on can make
why this won't work.

Yes, I do. :)

------
skybrian
This article seems to be mostly ignoring what's going on in the sidebars of a
decent IDE: file explorers, outlines, type hierarchies, and so on. These are
pretty decent ways of getting an overview and navigating a codebase.

There may be a way to do better, but it seems unlikely to be a bunch of
abstract nodes and straight lines between them, whether in 2D or 3D.

------
errnoh
Interesting topic. I haven't gone as deep in this rabbit hole but I've also
written "similar" tool that I've used as a visual help [1] when reading
programs written by other people. It's been useful in understanding
bottlenecks and weird code patterns / dependencies. I've even printed the
graph sometimes and written down notes on the paper, drawing circles around
logical groups, etc.

I ended up going with separate color for each type / package.

[1] Screenshot of a simple piece of code:
[https://imgur.com/a/Pr9dkkd](https://imgur.com/a/Pr9dkkd)

~~~
divan
Nice. I've been doing similar drawings a lot – on whiteboard, on paper, on
tablet, a few times even drawing them to use as the argument in pull-request
debates, because words weren't enough to show the point.

------
vanderZwan
> _The brain handles them very differently on the lowest level, but what’s
> interesting is that we can use spatial representation to represent temporal
> information and vice versa, and, actually, often do precisely that._

The author of this article would probably really enjoy diving into research
regarding sign languages, which are by there very nature both spatial and
temporal languages - in other words: _kinematic_ languages.

------
a3n
I notice most of the article is written in straight text, rather than
visually.

~~~
divan
I got the pun, but that's actually interesting point. Natural text also has
both spatial and temporal components: when you read fiction, some paragraphs
describe the scene, the character, the relationships, and others – how they
evolve, change and interact.

For this reason, I sometimes enjoy watching movie before I read the book it's
based on – the movie (visualization) so much better and showing how things
look like, while text is still superior in following the story, living
development of characters and so on.

So in this article I used graphics a lot – and even more so in the original
slides. I actually had to write WebGL programs to show that visual aspect.
That's one of the things that frustrates me a lot – it's so hard to just
visualize what you mean, without being professional animator or programming 3D
scenes. I'd love it to be as simple as writing a post on social network.

Textual literacy is still orders of magnitude more accessible, cheaper and
widespread.

------
ginko
But programming already has zoom levels. It's called abstraction.

~~~
coldtea
Yeah, and similarly we don't need hot sauces when we eat out at noun, because
there's already something hot available: the sun.

~~~
geodel
Did you mean 'noon' or I missed the joke?

~~~
pkroll
You're likely correct, though there have been restaurants named "Noun" in the
world. (Mostly closed, but one still open in Cannes.)

------
holychiz
Outstanding post. Author might find it interesting to partner up with game
designers on visually representing massive amount of data for quick grok by
the masses.

~~~
divan
Thanks! Yep, you're reading my mind - I'll definitely need gamedev experienced
brains to move this forward)

------
bsaul
i don’t think visual representation of structure is actually the hard part.
Logic and computation seems to me is the only difficul part. We’re still
writing cooking recipes the same way , using lines of text, even if the
ingredients are extremely easily represented with images or icons.

~~~
divan
Fair point. I don't see how to outperform text in expressing logic and
computation visually either.

The problem here is a scale – what works for cookie recipes, doesn't work for
"recipe" on how to build a Boeing plane, for example.

~~~
bsaul
absolutely. It seems that inevitably you’ll have to abstract a pack of
computation under a single concept representing what the computation is
globally about.

hence the general focus on isolation , interface and composability.

Once you’ve abstracted a set of computation under a good concept , you should
be able to understand it using just a name.

------
EdiX
I think the cave and torch metaphor is underselling me on my editor's ability
to have split windows.

~~~
everybodyknows
Split windows, plus regex pattern search of a set of files themselves selected
by pattern, together well satisfy my own code abstraction needs.

Examples of the latter are Emacs' 'multi-occur', and Unix command line
pipelines of the form:

    
    
      locate -0 /\*descriptive_substring\*.go |
        xargs -0 grep -E 'regex'

------
p2t2p
DRAKON flew and landed Buran. I wouldn't count it as failure.

