Folk wisdom on visual programming • Hacker News Board

Re: Folk wisdom on visual programming

#121

Post by auxym » Fri, Jul 02, 2021, 12:04 PM UTC

jcelerier wrote: post #98

bmitc wrote: post #82

Earlier quoted context omitted.

That’s true to a degree, but I think the discrepancy is still there. Experts in LabVIEW build up key commands to do things for them, and there’s even an ability to custom implement these using LabVIEW itself. Also, for some reason other fields seem to love these visual tools like TouchDesigner and Grasshopper. Programmers can be quite myopic when it comes to their programming preferences and perspectives. For tools t…

> Also, for some reason other fields seem to love these visual tools like TouchDesigner and Grasshopper. It's very simple - if you work with artists and you make them a presentation of your software, and at any moment there is some amount of code displayed on the screen, some of them will get up and leave the presentation. I worked on my software with someone who would literally refuse to use the keyboard - everythin…

> It's very simple - if you work with artists and you make them a presentation of your software, and at any moment there is some amount of code displayed on the screen, some of them will get up and leave the presentation.

Surprisingly, this is also the case for mechanical engineers. The proportion might be smaller, but they still exist. I know people in freshman classes that are retook the intro to programming class which was stuff like variables, conditionals and loops in Matlab.

Then there's people who did OK in their Fortran classes in the 1990s but never touched a line of cosey since.

The people have a good chance of being intimidated by code. This is where LabVIEW and Simulink come in.

Re: Folk wisdom on visual programming

#122

Post by w_t_payne » Fri, Jul 02, 2021, 12:11 PM UTC

im_down_w_otp wrote: post #65

w_t_payne wrote: post #40

Earlier quoted context omitted.

I've used Simulink a lot in the past, and the things that it gives you (as well as it's limitations) are a big driver for my attempts to build tools in this space (I think I'm trying to do a similar thing to you -- causal reasoning using data flow information and other graph-structured engineering data such as requirements traces).

Yeah, that's the first half of our stack. Ultimately it exists in service of the second half of our stack which is for automatically stressing and analyzing system behavior to localize root causes, uncover emergent properties, and auto-optimize system parameters. On the way toward building everything we needed for the analysis we wanted to do we realized we had a distributed tracing system suitable for continuous sys…

I'd love to have a chat at some point. I'm trying to (slowly) bootstrap some tools for the embedded space, and we're trying to get a grasp on (a) what our MVP should look like, and (b) how to go about approaching customer #1.

Re: Folk wisdom on visual programming

#123

Post by simonh » Fri, Jul 02, 2021, 12:11 PM UTC

hutzlibu wrote: post #120

simonh wrote: post #111

"A picture paints a thousand words, sure, but here's a thousand word essay. Try painting me a picture of it." I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things. Maybe eventually we'…

"Maybe eventually we'll arrive at a state where really good programming environments incorporate the advantages of both textual and visual tools in a powerful and dynamic way. " Yes, I agree. But not surprisingly, this is not easy to solve. You need a visual language as a consistent concept and then you need a actual visual framework, rendering it all, and enabling user input. You need a compiler compiling forth and…

I listened to a podcast a while ago where someone was speculating why programs processing data can't just be connected together like devices in a water system. Pumps, sinks, boilers, showers, etc. Or like electrical devices, just channel the data between them.

It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device. Data isn't like that.

Data formats and encoding vary hugely and can have crazy different properties. It's more like piping chemicals between devices in a chemical factory. You can't just take the output from a device producing acid and plug the pipe into the input of a device that's designed to process water, or ammonia, or petrol. They're all 'just' fluids and you can pipe them about, but their properties vary wildly. You can only feed one into a device as input if that device is specifically designed to process that specific material.

Yes it is possible to define standardised data formats, up to a point. XML, JSON, CSV, etc but even then you can't just feed arbitrary JSON into every program designed to ingest JSON and expect it to work, just because the data it expects is JSON formatted.

Yes Unix has pipes, but each tool in the pipe chain has to be told exactly how to process the specific input it gets from the previous tool. You can't just look in history for two arbitrary examples of using pipes, and cut and paste the first half of one pipe chain, and paste the second half of another arbitrary pipe chain on the end, and expect to get something useful out of the combination. Maybe you'll get lucky, but usually you'll get garbage.

Re: Folk wisdom on visual programming

#124

Post by auxym » Fri, Jul 02, 2021, 12:22 PM UTC

bmitc wrote: post #89

crispyambulance wrote: post #13

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them. There are NOT a "large number" of visual programming tools th…

In my opinion, LabVIEW is the most general purpose and powerful visual programming language. Others I know of are vvvv gamma where the recent update basically makes it a .NET language (although LabVIEW also has .NET integration) and Pure Data. Other tools are Simulink, TouchDesigner, Max/MSP, and Grasshopper for Rhino. After that, it drops off pretty rapidly to a collection of barely used or even known about tools pr…

Another example is ncode Glyohworks, which was used by a very large company I used to work for, for test data post-processing.

Re: Folk wisdom on visual programming

#125

Post by hutzlibu » Fri, Jul 02, 2021, 12:31 PM UTC

simonh wrote: post #123

hutzlibu wrote: post #120

Earlier quoted context omitted.

"Maybe eventually we'll arrive at a state where really good programming environments incorporate the advantages of both textual and visual tools in a powerful and dynamic way. " Yes, I agree. But not surprisingly, this is not easy to solve. You need a visual language as a consistent concept and then you need a actual visual framework, rendering it all, and enabling user input. You need a compiler compiling forth and…

I listened to a podcast a while ago where someone was speculating why programs processing data can't just be connected together like devices in a water system. Pumps, sinks, boilers, showers, etc. Or like electrical devices, just channel the data between them. It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by a…

"It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device."

Well, electricity is not really easy either. There is a huge effort, to transform the current in the needed shape (voltage, current, frequency, DC vs. AC, smoothened... And water is also not just water, as it can be clean drinking water, or sewage water, or hot (but slightly dirty) water for the heating, or you have hot, high pressured steam, ...

Not just coding is complicated ;)

Re: Folk wisdom on visual programming

#126

Post by auggierose » Fri, Jul 02, 2021, 12:50 PM UTC

akavel wrote: post #118

Mandatory fanboi mention, and IMO a gross omission of the article: https://enso.org/ (née Luna) - an open-source language & IDE which aims to insta-kill all the "vs. textual programming" arguments by keeping a strict 1:1 visual textual representation translation as a core feature of the language. A 2.0 alpha was recently released, go check it out!

Very nice. I am also currently building a new environment for programming (I want my 5 year old niece to get a head start on modern creativity :-)). I think the main idea is simple: logic + visualisation + data. Make something that takes all of these three things seriously. Programming languages usually care about the logic part only (and even that not very well).

