Live data from Hacker News

Ask HN: Why does visual programming suck?

news.ycombinator.com

311–320 of 325 posts

Re: Ask HN: Why does visual programming suck?

#311

Earlier quoted context omitted.

Yeah. I feel like the depth of OP's writeup blurs the lines between working with an application framework, API, and IDEs. I was under the impression that visual programming is different from IDEs or frameworks...

If you ever want to horrify yourself, google LabView, a truly horrible piece of software.

I actually liked it in a way.

Not my favourite but absolutely not horrifying to a student.

Now that I think about it though I wonder what huge merges look like.

Re: Ask HN: Why does visual programming suck?

#312

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a syst…

Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink: https://mathworks.com/help/simulink/examples/anti-windup-con... Obvious lectures from this: 1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variabl…

I've worked on this and also did cross-compilers for it. It's industry standard. It's not only used in cars, it's used all over industry control automation, airplanes, power plants, ... It's reliable and creates almost bug free code. It allows real-time control loops. It creates highly optimized C code (I wrote a C++ backend). You wouldn't want to do that in C or C++ by hand. Before Simulink my prev. company used Occam, a powerful Smalltalk/Objective C like language with CSP, which ended up being succeeded by Go.

But there are also many more such successful tools being used industrially, esp. from Siemens.

The biggest problem with it are diff tools. There exists a graphical diff in the toolbox, but I haven't seen it being integrated in its workflow yet.

Re: Ask HN: Why does visual programming suck?

#313

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a syst…

Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink: https://mathworks.com/help/simulink/examples/anti-windup-con... Obvious lectures from this: 1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variabl…

I'm developing driver assistance functions for vehicles and I have experience using simulink, although not anymore, fortunately. It's usage is converging slowly but steadily to zero in the company I work for, although we still use it for controllers, but mostly only legacy "code". Why is it?

