Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where should visual programming go?

tonsky.me

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Where should visual programming go?

#11

Post by 1ByteAttaTime »

hinkley wrote: post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

Node-Red "Projects" feature has version control features that include a diffing tool (running on git). I've tried UML code generators in the past and was a skeptic of NR at first, but for headless applications subject to recurring change or needing high-level access to complex stacks (like video compression) its really impressive. Don't get me wrong, its still glorified NodeJs and not for every job but its worth a peek...

https://nodered.org/docs/user-guide/projects/

Re: Where should visual programming go?

#12

Post by jarsin »

hinkley wrote: post #10
jarsin wrote: post #4

Earlier quoted context omitted.

Unreal has visual diff. It's interactive so you can click on some node and it will take you to the diff in the other file. I honestly never use it because I only use unreal alone, so can't say how good or bad it is in real world project.

You know of a good demo video?

High level overview with source control in unreal https://youtu.be/YKMDdtX-8gM?t=1025

Basic demo https://www.youtube.com/watch?v=XYZsvouytVQ

Re: Where should visual programming go?

#17

Post by randomdata »

yryr wrote: post #2

Have a look at Ballerina, https://ballerina.io/

Presumably as an example of where it doesn't need to go? The graphical representations are incomprehensible at first glance. I'm sure you can learn to understand them, but at that point why not just learn how to read the textual representation? Especially when it doesn't even uphold its claim of being equivalent. The textual representation shows some kind of error handling, but I can find nothing in the graphical representation that indicates that there is error states.

Re: Where should visual programming go?

#18

Post by limit499karma »

hinkley wrote: post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

> (mechanical sympathy)

I get what you are trying to convey but that usage of the term is not helpful in the general case as it confuses what mechanical sympathy actually means.

Mechanical sympathy is simply this: abstractions that acknowledge the underlying embodying stratum of a dynamic construct. In code, that translates to software that attempts at harmonizing the software abstraction with the operational characteristics of the underlying computing device.

Re: Where should visual programming go?

#19

Post by recursivedoubts »

not a well thought out take, but i think visual programming should stop trying to encode application logic and focus on:

- building good UIs rapidly (e.g. improving & simplifying layout options, look & feel, etc.)

- make debugging trivial & powerful

- make deployment trivial

Visual Basic was on the right track in almost every way except as a language. Hypercard maybe had the language thing figured out: use english as a base?

Hooking up loops and conditionals visually is a waste of type, people can type it out with a little instruction with a good IDE & code completion that caters to non-coders. Focus on the tooling around the code & the things visual development has proven good for (laying out UIs, debugging) and then the stuff that people don't want to think about (deploy)

Re: Where should visual programming go?

#20

Post by lagniappe »

recursivedoubts wrote: post #19

not a well thought out take, but i think visual programming should stop trying to encode application logic and focus on: - building good UIs rapidly (e.g. improving & simplifying layout options, look & feel, etc.) - make debugging trivial & powerful - make deployment trivial Visual Basic was on the right track in almost every way except as a language. Hypercard maybe had the language thing figured out: use english as…

Visual Basic nailed it, for me. Nothing has felt that intuitive for me since.

If I were to build a poor man's effigy to visual basic today, I'd use Go as the underlying language, and Fyne for the visual kit.

- Go has strong concurrency that is easy to understand

- Go has easy syntax that makes errors very obvious and debuggable

- Go is multi platform, truly, from OS to hardware, right out of the box

- Go with Fyne can produce a single binary .exe just like visual basic.

- Fyne retains the same look and feel across different environments

Post reply on HN