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

451–460 of 505 posts

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

#451

Post by hnick »

marcosdumay wrote: post #360
hnick wrote: post #209

Earlier quoted context omitted.

As a programmer who had used Excel for years, seeing my accountant start typing a formula, change sheets, select some cells, go back, repeat, was a learning process. I didn't even know you could do that, and also, I hated it. But it worked very well for him. I've more recently been exposed to a few spreadsheets that are used to calculate quotes in major insurance businesses when I was asked to create an online proces…

> I seem to always find at least one error Every time I see so spreadsheet where the dependency is hard to track, I've found enough errors that the results were completely bogus. Also every time, nobody cared.

In my case at least, they probably accounted for it somewhere by adjusting rates elsewhere so it works out. So it's a bit risky to just change, similar to code that is known to be wrong but too hard to change since "everything works".

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

#452

Post by nagonago »

dhosek wrote: post #442
yoelhacks wrote: post #391

Earlier quoted context omitted.

I think there's a very important real-world nuance here. What you want with a programming language is to handle granular logic in a very explicit way (business requirements, precise calculations, etc.). What this article posits, and what I agree with, is that existing languages offer a more concise way of doing that. If I wanted to program in a visual way, I'd probably still want / need the ability to do specific ope…

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 only using `for x in y` style loops.

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

#453

Post by mashpoe »

chacham15 wrote: post #5

I think the difficulty here is addressing: who is your target audience? Depending on that answer, you have different existing relatively succesful visual programming languages. For example, game designers have managed to make good use of Unreals' blueprints to great effect. Hobbists use Comfy UIs node language to wire up generative AI components to great effect. As far as generic computing goes, Scratch has managed t…

Scratch is the only type of visual programming I've enjoyed using. It's easy to read if you're an experienced programmer because it has the same structure as regular code, and it's easy to read for beginners because everything is broken into large blocks that have what they do written right on them. The way code is structured in most programming languages is actually very logical and intuitive, and it's the most successful system we have so far. The problem for beginners is that they can't figure out if they enjoy programming until they've learned the syntax, which can be very discouraging for some people. I've seen Scratch bridge that gap for people a couple of times, and I think it's probably the best model when it comes to teaching people to code.

I think other types of models would only be useful for situations where writing code isn't the most intuitive way to make something. From my limited experience, a visual system for making shaders is a pretty good idea, because ideally, you don't want to have many conditional branches or loops, but you might have a lot of expressions that would look ugly in regular code.

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

#454

Post by austin-cheney »

My solution to this problem is to focus on structure and references only. Eliminate inheritance and other conventions. Have functions as first class citizens and procedures as first class citizens too.

A procedure is essentially just a block of code. It takes no input and returns no output. In a lexically scoped language with block scope then procedures provide scope no differently than functions. If procedures can be called from a variable reference then imagine how clear the code becomes.

Example

    if (something > something_else) procedure_here else other_procedure;
Other example

    let old = {whatever;};
    let young = {young_stuff;};
    if (age > 40) old else young;
The program code suddenly becomes more declarative to read than most declarative languages/conventions. Don't be fooled as this is still highly imperative.

When reading code becomes more narrative and less syntax it becomes more visual the same way reading books becomes more visual with practice reading books. For some people programming is already incredibly visual. It is for me, but not most people.

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

#455

Post by charleslmunger »

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

Earlier quoted context omitted.

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.

I'm far from an expert in formal verification, I probably should be doing more of it than I do. From my two links, the way I've seen formal verification work is to either translate the code line-by-line in an automated or manual way into a formal language, then check for possible orderings that violate properties you care about; or define a formal model of the state machine, and insert validation of all the transitions in the code.

If you were going to do formal verification from the graphical representation, it would be on the algorithm; namely does it always converge, does it ever deadlock, does it ever fail mutual exclusion. If the goal is for a computer to analyze it, it can be precisely as complex as the source code, so yes. But at that point it's not useful visually for a human to read.

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

#456

Post by jrm4 »

Gormo wrote: post #352
jrm4 wrote: post #325

EAGLE MODE I'd kill for a modern version of eaglemode https://eaglemode.sourceforge.net/

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)

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

#457

Post by yoelhacks »

stcredzero wrote: post #416
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…

Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language. I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowch…

> (Which is often maintained manually, separate from the repo.)

To me, this is the interesting avenue for investigation.

Rather than go from visualization -> code, how can we take an existing visualization that represents some underlying system (a code base, module dependencies, service architecture, a network topology, etc) and easily update the representation as the underlying system changes...

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

#458

Post by whilenot-dev »

stcredzero wrote: post #416
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…

Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language. I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowch…

> We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowcharts or state transition diagrams, etc.

We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are documented using diagrams on a high level (like flowcharts or state transition diagrams etc.), but are not executable.

Fixed it for you.

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

#459

Post by smj-edison »

charleslmunger wrote: post #455
smj-edison wrote: post #435

Earlier quoted context omitted.

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.

I'm far from an expert in formal verification, I probably should be doing more of it than I do. From my two links, the way I've seen formal verification work is to either translate the code line-by-line in an automated or manual way into a formal language, then check for possible orderings that violate properties you care about; or define a formal model of the state machine, and insert validation of all the transitio…

Ah, I see: by the time you've written a formal specification, the visualization becomes redundant.

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

#460

Post by gopher_space »

sbensu wrote: post #72
jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates. The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a so…

I've been looking at using Godot for desktop apps, and seeing how the game world thinks about memory has given me a ton of ideas.
Post reply on HN