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

441–450 of 505 posts

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

#441

Post by alpakaxaxa »

Programming visually is a very hard topic and I am not qualified to talk about it. However, for me it is extremely weird that programming is still about entering some code / functions from top to bottom in a text file.

Please let me enter code in a 2d canvas where I can put a bunch of functions that are related to each other in one corner, etc. Because I don't need to scroll through code when I know exactly where I put it on a 2d canvas because the thing has an actual shape instead of just top to bottom. Give me different views based on what I am doing. Implementing a feature? Debugging? The developer tooling is abysmal in general and I think the programming industry is doing an awful job in doing any progress as companies don't seem to properly fund these efforts. It is capitalism baby. I habe to say, I am not really a programmer and I have mental limitations which would benefit a great deal from better tooling.

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

#442

Post by dhosek »

yoelhacks wrote: post #391
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 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.

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

#444

Post by sterlind »

I once saw a Clojure implementation of red-black trees that had an inline, visual diagram of each tree pattern to match on, and how to mutate the graph (at one of the Strange Loop conferences.) extremely slick, since code was generated from the diagrams (or by, can't recall which.)

that's an extremely niche case, certainly not enough to justify including visualizer widgets in an IDE, but here's another: form builders. they've fallen out of favor recently, but UI layouts are extremely visual and lend themselves well to visual programming.

DrRacket is a neat little playground for experimenting with this kind of thing.

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

#445

Post by AtlasBarfed »

jayd16 wrote: post #375
raincole wrote: post #112

Earlier quoted context omitted.

As someone who works for games, I think the biggest problem of node-based systems is... they're all different (in terms of UI/UX). Unreal blueprints, Substance Designer, Houdini, Blender's geometry node, Unity shader nodes... they all look different and act differently. Different shortcuts and gestures. Different window/panel management. Different programming languages have different syntax rules and libraries, of co…

You know, this is actually really insightful. A standard graph format that all these tools could import/export to could lead to a lot more reusable tooling. The incentives aren't quite there at the moment but maybe someone like Microsoft or Jetbrains takes a stab at it.

You think Microsoft is going to make a format that's cross-platform?

I guess that leaves jet brains

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

#446

Post by ar_lan »

buescher wrote: post #404
ar_lan wrote: post #365

I genuinely have no idea how to read the first diagram presented. Maybe I'm not the target audience - I'm significantly NOT a visual learner, but that first diagram is far more confusing to me than code/pseudocode.

That system, Unit, was on the front page here about a week ago: https://news.ycombinator.com/item?id=40900029 It's got a certain aesthetic appeal but I don't find it self-explanatory either.

Thank you for the context!

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

#448

Post by Risord »

Risord wrote: post #439
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.

One can start from typical UIs and start tinkering from there why it isn't good enough for programming.

Good first step is to notice that we dont have even static data objects. Still UIs are full of them (forms) but you cannot copy paste or store them as a whole, everything is ad-hoc. Now imagine that every form could be handled like Unity scriptable object. And maybe something what prefab variants do: data inheritance.

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

#449

Post by Duanemclemore »

pyottdes wrote: post #356
Duanemclemore wrote: post #122

I'm going to throw a vote in here for Grasshopper, the visual programming language in Rhino3d as doing it the right way. It is WIDELY used in architectural education and practice alike. Unfortunately, most visuals you'll get of the populated canvas online are crap. And for those of us who make extremely clean readable programs it's kind of a superpower and we tend to be careful with how widely we spread them. But onc…

Agreed, Rhino/Grasshopper is an amazing tool, especially once you start adding in C# components. I’ve been using it off and on for several years on custom consumer product projects. It’s an under utilized workflow in many fields requiring 3D modeling imo. I just finished a custom VR gasket generator for the Quest 3 that uses face scans from iPhone as the input and the project wouldn’t have been possible without Grass…

That's rad - thanks for sharing! I'll try to watch the whole thing when I'm not on deadline.

My jewelry work [0] is almost all in Grasshopper, as I've built up such a workflow there over the past... 8 years? that I don't need custom tools for most of it.

But my research work is all about building custom tools in C#. In fact I just finally published my component library yesterday [1]. Frankly I should have released it years ago, but I finally just bit the bullet.

[0] https://Xover0.com [1] https://www.food4rhino.com/en/app/horta

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

#450

Post by jmholla »

BobbyTables2 wrote: post #65
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 agree. LabView’s shining examples would be trivial Python scripts (aside from the GUI tweaking). However, it’s runtime interactive 2D graph/plot widgets are unequaled. As soon as a “function” becomes slightly non trivial, the graphical nature makes it hard to follow. Structured data with the “weak typedef” is a minefield. A simple program to solve a quadratic equation becomes an absolute mess when laid out graphica…

> How does one “diff” a LabView program?

LabVIEW has a built-in differ.

Post reply on HN