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

391–400 of 505 posts

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

#391

Post by yoelhacks »

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 operations using a written artifact (language, SQL, etc). Combining them in different ways visually as a first-class operation would only interest me if it operated at the level of abstraction that visualizations currently operate at, many great examples of which are offered in the article (multiple code files, system architecture, network call).

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

#392

Post by MisterTea »

dralley wrote: post #97
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.

Most industrial automation programming happens in an environment similar to LabView, if not LabView itself. DeltaV, Siemens, Allen-Bradley, etc. Most industrial facilities are absolutely full of them with text-based code being likely a small minority for anything higher level than the firmware of individual PLCs and such.

These are standardized IEC 61131-3 languages https://en.wikipedia.org/wiki/IEC_61131-3

Ladder, SFC and FBD are all graphical languages used to program PLC's. Ladder is directly based on electrical ladder schematics and common in the USA. The idea was electricians and plant technicians who understood ladder schematics could now program and troubleshoot industrial computers. SFC and FBD were more common in Europe but nowadays you mostly see Structured Text, a Pascal dialect (usually with bolted on vendor OOP lunacy.)

I will admit that for some programs, Ladder is fantastic. Of course ladder can be turned into horrid spaghetti if the programmer doesn't split up the logic properly

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

#394

Post by usernamed7 »

I seem to have a fascination with code visualization and exploration. Looking at a complex codebase through a variety of perspectives can have a lot of utility. I like the heatmap a lot but that's only of statistical benefit and less exploratory.

I created a rudimentary graphical ruby programming environment https://x.com/RussTheMagic/status/1809091784946921670 however I realized similar conclusions of this article; while i could do lazy evals, and method parameters and all sorts of song and dance... that's not actually what I needed - which was a way to better work with and tinker with code. I've used irb/pry extensively for this, but it's always had it's limitations there.

I wanted to be able to see what the result of the ruby code was as it was executed line by line and be able to explore the return values, so I made another version which is a realtime, visual irb called revirb https://x.com/RussTheMagic/status/1811427507784315309

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

#395

Post by ranger_danger »

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.

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

#396

Post by jpeloquin »

duckmysick wrote: post #289
bboygravity wrote: post #163

Earlier quoted context omitted.

I don't hate it, I feel it's pretty good for talking to hardware, (understanding) multi-threading, agent oriented programming, message cues, etc. It's also fairly good for making money: the oil and gass industry seems to like using it (note: n = 1, I only did one oil n gas project with it).

How does version control work with Labview? Also, since you;ve done only one project with it, how hard was it to pick it up and learn?

> How does version control work with Labview?

Labview does have diff and merge tools. It feels kind of clunky in practice, kind of like diffing/merging MS Office files. In my experience people think of versions of LabView code as immutable snapshots along a linear timeline and don't really expect to have merge commits. Code versions may as well be stored as separate folders with revision numbers. The mindset is more hardware-centric; e.g., when rewiring a physical data acquisition system, reverting a change just means doing the work over again differently. So LabView's deficiencies in version control don't stand out as much as they would in pure software development.

https://www.ni.com/docs/en-US/bundle/labview/page/comparing-...

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

#398

Post by sgt101 »

mctaylor wrote: post #397

I think we need functional visual programming. It seems to me like referential transparency and pure functional composition would be a much cleaner way to visually compose functions into larger functions (and eventually programs).

People did some work on this : https://www.google.co.uk/books/edition/Drawing_Programs_The_...

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

#399

Post by [deleted] »

duckmysick wrote: post #289
bboygravity wrote: post #163

Earlier quoted context omitted.

I don't hate it, I feel it's pretty good for talking to hardware, (understanding) multi-threading, agent oriented programming, message cues, etc. It's also fairly good for making money: the oil and gass industry seems to like using it (note: n = 1, I only did one oil n gas project with it).

How does version control work with Labview? Also, since you;ve done only one project with it, how hard was it to pick it up and learn?

[deleted]

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

#400

Post by jpeloquin »

galaxyLogic wrote: post #389
ambyra wrote: post #208

Earlier quoted context omitted.

Excel could do this so much better though (and I think excel is the best candidate for visual scripting overhaul). The cell could have two parts; top parts is the function signature (other cells could reference by signature, or by cell number), bottom part is the code. Each cell is a function. People put huge unreadable basic functions in that tiny box. It's such an obvious pain point, surprised it's never been addre…

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).

Post reply on HN