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

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

#481

Post by eimrine » Tue, Jul 16, 2024, 3:14 PM UTC

edflsafoiewq wrote: post #35

lolinder wrote: post #28

Earlier quoted context omitted.

Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?

Writing is based on speech, which is one-dimensional. Most programming is actually already highly two-dimensional thanks to its heavy line orientation. But most visual programming isn't trying to be a kind of "2D orthography" for language, it is trying to be a "picture" of a physical mechanism.

That 2D orthography idea is my pipe dream. Any time I am writing several similar lines of code but with variables having different length I always want my IDE to be acknowledged that some 1-symbol operators would be looking so nice if aligned in one vertical line.

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

#482

Post by Night_Thastus » Tue, Jul 16, 2024, 3:43 PM UTC

I would love something to better visualize the software I'm working with. However...

1: It would need to have dynamic abstraction. Sometimes I need to see very top-level flow and organization, sometimes I need to dig down a bit. I'll essentially never need the lowest level like IF statements as the OP mentions, but I'll definitely need multiple different levels.

2: It would need to have some awareness of the intention of the software, its history, and it would need answers to some questions. It would need to be as competent as a developer experienced with writing the software to really give me any useful insights. It can't get confused because there are some macros sprinkled in, 3-4 different languages interacting, or parts of the software only used when certain environmental variables are set. It needs to handle basically all of the edge cases. If it gets "confused", it'll end up taking more time than it saves.

#1 is doable, but hard. #2 is basically magic. (For now)

You can claim machine learning can do it, but there's nothing close to that sophisticated and reliable in existence.

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

#483

Post by pjdesno » Tue, Jul 16, 2024, 3:44 PM UTC

Interesting that neither the original article nor any of the comments so far mention MATLAB's Communications Toolbox, which is probably one of the most widely used visual programming languages.

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

#484

Post by JonChesterfield » Tue, Jul 16, 2024, 3:47 PM UTC

jillesvangurp wrote: post #170

I think people get too hung up on the visuals. There was a (failed) attempt to create something called intentional programming by Charles Simonyi. That happened in the middle of the model driven architecture craziness about 20 years ago. In short, his ideas was to build a language where higher level primitives are created by doing transformations on lower level syntax trees. All the way down to assembly code. The ide…

Related to this is compilers printing control flow graphs on request, though usually you can't edit the graph and convert that back to the internal structure.

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

#485

Post by cxr » Tue, Jul 16, 2024, 4:51 PM UTC

For programming and debugging to be really visual and really succeed, it needs to be in three dimensions. Like a shop floor that you can roam around, pull things off the conveyor, inspect and tweak them with your hands, and then put them back where they were and watch them move to the next step in the process.

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

#486

Post by dhosek » Tue, Jul 16, 2024, 5:18 PM UTC

nagonago wrote: post #452

dhosek wrote: post #442

Earlier quoted context omitted.

My son who started programming at 7 pretty quickly moved on from languages like Scratch and Tinker. To the extent to which he uses them at all, it’s mostly to play games that are available in them. I’m not entirely convinced that he couldn’t have just started with Javascript or Python. It’s not like learning the syntax for a for loop¹ is that much harder than arranging the blocks in one of those block languages. ⸻ 1.…

> Although I must confess that I have a mental block about the second and third components of a C-style for-loop and whenever possible, I avoid them if I can. Glad I'm not the only one! Despite programming for over a decade, I still mix up the order of `update` and `condition` sometimes in `(initialization, condition, update)` for loops. Probably because I spent too much time with Python and became so accustomed to o…

It has definitely pushed me to prefer foreach style loops in my coding which, I think, makes the code in general better (and, when writing in rust, faster as the generated code is able to eschew bounds checks).

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

#487

Post by rbanffy » Tue, Jul 16, 2024, 5:22 PM UTC

dgb23 wrote: post #423

low_tech_punk wrote: post #384

I think we need to differentiate: Visualize a program vs. Visually program. This post seems to still focus the former while an earlier HN post on Scoped Propagators https://news.ycombinator.com/item?id=40916193 showed what's possible with the latter. It specifically showed what's possible when programming with graphs. Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual prog…

The dead fish metaphor is so interesting because programs aren’t static objects, they move. Most visual programming environments represent programs in a static way, they just do it with pictures (often graphs) instead of text. Perhaps there is something to be discovered when we start visualization what the CPU does at a very low level, as in moving and manipulating bits, and then build visual, animated abstractions w…

> what the CPU does at a very low level,

Careful with what you wish for. Below the ISA abstractions there are endless nightmares of realities created and destroyed, time flowing in multiple directions, and side effects of other realities you can almost see, but won’t.

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

#488

Post by rbanffy » Tue, Jul 16, 2024, 5:29 PM UTC

causal wrote: post #334

tliltocatl wrote: post #138

The social problem with visual programming is indeed the same as with "Mythical Non-Roboticist". But there is quite some issues on it on the technical side too: - Any sufficiently advanced program has non-planar dataflow graph. Yes "pipelines" are fine, but anything beyond that - you are going to need labels. And with labels it becomes just like plain old non-visual program, just less structured. - Code formatting be…

+1 I'd add versioning and diff tools as another critical advantage for text. If your visual tool can't provide a superior diff experience, then it's dead on arrival for most serious projects.

I have a hard time trying to convince people to use things like PlantUML to “write” diagrams, but Gliphy is much too popular.

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

#489

Post by causal » Tue, Jul 16, 2024, 5:53 PM UTC

rbanffy wrote: post #488

causal wrote: post #334

Earlier quoted context omitted.

+1 I'd add versioning and diff tools as another critical advantage for text. If your visual tool can't provide a superior diff experience, then it's dead on arrival for most serious projects.

I have a hard time trying to convince people to use things like PlantUML to “write” diagrams, but Gliphy is much too popular.

I wish Github READMEs had native PlantUML support. My go to is MermaidJS for that reason.

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

#490

Post by Gormo » Tue, Jul 16, 2024, 5:59 PM UTC

jrm4 wrote: post #456

Gormo wrote: post #352

Earlier quoted context omitted.

What do you mean by "modern", and in what way does the existing implementation of Eagle Mode not meet that criterion?

I feel like I ought to be able to plead the "porn definition" thing here. YOU KNOW IT WHEN YOU SEE IT, COME ON. :) (fair question, I'd have to think about it some more)

The point is that "modern" doesn't actually mean anything at all -- all you're saying is that something seems to you, subjectively, to be somehow newer in relation to older things, but you're (a) talking about yourself, not about the thing you're evaluating, and (b) not even describing any of the concrete qualities of the thing itself that may be informing that subjective impression.

When someone describes something as "modern", are they saying that it's large or small? Is it bright or dark? Simple or complex? Fast or slow? That term encompasses no answers to any of these questions.