Watch What I Do: Programming by Demonstration (1993)(acypher.com)
acypher.com
Watch What I Do: Programming by Demonstration (1993)
http://acypher.com/wwid/
10 comments
Programming by demonstration is a great forgotten technique for allowing end users to automate their common tasks and reduce repetition.
Auto-complete searches, intellisense, are known examples of PBD techniques illustrating their benefits.
Suggesting adequate parameters for commands, macro recording, command pipes... All these provide users some ways of building automated functions, without requiring them to learn the precise syntax of a programming languages.
Auto-complete searches, intellisense, are known examples of PBD techniques illustrating their benefits.
Suggesting adequate parameters for commands, macro recording, command pipes... All these provide users some ways of building automated functions, without requiring them to learn the precise syntax of a programming languages.
I still see papers published every year on PbD (though I agree the idea still hasn't really taken off).
I've been impressed by the recent Helena/Rousillon project for automating web scraping and other browser-based tasks: http://helena-lang.org/
I've been impressed by the recent Helena/Rousillon project for automating web scraping and other browser-based tasks: http://helena-lang.org/
Thanks for showing this, I didn't know web scraping came this far. And here I am, writing my own scraping scripts :P
I learned C# from watching Scott Allen's MVC 3 course on PluralSight years ago.
The best part about his videos was that he would purposely avoid using the pre-scaffolded boilerplate project templates, and would instead start with empty ASP.NET projects and build up an MVC solution from there.
Before I had even written a single line of code, I was able to keep up in conversations with guys who had been writing C# for a decade, because he was so thorough.
I learned more about patterns and structures from other folks like John Papa, but the fundamentals were all thanks to Scott's videos.
The best part about his videos was that he would purposely avoid using the pre-scaffolded boilerplate project templates, and would instead start with empty ASP.NET projects and build up an MVC solution from there.
Before I had even written a single line of code, I was able to keep up in conversations with guys who had been writing C# for a decade, because he was so thorough.
I learned more about patterns and structures from other folks like John Papa, but the fundamentals were all thanks to Scott's videos.
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.
- 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.
I just checked out that video about Demotivation. I instantly understood so much more about how demoscene videos work and how they are created. Amazing stuff. Thanks for that.
There's a universe of time to be spent enjoying all those tools for the creative soul.
Also: "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."
This!! Yes! My thought for the past 15 years or so. We've got an army of programmers (and general computer/phone users) pushing the cart with the square wheels for decades. Myself included. And this is about making those wheels just a little bit more rounded.
This is true on so many levels. Not just software tools. I mean we really can't come up with a better input UI than a mouse/keyboard/touchscreen? Wait, what? We're moving a cursor on a screen?! And the screen is flat?! Neuralink please end our suffering.
There's a universe of time to be spent enjoying all those tools for the creative soul.
Also: "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."
This!! Yes! My thought for the past 15 years or so. We've got an army of programmers (and general computer/phone users) pushing the cart with the square wheels for decades. Myself included. And this is about making those wheels just a little bit more rounded.
This is true on so many levels. Not just software tools. I mean we really can't come up with a better input UI than a mouse/keyboard/touchscreen? Wait, what? We're moving a cursor on a screen?! And the screen is flat?! Neuralink please end our suffering.
Great summaries, thanks!
Particularly the part about most "visual" programming languages just providing visual versions of fundamentally Fregean representations, meaning not actual analogs of the things they describe.
That seems to be a (the?) fundamental mistake that's being made over and over again: we think that what we want is to create a visual representation, when what we really want is an analogical one. For some reason we equate visual with analogical. Now that's not 100% wrong, a really good analogical representation can and often will be visual, but that doesn't mean that just making it visual will also automatically make it analogical.
Particularly the part about most "visual" programming languages just providing visual versions of fundamentally Fregean representations, meaning not actual analogs of the things they describe.
That seems to be a (the?) fundamental mistake that's being made over and over again: we think that what we want is to create a visual representation, when what we really want is an analogical one. For some reason we equate visual with analogical. Now that's not 100% wrong, a really good analogical representation can and often will be visual, but that doesn't mean that just making it visual will also automatically make it analogical.
Thanks for writing this, I'll bookmark it to delve into the book when I have some time.
Neat timing on this article too. While this isn't a live demo of coding, I just published a 90 minute live demo today where I go over the process of planning out a substantially sized web app I'm going to be developing. The video is just a non-stop thought process of me figuring out how the app will work (struggles included). It's available at: https://nickjanetakis.com/blog/live-demo-of-planning-a-real-...
This is the first time I tried something like that. If anyone watches it, I'd really like to know what they thought. The only problem with live demos and really getting into the thick of it is the videos end up being a lot longer than a highlight reel that was made after the fact and only showed the interesting parts.
For me one of the biggest wins of a live demo is being able to see the true process, because that's what allows you to figure out how to apply it to your own project / work / etc..