Folk wisdom on visual programming • Hacker News Board

Re: Folk wisdom on visual programming

#151

Post by grayrest » Fri, Jul 02, 2021, 5:47 PM UTC

> So presumably we could learn to distinguish closely packed shapes if we were familiar enough with the conventions.

The data visualization people have already demonstrated this with sparklines and small multiples. There are fewer preattentive attributes than most people would assume so I expect increasingly dense visual representations to approach text (e.g. logograms).

I'll also point out that data viz people have also come up with reasonable solutions to problems mentioned like wire bundling. I haven't seen an auto-layout algorithm I like but I've found a reasonable guess followed by manual manipulation with automatic wire routing to be okay for visualizations and the circuit drawing and VLSI I did 20 years ago in college.

Re: Folk wisdom on visual programming

#152

Post by 908B64B197 » Fri, Jul 02, 2021, 5:56 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…

> Yes Unix has pipes

And they only understand byte streams, which are the simplest possible abstraction.

> Or like electrical devices, just channel the data between them.

If you get to that level of precision, there are visual tools for logical circuit design. But I don't think that's what the author had in mind.

Re: Folk wisdom on visual programming

#153

Post by MaxBarraclough » Fri, Jul 02, 2021, 6:06 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…

> 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.

I'm not a functional programmer, but don't monads aim to do something like that?

Re: Folk wisdom on visual programming

#154

Post by im_down_w_otp » Fri, Jul 02, 2021, 6:40 PM UTC

w_t_payne wrote: post #122

im_down_w_otp wrote: post #65

Earlier quoted context omitted.

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.

Happy to chat sometime. Any preferred way to connect?

Re: Folk wisdom on visual programming

#155

Post by joonazan » Fri, Jul 02, 2021, 8:11 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…

> 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.

Ever played SpaceChem?

Re: Folk wisdom on visual programming

#156

Post by dkersten » Fri, Jul 02, 2021, 9:41 PM UTC

bmitc wrote: post #73

analog31 wrote: post #17

The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools. I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an e…

> I used LabVIEW extensively for a few months I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively,…

> But I can indeed see an argument for strain when using the mouse so much. I have experienced that before and improved my ergonomic setup. As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program or use tools.

I wonder also how using visual languages like LabVIEW compares to other mouse-heavy computer users like photo editors/graphic designers, CAD users etc.

> Dataflow is attractive to advanced users as well

I quite enjoyed using Max/MSP a few years ago when I did some stuff with it for a few months. I've always wished I had it available as a general purpose language in my programming toolbox since. As for other advanced users who use (visual) dataflow, my go to example is Ansys' SCADE Suite[1][2][3], which is used for critical systems like trains, helicopters and power plants.

[1] https://www.ansys.com/products/embedded-software/ansys-scade...

[2] https://www.ansys.com/content/dam/product/embedded-software/...

[3] https://www.youtube.com/watch?v=5z0h-WeScqw&list=PL0lZXwHtV6... (the third video introduces the visual language)

Re: Folk wisdom on visual programming

#157

Post by galaxyLogic » Sat, Jul 03, 2021, 12:40 AM UTC

username90 wrote: post #133

galaxyLogic wrote: post #69

What I find interesting is that the human society and economy at large is able to function without there being any genius programmer who designed it all. If you look at roads, there is a road everywhere and still people don't get lost. But in a big chunk of source-code I do feel I get lost. I believe that may be because there are too few constraints when programming textually. Whereas when designing roads and bridges…

A city with streets is just a graph with 1-4 pointers per node. It is super simple in code, just a few lines, not sure how you could get lost in that. If you make code anything more complex than that then it isn't really equivalent to navigating the streets on a map. > I believe that may be because there are too few constraints when programming textually No that is not the issue, you can write extremely complex and u…

> If you make code anything more complex than that then it isn't really equivalent to navigating the streets on a map.

My point is, you should strive to make coding not more complex than that, if possible. And if you have constraints such as must represent the program as a 2-D dataflow structure then it must stay simple as that. Now is there a need to make more complicated programs? Probably yes. But human society is still able to function with the simple dataflows that it has, which makes it understandable and thus very resilient.

Re: Folk wisdom on visual programming

#158

Post by Timothycquinn » Sat, Jul 03, 2021, 2:13 AM UTC

cruise9 wrote: post #83

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…

I'd love to hear how you integrated a Java and TCL backend with spreadsheets. I'm assuming this isn't something you can do with excel? (Logistics at the small business I work at, is run on a mess of excel spreadsheets with complicated formulas and occasionally VBA for some email functionality. I have a feeling we're doing things horribly wrong, but I don't know of any better way to do things with our zero IT budget.)

I did not leverage any VBA or VB. I learned to code in VBA and written way too much code in that space and was well aware of the limitations.

I'm pretty sure the way it went was, on check-in of a new version, I had a Java program that read the spreadsheet validated that all the right sheets were there and that the columns on each sheet conformed with the spec and also validated rows of data. The sheets were translated on each front end node for easy access.

Regarding the expression engine, the the expressions themselves were then translated into TCL boolean expressions. The attributes for the related objects where already loaded into memory into dictionaries and then the expressions were just evaluated to get a boolean result.

Re: Folk wisdom on visual programming

#159

Post by Timothycquinn » Sat, Jul 03, 2021, 2:19 AM UTC

meesterdude wrote: post #128

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.

Agreed. I was amazed to see how much coding time is wasted by people trying to do some data cleanup job when it can be done so much easier and safer with no coding by: 1) Exporting he data to a spreadsheet 2) Massaging the data in the spreadsheet 3) Use a general purpose program to convert the spreadsheet into scripts that can be run against the DB.

I actually wrote a VBA program that does this where you have a query with ~1, ~2, ~3 macros and you just paste in a table, click a button and it spits out scripts for you. I wrote it 20 years ago and still use it to this day.

Re: Folk wisdom on visual programming

#160

Post by analog31 » Sat, Jul 03, 2021, 3:36 AM UTC

bmitc wrote: post #73

analog31 wrote: post #17

The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools. I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an e…

> I used LabVIEW extensively for a few months I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively,…

>>> I’m not sure that a few months is enough to understand the true pros and cons of a language.

No doubt. My problems were mainly with the ergonomics of the editing environment, not the language. And I had problems with other graphical software as well, including games.