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

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

431–440 of 505 posts

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

#431

Post by galaxyLogic »

jpeloquin wrote: post #400
galaxyLogic wrote: post #389

Earlier quoted context omitted.

A basic problem I have, looking at an Excel spreadsheet, is I don't know which cells are calculated by a formula, which are constants. Maybe it would be easier if the spreadsheet was divided into an upper part with only constant-cells and a lower part with only calculated values, would that help me?

> A basic problem I have, looking at an Excel spreadsheet, is I don't know which cells are calculated by a formula, which are constants. Use Ctrl-` (show formulas).

Thanks for the tip I will use it next time I open an Excel spreadsheet.

I'm also thinking in terms of perhaps having a different visual style for cells with formulas, when the spreadsheet is presented on paper etc.

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

#434

Post by dgb23 »

wpm wrote: post #427
dgb23 wrote: post #423

Earlier quoted context omitted.

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…

Yes, most diagrams are frustratingly static, even those that over lay step by step information on top. I've found "diagrams" in my head, the mental models I use to reason about a problem, are not static. They are abstract machines, with cogs and gears and clutches and input shafts and output shafts, colors and arrows and action and movement, that work like a map for finding the solution, either directly, or at least…

The pointer thing is so relatable.

I don’t think we share exactly the same inner visuals, but they all relate to some intuitive understanding.

For me there are these unique and abstact visuals but they blend in with code (text) often. When I‘m intimate with a program I can often visualize line by line and fix bugs or change its behavior.

However, the things that‘s most removed from textual representation is data, memory, I/O (streams etc.) and it all moves.

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

#435

Post by smj-edison »

charleslmunger wrote: post #411
smj-edison wrote: post #366

Earlier quoted context omitted.

From what I've seen when code is generated from formal specs it ends up being inflexible. However, do you think it would be valuable to be able to verify an implementation based on a formal spec?

People do that, and find very tricky bugs. One person did it by line-by-line translating C code into TLA+, another by representing the state machine in Coq and checking for predicates validating it in the source. But I don't think a visual representation of the state machine would have diagnosed the bugs the formal checkers did. https://probablydance.com/2020/10/31/using-tla-in-the-real-w... https://probablydance.com…

I just realized my previous comment left out what I was trying to say—my bad! I think what I was trying to ask was: would it be possible to generate a formal specification from a graphical representation, and then use that specification to verify the source?

Also thank you for those links! I'll definitely give them a read.

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

#436

Post by twodave »

ranger_danger wrote: post #395
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…

> painful because after every small edit I have to spend ten minutes fixing layout. PlantUML solves this.

I disagree. As someone who likes PlantUML specifically because it lets me store diagrams as code, I too frequently end up spending just as much time trying to indirectly coerce the thing into the layout I want since it won’t let me position things explicitly.

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

#437

Post by jbverschoor »

zarathustreal wrote: post #294
jbverschoor wrote: post #286

Earlier quoted context omitted.

Even the simplest type inference can cause typescript to stall for minutes. The problem is in the inference. That problem goes away when you're actually specifying types. Tooling should add typing automatically (not implicitly)

Minutes? There’s no way you’ve seen a minutes-long stall caused by TypeScript inference..I need to see some evidence on this one

I'll look into it.. But yeah, had that multiple times (older versions though). Specifying the type solves is, and I was not the only one after some googling

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

#438

Post by lanstin »

constantcrying wrote: post #232
d--b wrote: post #199

> One reason is because we think that other, more inexperienced, programmers might have an easier time with visual programming. If only code wasn't as scary! If only it was visual! Excel Formula is the most popular programming language by a few orders of magnitude and it can look like this: > =INDEX(A1:A4,SMALL(IF(Active[A1:A4]=E$1,ROW(A1:A4)-1),ROW(1:1)),2) Ahem. Excel is one of the most visual programming environme…

I have had to debug insane Excel sheets, which were used to generate C code, based on the geometric properties of an object. Excel works very well for describing many, simple relationships. It totally falls apart the moment you have complex relationships, as they become mentally untraceable. Functions allow you to abstract away functionality, referencing cells does not. I am pretty certain that Excel is one of the mo…

I had thought I had seen everything but kudos - Excel to generate C code is some sort of local extremum for software hacks.

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

#439

Post by Risord »

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…

I think quite interesting starting point is general purpose visual medium which is good enough to be used for programming, too.

Aka: more visual/structured medium to some use cases we use text today.

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

#440

Post by ranger_danger »

twodave wrote: post #436
ranger_danger wrote: post #395

Earlier quoted context omitted.

> painful because after every small edit I have to spend ten minutes fixing layout. PlantUML solves this.

I disagree. As someone who likes PlantUML specifically because it lets me store diagrams as code, I too frequently end up spending just as much time trying to indirectly coerce the thing into the layout I want since it won’t let me position things explicitly.

Fair enough, I guess we have different opinions on what "fixing the layout" really means :)
Post reply on HN