- First is the most serious, debugging: this is a deal breaker alone. Once your code will go into production, and once, bugs will be found in it. How do you debug it? A typical variable in simulink looks like this: `Simulink_Sum_Node_4521` (something similar, I don't remember exactly). Yes, that is a variable in the c code generated from simulink graphs. It's index start from 0, but you have quite a lot of it - just count the operations in your normal code, and don't forget that (a+b)/c already contains 2 operations! Not sure if the original programmer was lazy to name them all, but not sure if it is possible to meaningfully name them either. If you want to get (a+b)/c^5, (a+b) might not have a meaning on it's own. So you stuck debugging a 10k+ lines long file containing variables like this.

- Reading is natural: we read from early childhood, we write from early childhood. Did you draw computational graphs as a kid? In school maybe? Yeah, me neither. When I want to tell my colleague a formula, I'm not going to draw him/her a computational graph, I'm going to write it down. Hell, you are reading right now, and not looking at a graph consisting words and arrows that represent relations! Imagine how that would look like...

- Graphs take up much more space on the screen than text. Grab a pen and draw a computational graph of a Fourier transformation! It takes up a whole screen. As a formula, it takes up a tiny fraction of it. Our state machine used to take up about 2m x 2m on the wall behind us.

- Also the other reasons already written in this thread...

Working with simulink convinced me entirely that graphical programming has no future whatsoever.

Re: Ask HN: Why does visual programming suck?

#314
post #230

Earlier quoted context omitted.

in 3d and Audio the data is anything BUT constant. You will have to be more specific than that because I do not understand what you mean. Anything can be turned off and on.

I meant the input and output of nodes. The main thing a VST oriented VPL does is manipulating audio samples so the graph is easier to use and reason about than a generic VPL (domain specific VPL seem to thrive, I wouldn't say the same thing for generic VPLs)

No that would have been very limited. It's very important to turn on and off execution flow and of course branch it. That applies both in graphics and in sound. Why you got that impression ?

Audio VPLs are far more powerful than what you describe.

Re: Ask HN: Why does visual programming suck?

#315
post #314

Earlier quoted context omitted.

I meant the input and output of nodes. The main thing a VST oriented VPL does is manipulating audio samples so the graph is easier to use and reason about than a generic VPL (domain specific VPL seem to thrive, I wouldn't say the same thing for generic VPLs)

No that would have been very limited. It's very important to turn on and off execution flow and of course branch it. That applies both in graphics and in sound. Why you got that impression ? Audio VPLs are far more powerful than what you describe.

Example ? (And I didn't say one couldn't branch or stop the execution flow)

Re: Ask HN: Why does visual programming suck?

#316
I think that Visual Programming could be more suitable for building modern applications that may need to make web services to monitor physical devices (for example) or to gather and analyze values coming from sensors,etc... That's exactly what has driven the design or our new Visual Programming language : the need of being able to rapidly and easily build applications that connect and use technologies that were not made for working together (https://www.youtube.com/watch?v=uRWIlDXeLdk and https://www.youtube.com/watch?v=JccLWZ6nPlY). (Full disclosure, CEO of Hackeet)

Re: Ask HN: Why does visual programming suck?

#317

Earlier quoted context omitted.

> I consider UI mockups the perfect usage for visual programming environments. It can be, though the type of mockup I find more useful for discussion is much lower fidelity than that. The feedback and discussion around a mockup is related to the fidelity. Low fidelity, such as whiteboard or large sharpie drawings, will garner feedback that discusses whether this UI even makes sense at all, if there's a different appr…

Ah, I see what you're saying. Seems like you've done quite a bit of this type of work, I've the exact opposite. I guess it makes sense that the fewer data points the clients are given, the more they focus on the broader picture. Would you often start with a napkin drawing-esque mockup, and add detail to it while cooperating with the client, or would you sometimes start with a finished HTML+JS+CSS prototype and change…

I'm not a graphic designer, so I generally try not to do things that focus on the design -- which means I tend to start on the whiteboard/sharpie/napkin side of things.

That said, some people just can't picture how things look unless you show them how it looks, and in the past I've worked with clients that would think it's literally a joke (and probably fire me when they found out it wasn't) if I come to them with a sharpie drawing.

I think the only times I've gone to a more high-fidelity version up front is when the client/stakeholders had no idea what they really wanted. A "finalized" mockup can start the discussion (even if it turns out to be entirely wrong) and then be used to get into the low-fidelity whiteboard/sharpie mockups. The important thing is to keep the discussion focused on the right thing, and don't stray into fonts/images/icons if you want to talk about the overall structure and what pages even should exist.

Re: Ask HN: Why does visual programming suck?

#318

The way people have implemented visual programming has turned out to be a bit of an oxymoron. Visual and symbolic are entirely different channels of representation & understanding (for the most part). Representing a program using lines of code and throwing some "visual magic" to spread out lines of code across a screen doesn't take advantage of what EITHER visual or symbolic manipulation has to offer. Visual programm…

I wonder how Victor's Realtalk project will incorporate his interest into visual programming: https://harc.ycr.org/project/realtalk/ Also, for anyone interested it looks like he just posted on HN for the first time under user 'worrydream'.

It's going to be entirely different I feel. Instead of manipulating graphics on a flat screen, focus will probably be on manipulating physical objects on a table / in a room.

Watch his 2 talks that highlight the thinking and inspiration behind the RealTalk project:

https://www.youtube.com/watch?v=klTjiXjqHrQ https://www.youtube.com/watch?v=agOdP2Bmieg

Re: Ask HN: Why does visual programming suck?

#319
post #314

Earlier quoted context omitted.

No that would have been very limited. It's very important to turn on and off execution flow and of course branch it. That applies both in graphics and in sound. Why you got that impression ? Audio VPLs are far more powerful than what you describe.

Example ? (And I didn't say one couldn't branch or stop the execution flow)

Two materials combined to one over a 3d surface where instead of mixing in certain areas you can have one or the other depending on a texture transparency acting as a mask. Or a gradient color customized to act as a bit mask with one and off values in the colors of black and white. Non continuous data in sound can be midi or any form of modulation source like a square wave that can also act as a bit and tons of other methods.

Re: Ask HN: Why does visual programming suck?

#320
post #314

Earlier quoted context omitted.

No that would have been very limited. It's very important to turn on and off execution flow and of course branch it. That applies both in graphics and in sound. Why you got that impression ? Audio VPLs are far more powerful than what you describe.

Example ? (And I didn't say one couldn't branch or stop the execution flow)

[deleted]
Post reply on HN