We need visual programming. No, not like that • Hacker News Board

Re: We need visual programming. No, not like that

#141

Post by baruz » Mon, Jul 15, 2024, 5:27 AM UTC

whstl wrote: post #36

aragonite wrote: post #32

> Developers say they want "visual programming", which makes you think "oh, let's replace if and for". But nobody ever made a flow chart to read for (i in 0..10) if even?(i) print(i). I'm not convinced by this particular example. Wouldn't a visual programming language just represent the logic here as a pipeline connecting two more atomic operations: you'd have a visual representation where you pipe the (0..10) range…

That's a good point. Functional programming is a much more appropriate foundation for visual coding. Not only because of functional operators in your example, but immutability and purity also makes things simpler when represented visually. Circuit modeling (like in Max/MSP, Reaktor, Pd) is something that also works way better visually than imperative programming.

Dataflow paradigm

Re: We need visual programming. No, not like that

#142

Post by applied_heat » Mon, Jul 15, 2024, 5:29 AM UTC

ejiblabahaba wrote: post #118

dralley wrote: post #97

Earlier quoted context omitted.

Most industrial automation programming happens in an environment similar to LabView, if not LabView itself. DeltaV, Siemens, Allen-Bradley, etc. Most industrial facilities are absolutely full of them with text-based code being likely a small minority for anything higher level than the firmware of individual PLCs and such.

A lot of these environments inherit a visual presentation style (ladder logic) that comes from the pre-computer era, and that works extremely well for electrical schematics when conveying asynchronous conditional behaviors to anyone, even people without much of a math background. There's a lot of more advanced functions these days that you write in plain C code in a hierarchical block, mostly for things like motor co…

I like function block on Schneider platform for Process control with more analog values than Boolean. It visualizes the inputs, control loop, and output nicely.

Numeric values in ladder feels a bit kludgey

Re: We need visual programming. No, not like that

#143

Post by hermitcrab » Mon, Jul 15, 2024, 5:33 AM UTC

Visual programming works best when it is used on a limited domain with a higher level of abstraction than programming languages such as C. For example data transformation, image manipulation, sound processing etc. More discussion of isual vs code here:

https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...

Re: We need visual programming. No, not like that

#144

Post by katzenversteher » Mon, Jul 15, 2024, 5:36 AM UTC

I really miss ObjecTime ROOM. We used it a lot for embedded software development and it basically allowed to model the "big picture" of your application in (extended) UML and add C / C++ for the details. The generated code for the rest was usually very efficient, the runtime was pretty portable and slim as well.

It became IBM Rational Rose Realtime (! the last word makes a big difference) and then it kind of disappeared from what I know. I believe they tried to integrate it with Eclipse and maybe they did but the IBM website is such a jungle to navigate, I never found something comparable.

Re: We need visual programming. No, not like that

#145

Post by baruz » Mon, Jul 15, 2024, 5:38 AM UTC

sbensu wrote: post #55

aragonite wrote: post #32

> Developers say they want "visual programming", which makes you think "oh, let's replace if and for". But nobody ever made a flow chart to read for (i in 0..10) if even?(i) print(i). I'm not convinced by this particular example. Wouldn't a visual programming language just represent the logic here as a pipeline connecting two more atomic operations: you'd have a visual representation where you pipe the (0..10) range…

It is certainly possible and that is how most of these visual languages do it. But is that how _you_ want to program that logic?

That’s how Smalltalk does it. I believe Scheme family languages do it that way, use a generator and then filter and select. Self as well.

Re: We need visual programming. No, not like that

#146

Post by vanjajaja1 » Mon, Jul 15, 2024, 5:38 AM UTC

ethbr1 wrote: post #131

npunt wrote: post #21

Great article. Any sufficiently complex problem requires looking at it from different angles in order to root out the unexpected and ambiguous. Visualizations do exactly that. This is especially important in the age of AI coding tools and how coding is moving from lower level to higher level expression (with greater levels of ambiguity). One ideal use of AI coding tools would be to be on the lookout for ambiguities a…

> Any sufficiently complex problem requires looking at it from different angles in order to root out the unexpected and ambiguous. Visualizations do exactly that. To me, this is an underappreciated tenet of good visualization design. Bad/lazy visualizations show you what you already know, in prettier form. Good visualizations give you a better understanding of things-you-don't-know at the time of designing the visual…

agreed, though bad/lazy visualizations can still be useful for a cache. you know it today, but you might forget tomorrow

Re: We need visual programming. No, not like that

#147

Post by f1shy » Mon, Jul 15, 2024, 5:49 AM UTC

Harmohit wrote: post #59

I am surprised I have not seen LabView mentioned in this thread. It is arguably one of the most popular visual programming languages after Excel and I absolutely hate it. It has all the downsides of visual programming that the author mentions. The visual aspect of it makes it so hard to understand the flow of control. There is no clear left to right or top to bottom way of chronologically reading a program.

I still have to find somebody who worked with LabView that does not hate it.

It is a total abomination.

Re: We need visual programming. No, not like that

#148

Post by ozim » Mon, Jul 15, 2024, 5:53 AM UTC

mapcars wrote: post #8

jampekka wrote: post #2

The fundamental problem in visual programming is that it limits you to geometry (practically to 2D euclidian space). Most non-trivial programming problems are spaghetti by nature in such spaces.

That is not a problem, and for sure not a fundamental one. The textual representation is very limited, it's actually 1D with a line breaks helping us read it. 2D gives a lot more possibilities of organising code similar to how we draw diagrams on a whiteboard.

With text/symbolic representation I can describe any amount of dimensions in a super dense way and physicist/mathematicians are doing that, software devs as well because most software is multidimensional.

You do have graphs in mathematics but all the maths I see is about describing reality in really dense couple of symbols, compressing as much of the universe as possible to something like E=mc^2.

Graphical programming representations go the other way - it actually tries to use more bits to describe something that can be described in less bits - many more bits.

Re: We need visual programming. No, not like that

#149

Post by tkubacki » Mon, Jul 15, 2024, 5:56 AM UTC

I've done my own "try to animate things with mermaid like lang" https://github.com/dot-and-box/dot-and-box

and got one conclusion similar to article's author as I understand it: general purpose visual programming lang is hard or impossible

Re: We need visual programming. No, not like that

#150

Post by transpute » Mon, Jul 15, 2024, 5:57 AM UTC

learn_more wrote: post #92

sbensu wrote: post #75

Earlier quoted context omitted.

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program? That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

You might be interested in: https://schematix.com/video/depmap I'm the founder. It's a tool for interacting with deployment diagrams like you mentioned in your article. We have customers who also model state machines and generate code from the diagrams.

> Schematix provides diagrams as a dynamic resource using its API. They aren't images you export, they don't end up in My Documents. This isn't Corel Draw. In Schematix, you specify part of your model using a graph expression, and the system automatically generates a diagram of the objects and relations that match. As your Schematix model changes, the results of the graph expression may change, and thus the visual diagram will also change. But the system doesn't need you to point and click for it. Once you've told it what you want, you're done.

What an interesting tool! It's rare to see robust data models, flexible UX abstractions for dev + ops, lightweight process notations, programmatic inventory, live API dashboards and a multi-browser web client in one product.

Do you have commercial competitors? If not, it might be worth doing a blog post and/or Show HN on OSS tooling (e.g Netbox inventory, netflow analysis of service dependencies) which offer a subset of Schematix, to help potential customers understand what you've accomplished.

Operational risk management consultants in the finance sector could benefit from Schematix, https://www.mckinsey.com/capabilities/risk-and-resilience/ou.... Lots of complexity and data for neutral visualization tooling.