A couple of valuable takeaways from chapter 1 for me:

- Explains what PBD is all about.

- "many mathematicians and physicists think visually and reduce their thoughts to words only reluctantly to communicate with other people". I've found that this holds true for myself as well, both when thinking about maths problems and in thinking about algorithms for my software. This is why I believe in the concept of visual programming.

Several tools made for music production, creation of computer generated imagery and animation base a lot of the workflow around working visually. For example:

* Max, a visual programming language for music and multimedia. https://cycling74.com/products/max/

* Pure Data, an open source visual programming language for creating interactive computer music and multimedia works. https://en.wikipedia.org/wiki/Pure_Data

* VCV Rack, an open source virtual modular synthesizer. https://vcvrack.com/

* Blender, an open source 3D modeling, animation and rendering program has a material editor where you create a material by routing basic materials through a set of nodes. https://docs.blender.org/manual/en/latest/render/blender_ren...

* Nuke, a compositing software that is widely used in the VFX industry, has a node-based workflow. https://learn.foundry.com/nuke/content/getting_started/using...

* Natron, an open source composting software. Development stopped last year and they are currently in need of a maintainer. http://libregraphicsworld.org/blog/entry/the-demise-of-natro.... https://natrongithub.github.io/

* Tool2, an open source piece of software for creating interactive 3d content and animations. http://tooll.io/

* Cables, "interactive visuals, made from cable salad". https://cables.gl/

* Demotivation, a tool by Ferris of demoscene group Logicoma, provides a visual programming language that compiles to a function that renders everything on screen in the demos created with the tool. Ferris talks a bit about it in https://youtu.be/hFIyj5Yv440?t=1332, and he also worked on the code in a recent stream on Twitch which he hasn't uploaded to YouTube yet; https://www.twitch.tv/videos/419371333 (Ferris Makes Demos Ep.052 - Botch. Skip to 00:07:41 in the video on Twitch). This tool is not available to the public.

I think a couple of other pieces of software deserve a mention for being ways to work very visually with music production in various ways:

* Steinberg Cubase, a digital audio workstation. https://new.steinberg.net/cubase/

* Ableton Live, a digital audio workstation. https://www.ableton.com/en/live/

* Arturia Pigments, a wavetable and virtual analog software synthesizer. https://www.arturia.com/products/analog-classics/pigments/ov...

And in the world of game development there is of course:

* Unreal Engine 4, a game engine and suite of integrated tools for designing and building games, simulations, and visualizations, features a visual programming language called Blueprints. https://docs.unrealengine.com/en-US/Engine/Blueprints/Gettin...

Those are the ones that I personally find inspiring. There are a couple of visual programming tools that I don't mention here but which I felt fell way short of being even remotely productive.

So back to what was being said in the book linked by OP. A couple of quotes:

- "Aaron Sloman distinguishes two kinds of data representations: analogical and Fregean (after Gottlob Frege, the inventor of the predicate calculus). Analogical representations are similar in structure to the things they describe; Fregean representations have no such similarity." (Goes on to show a figure demonstrating the difference.)

- "Words are Fregean. Yet words and rather primitive data structures are often the only tools available to programmers for solving problems on computers. This leads to a translation gap between the programmer's mental model of a subject and what the computer can accept. I believe that misunderstanding the value of analogical representations is the reason that almost all so-called visual programming languages, such as Prograph, fail to provide an improvement in expressivity over linear languages. Even in these visual languages, the representation of data is Fregean."

I find this very interesting. This is pointing out a very specific problem.

I went on to read chapter 3 as well, and found that chapter interesting as well. Not going to comment on that chapter because this is enough text anyway for now.

I intend to read more of the chapters as well.

All of this is to say, this book seems to hold some valuable knowledge, and I wish people read it. The book seems to focus a good deal on empowering end-users, and on teaching-contexts. That is a worthy goal as well but not what I am interested in (hence why I skipped reading chapter 2). But from what I have seen so far I think this book might help guide us toward creating better tools for expert programmers.

We need tools that help us manage complexity better than what we have today. We need tools that will help us iterate faster. And I believe that tools that give us ways to reason about our problem visually as we are authoring and editing our software will be key. Not as separate drawings and documents. As an ingrained part of development. As a way of communicating to the machine what we are trying to achieve with our software.