Live data from Hacker News

Ask HN: Why does visual programming suck?

news.ycombinator.com

291–300 of 325 posts

Re: Ask HN: Why does visual programming suck?

#291

Earlier quoted context omitted.

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…

That's actually very interesting. Never heard of that before. A few remarks off the the top off my head: 1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different sol…

Perhaps creating niche visual DSLs is a more viable approach to developing visual programming environments than to focus on creating a general purpose programming environment.

It'd be interesting to see if there are any existing solutions in other domains.

Re: Ask HN: Why does visual programming suck?

#292

Picture says it all: http://thedailywtf.com/articles/Labview-Spaghetti :)

i program in labview daily, and it's always a little disappointing to see this same dumb picture posted all the time in reference to labview and visual programming. NO respectable labview programmer would work like that. you could make the same argument for text-based languages as well, as i have seen some atrociously formatted code in addition to poorly structured code. one of the main issues with labview is that pe…

If you hadn't had a chance to check out Labview NXG, I suggest it. 2.0 Beta is out now. Completely new editor experience. (Full disclosure, work on the core NXG team)

Re: Ask HN: Why does visual programming suck?

#293
post #229

Earlier quoted context omitted.

Welcome to the failures of Google search engine. Google is great but not so great when you try to make the search a bit smarter. I am about to "work" in the industry I have a Blender plugin and Unreal editor plugin in the works , none of the use a VPL by the way because simply what I am trying to do is too technical for VPLs that target users and not coders. But of course I will be offering VPL support because users…

Well, you said the rule of thumb was to use Blueprints unless you can't avoid C++, that implies a default. I do agree that Google's not evidence of anything, I just use it as a first approximation when I have no better sources. That said, the marketing channel of a company trying to push its tech doesn't really satisfy me either.

If that is what you mean by default then yes Blueprints are generally preferred because they are accessible both by Artists and experienced developers. C++ is generally preferred for performance reasons because Blueprints being an interpreted language is around 10 times slower ( these are estimates by Epic the creator of Unreal).

Of course how much Blueprints will be used will depend on the game. There are games made entirely with Blueprints.

Also Epic recommends the use of Blueprints as first choice again because of ease of use. They have invested a great deal to it after all. It even has a debugger with break points , watching values and visualization of execution flow.

Re: Ask HN: Why does visual programming suck?

#294
post #26

It doesn't. The electrical world has been using contactor diagrams for complex logic for decades, and with the inclusion of more advanced computer components ladder logic (still the same concepts, symbols and logic) https://www.allaboutcircuits.com/worksheets/ac-motor-control... is the link I quickly found. It's typical to see a handful of symbols handle what would take a hundred of lines of code for the level of use…

Difference here is, we are using humans to fill in the gaps. With visual programming, we either still have to draw the exact wire-diagrams, or exactly define the function of a symbol.

Quite a few PLCs have ladder logic as a programming language as a selling point.

For physical systems it is pretty true.

Re: Ask HN: Why does visual programming suck?

#295

Earlier quoted context omitted.

I consider UI mockups the perfect usage for visual programming environments. Obviously a visual product compliments a visual development interface. However, it's a very narrow realm compared to the rest of the programming universe. It's the same as saying that drawing a picture is easier for most people than programming a picture, and it doesn't really have to do with the topic of visual programming, but rather visua…

> 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 things up as they request?

Re: Ask HN: Why does visual programming suck?

#296

Earlier quoted context omitted.

which in this context is text Ha! Nice try. You program in a text file. You don't get to somehow call that a spreadsheet just to make your argument sound better. My whole point is that we need to turn that free text into a spreadsheet (from which graphs can be produced) and "your accountants will thank you".

Why is it that only very simple programs can we written effectively with spreadsheets and that setups where complex arrangements of linked spreadsheets and databases are described as horrible to work with by the people that have to work with them. Is it possible that nearly every professional is right and you are wrong and text is an effective means to represent computation.

Why is it that only very simple programs can we written effectively with spreadsheets and that setups where complex arrangements of linked spreadsheets and databases are described as horrible to work with by the people that have to work with them?