Re: Folk wisdom on visual programming

#127

Post by hypertele-Xii » Fri, Jul 02, 2021, 1:34 PM UTC

simonh wrote: post #111

"A picture paints a thousand words, sure, but here's a thousand word essay. Try painting me a picture of it." I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things. Maybe eventually we'…

What if the painting could change? What if you could touch the painting and explore it interactively? What if the painting engulfed all your senses, creating the illusion that you're in the painting?

The journey of media from print to VR. While it'll certainly take more than 1000 words to program the painting in VR, if a million people see it, the value ratio is pretty good.

Re: Folk wisdom on visual programming

#128

Post by meesterdude » Fri, Jul 02, 2021, 2:19 PM UTC

Timothycquinn wrote: post #37

I wrote a spreadsheet based rules engine at Honeywell in around 2003 which enabled the business to maintain the business rules for all sales contracts that ran through the automation and control systems division. This gave them the ability to define forms, subsets of forms (legal or otherwise), notifications and approvals. I had its own natural language based expression language which the super users and business ana…

Neat! Seems like what's old is new again. I'm up to the same shenanigans (sans java, TCL and a graph database). spreadsheets are a great medium to provide non-technical people access to adjusting production with nuanced precision.

Re: Folk wisdom on visual programming

#129

Post by DonHopkins » Fri, Jul 02, 2021, 2:20 PM UTC

crispyambulance wrote: post #13

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them. There are NOT a "large number" of visual programming tools th…

If not a "large number", then more like a "huge number".

Even the single application Blender itself has several different visual node based programming systems (most but not all built on top of the same framework, and applied to different kinds of programming), for shader programming, CPU image processing, video compositing, lighting, animation and constraints, particle systems, physics simulations, procedural mesh generation, and the Blender Foundation and third parties are developing even more, like procedural city generation:

Procedural city generation:

https://www.youtube.com/watch?v=jb_jwsyfQc4&ab_channel=derbe...

Everything nodes:

https://code.blender.org/2020/12/everything-nodes-and-the-sc...

Nodes Workshop - 22 - 25 June 2021

https://devtalk.blender.org/t/nodes-workshop-22-25-june-2021...

>“It is like compositor but for physics”.

The complete beginners guide to Blender nodes, Eevee, Cycles and PBR:

https://artisticrender.com/the-complete-beginners-guide-to-b...

>Blender has a few nodes systems. The first and obvious one is Blenders shading system for Cycles and Eevee. This is the node system that we will focus on in this article.

>But we also have nodes for compositing, lighting and textures, even if the use case and future for texture nodes are uncertain at this point.

>We can also extend Blender with other node systems through add-ons. The most well-known is probably animation nodes that come bundled with Blender.

>There are also other node systems available for Blender. AMD ProRender for example, a third-party render engine that has its own shader node system. Another example is Luxrender. There is also mTree for generating trees with nodes and Sverchok that can manipulate all kinds of data with nodes.

Reposting this from a few years ago:

https://news.ycombinator.com/item?id=18496880

There's so much interesting prior work! I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems.

http://donhopkins.com/home/documents/taxonomy.pdf

It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before:

http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S...

I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher.

https://archive.org/details/visualprogrammin00shu_2pf

https://archive.org/details/watchwhatido00alle

Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32:

C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion

http://www.cs.cmu.edu/~bam/acronyms.html

Also, here's an interesting paper about Fabrik:

https://donhopkins.com/home/Fabrik%20PE%20paper.pdf

Danny Ingalls, one of the developers of Fabrik at Apple, explains:

"Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"

Re: Folk wisdom on visual programming

#130

Post by username90 » Fri, Jul 02, 2021, 2:21 PM UTC

jcelerier wrote: post #99

markus_zhang wrote: post #6

Earlier quoted context omitted.

But I also see some hate this style. This guy is an artist/programmer. https://forums.unrealengine.com/t/blueprints-are-a-toy-which... BTW I do agree visual programming makes sense in certain area, but to use it for a general scripting language? Hell no...

The ratio of people I know in gamedev who love vs hate visual programming is on the order of 10:1

I assume you work in unreal? Unity is more popular though and doesn't have visual scripting. Unreal Engine just having visual scripting and C++ with nothing in between is probably its biggest weakness, people prefer C# over those.