Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Programming – Why It’s a Bad Idea

mikehadlow.blogspot.com

Post reply on HN
Print view View original

31–40 of 122 posts

Re: Visual Programming – Why It’s a Bad Idea

#31

Post by jki275 »

wenc wrote: post #15
jacinabox wrote: post #2

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

It's also a long-term maintenance challenge, especially when you have complex models. Great for prototyping stuff fast, but hard to maintain in production. It was designed for people who aren't programmers to be rapidly productive especially when interfacing with hardware (in a lab environment). However, debugging complex topologies can be a real challenge. We have Labview models that are being rewritten in conventio…

It really ultimately has to be if it's to be maintained. LabVIEW is fine for basic prototyping, the problem is that EEs tend to think they've created the mona lisa of program design when they've built a barely functional prototype and then distribute it as a finished product.

Re: Visual Programming – Why It’s a Bad Idea

#32

Post by awesomelybad »

omnibrain wrote: post #13

Our company develops a software for alarm receiving centers. In our software our customers can use a visual code editor http://pfau.de/images/beispiel002.gif to program their own processes for alarm reactions. That is actually our main selling point. They can control the user interaction (what to do, who to call, etc) in reaction to an alarm, access all the data to change process outcomes in response to data or user…

It feels like it's easier to understand a complete process flow like this visually; sure a developer could probably implement individual steps for a complicated workflow faster as code, but only if they already understand how the process needs to flow in the first place. The visual paradigm almost acts to shortcut the need for a developer to "get in the zone" and load up a mental model of decision tree, but at the cost of a more rigid implementation model (you have to work within the framework of the UX that you're provided, and pretty much any GUI will fail to keep up with the speed the most advanced users "could" work at). On the other hand, I can't imagine implementing something like your example graphic in code without at least whiteboarding it out ahead of time, which is effectively just an analog way of doing visual programming.

Re: Visual Programming – Why It’s a Bad Idea

#33

Post by crimsonalucard »

Last I heard text is visual... so then what is text but a form of visual programming?

In essence text is visual programming limited to set of symbols and tokens parsed in left to right order.

Who said that this arbitrary set of rules is the best way to represent programming logic? The number of concepts for abstraction encompass many things in the visual realm. Graphs, procedures, arrows and even 3D space can be used to represent logic... Obviously with a space this big, text is unlikely to be the best way.

Text based programming is simply a local minima that is seemingly the optimal minimum. The problem is we're so deep in this minimum that it's hard to climb out.

Re: Visual Programming – Why It’s a Bad Idea

#34

Post by alliecat »

jki275 wrote: post #23
jacinabox wrote: post #2

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

LabVIEW is a... toy for children.

Don't be rude.

LabVIEW is used in production in a lot of serious environments.

Re: Visual Programming – Why It’s a Bad Idea

#36

Post by Immortalin »

eigenloss wrote: post #30
Immortalin wrote: post #27

In the early days of KloudTrader, we attempted to use Visual Programming too. https://web.archive.org/web/20171006072839/http://www.kloudt... The main difficulty was scale and tradeoffs between power vs ease-of-use. We spent a lot of time creating "subroutine blocks" for the most commonly used functions and optimizing for UI/ease of use that we weren't doing much else. Furthermore, pretty much every integration, libr…

Was "CloudTrader" taken?

The domain yes, check us out:

https://KloudTrader.com/narwhal

Re: Visual Programming – Why It’s a Bad Idea

#37

Post by rwmj »

gambler wrote: post #9

There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks": https://www.youtube.com/watch?v=6orsmFndx_o https://www.youtube.com/watch?v=I9LZ6TnSP40 https://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.h... http://worrydream.com/ And yes, this: http://www.fantasticcontraption.com/ This is not 100% real programming, because it does not include sensors, but you do create const…

I thought this presented an interesting visual programming concept:

http://www.chorus-home.org/

More in these videos: https://vimeo.com/179904952 https://vimeo.com/274771188

Re: Visual Programming – Why It’s a Bad Idea

#38

Post by jki275 »

alliecat wrote: post #34
jki275 wrote: post #23

Earlier quoted context omitted.

LabVIEW is a... toy for children.

Don't be rude. LabVIEW is used in production in a lot of serious environments.

I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code.

LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.

Re: Visual Programming – Why It’s a Bad Idea

#39

Post by kpil »

barberousse wrote: post #25
topkai22 wrote: post #17

Visual programming languages will only take you so far, but often that is far enough. What the author misses is that we as professional programmers miss the success stories, because we only get called in when the boundaries have been reached. In my career I’ve often been asked to rewrite Access DBs, InfoPath forms, or SharePoint sites developed by amateurs into something more usable. My early reactions where along th…

I think the broader, opposing point you bring out is that visual programming is perfectly suitable for specific scopes of computational modeling, and that's just because they're DSLs, and we already know DSLs are the right choice for a number of problems. I'd like to know who the author things they're engaging with on the points they're making.

I disagree that DSLs are the right choice unless it's an extension to the suitably flexible implementation language itself.

Actually, the perceived need for "dumb" DSLs is sprung from the same misconceptions as mentioned in the article and the end result is inevitably that simple problems are made somewhat simpler and complex problems turn into impossible problems.

A proper DSL extension in an unobtrusive host language is another thing but also hard to find. If a Lisp syntax is acceptable then that's the canonical example.

I don't want to get depressed overe all misconcieved excuses for test automation languages, process automation, configuration templating systems, etc, so I'll just stop here.

Re: Visual Programming – Why It’s a Bad Idea

#40

Post by lucozade »

jacinabox wrote: post #2

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

I was very impressed by Mark Elendt's talk at CppCon about the Houdini system. It contains a very sophisticated visual programming "language".

My view on this is that text is one of the best media we have for representing precise, information dense data.

What I got from the Houdini presentation was that, when someone is trained to produce precise, information rich data using other media e.g. artists then other representations can be as effective.

Post reply on HN