I completely understand where you're coming from. I'm saying, "try to imagine how it should be," not, "how it is." Those experiences are horrible because current spreadsheets are for simple functions and nothing more.

Is it possible that nearly every professional is right and you are wrong and text is an effective means to represent computation?

I guess this is where we disagree. I see the software industry as a mess and every professional as a person who was given one part of a Rube Goldberg contraption to be an expert on. The contraption works, to be sure, but it boils an egg in a hundred arcane steps. Given the state of our art, we have no leg to stand on to say what is and is not an effective means to represent computation. Normally a billion professionals would lend clout to your argument, but in the case of our industry, we know that they just staff a million abstruse contraptions. It just means we lack imagination and ownership: we're professionals, yes, but on whatever junk we're handed.

It wasn't always like that. We have seen that Computer Science doesn't really advance, but what is fascinating is that maybe 90% of those pushing for it to advance are of the original, older, generation that brought us that innovation in the first place. Max Planck once said something to the effect of, "Science advances one funeral at a time." I worry that Computer Science retreats one funeral at a time. Slowly we're losing those from the time when our thinking wasn't constrained with current tools; failed efforts were taken as learning points, not barriers; and no one viewed current technology as something the gods handed down to them but as something they created (maybe the day before), so they were constantly evaluating it.

Yes, the future of software development has to be away from free text toward data, and it follows as a logical syllogism. I was about to add that that is my opinion, but it's not so much of an opinion as a conclusion. While it's absolutely fair to wonder what that means, we can't brush it away because we already have the best Rube Goldberg contraption we could ever have.

Re: Ask HN: Why does visual programming suck?

#297
Imagine trying to do math without numbers. That's why visual mathematics sucks. Numbers are needed to count. We do it with our fingers when we're little, and we're limited to 10. Then we take off our socks to get to 20, but that's it.

Imagine trying to reason without words. That's why visual programming sucks. Words are the smallest units of abstraction that we can reason with. So when a visual programming language provides us with glyphs, we are already limited in our vocabulary and in what we can reason with. It becomes excruciating.

What we need is not a visual programming language, but more tools to visualize the programs that we have. Ultimately, all visuals need to fall back to literal code a parser can reason with, so there is no escaping code. In fact, there are already layers going down from the higher level languages that we use now. A practical graphical language would be one built on a higher level that adds a layer to the stack, and one which we can use or skip based on our problem at hand.

Also it is because graphics too easily limit abstractions that most graphical languages are best being domain specific. A WYSIWYG editor is for the web, the form designer in Delphi was for application layouts, and Scratch is for games.

Re: Ask HN: Why does visual programming suck?

#298
post #209

Earlier quoted context omitted.

I also hate that, but I always felt it was more a failure of the documentation writer than the GUI. "Click File -> Settings -> Whatever, open the Something tab, and click the "Do It" button under the Stuff subheading" can easily replace half a dozen unnecessary images.

GUI is documentation. If you have to document how to use your GUI you are doing it wrong.

It's not practical in a modern operating system to put every possible function at your fingertips and intuitively discoverable. There are better and worse ways to organize things, but there's just too much stuff to put all off it front and center.

GUIs are still much better than a command line in this respect, since with a GUI it's actually possible to find what you're looking for by randomly exploring, even if it's not always quick or practical.

Re: Ask HN: Why does visual programming suck?

#300
post #209

Earlier quoted context omitted.

GUI is documentation. If you have to document how to use your GUI you are doing it wrong.

It's not practical in a modern operating system to put every possible function at your fingertips and intuitively discoverable. There are better and worse ways to organize things, but there's just too much stuff to put all off it front and center. GUIs are still much better than a command line in this respect, since with a GUI it's actually possible to find what you're looking for by randomly exploring, even if it's…

One issue with GUI's is that you're sometimes stuck telling someone how to use a GUI that you didn't develop, for instance having a user manipulate settings in the device manager, which was created by Microsoft.

One thing that's rapidly improving on the command line side is Search. On my modern Windows computers (8 and 10), I don't search for things by hand in the dialogs any more. I press the Start button and start typing text.

For instance, Start plus "device manager" brings up the device manager, whereas I have no idea how to find it in the menus.

Post reply on HN