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

111–120 of 122 posts

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

#111

Post by jki275 »

alliecat wrote: post #110
jki275 wrote: post #100

Earlier quoted context omitted.

I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.

I say again; Don't be rude. Especially don't be mean about other people's environments for the sake of being mean about their environments. Which is what you just did.

It's not "rude", and it's not "mean" to describe something accurately. Using those adjectives is simply projecting your emotions onto a technical discussion.

LabVIEW is a cash cow that NI pushes on schools and junior EEs to make them think they're software developers, it allows them to write horrible cruft that is generally impossible to maintain. In almost every case I've seen, it's actually easier to rewrite the whole mess from scratch rather than try to decipher what someone a decade ago did as a hack that got turned into something people depend on.

You're clearly one of NI's rabid fans, you believe what you believe, but if you take personally criticism of a really poor tool, you know the rest..

I can create things in LabVIEW if I have to, I've done it and I've debugged and rewritten other people's abominations in it as well. The concept of visual programming languages is badly flawed for a variety of reasons and LabVIEW portrays each of them thoroughly.

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

#112

Post by jki275 »

detaro wrote: post #101
jki275 wrote: post #100

Earlier quoted context omitted.

I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.

What's "the right way"? Spending an extra few days on making your own visualization code, throwing away flexibility in the process?

Time spent doing it right up front pays off when someone has to maintain it.

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

#113

Post by pbazant »

weberc2 wrote: post #50

I'm not a visual programming proponent, but I don't think this article does a very good job of supporting its thesis. It exclusively makes claims about current VP implementations and tries to extrapolate them to VP in the abstract, but I think these are all non-sequiturs. I specifically think the article fails to distinguish between the dual problems of _modeling a program_ (hard) and representing that model visually…

I agree wholeheartedly with your comment -- no-one is actually saying that programming is fundamentally easy. I'd go even further and say that textual vs visual is a bit of a false dichotomy. Text is a form of visual notation. We format our source code carefully to achieve specific visual effects. The same AST can be rendered in many different ways of various visual richness. Formatted text is just one point in a continuum of possible visualisations of the same AST.

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

#114

Post by jki275 »

stinos wrote: post #109
jki275 wrote: post #100

Earlier quoted context omitted.

I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.

Well, enlighten us then. What is the right way according to you? In case of my example: what is a better way than getting things done in a few hours, with no bugs whatsoever, with all functionality needed, and just working? I'm actually truly curious as to what would be better and more right.

To begin with, the labview run time is riddled with bugs. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason.

Yes, drawing out some things in a visual IDE and having it work is nice. The problem is that eventually LabVIEW is going to update their runtime and it won't work anymore. Now what?

Take the time and do it right up front, and then when it needs to be updated people aren't cursing "whoever decided to do this in LabVIEW years ago" as they often do in these situations.

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

#115

Post by blbviviv »

maxxxxx wrote: post #48
AnIdiotOnTheNet wrote: post #43

Earlier quoted context omitted.

Indeed. I once thought as the author did, and as I'm sure many programmers do, that things like VB and Flash and Excel macros were a blight upon the world. But a lot of useful work got done with VB, careers were launched from humble beginnings on Newgrounds, and Excel is one of, if not the most, popular tools in all of business. I think John Ohno does a good job of articulating what's so great about these tools in hi…

VB and Excel have the advantage of having full blown programming language behind them so you can implement very complex things. I compare this to Labview where everything is visual and things get out of control pretty quickly.

Labview has m-script (which is matlab like)

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

#116

Post by maxxxxx »

blbviviv wrote: post #115
maxxxxx wrote: post #48

Earlier quoted context omitted.

VB and Excel have the advantage of having full blown programming language behind them so you can implement very complex things. I compare this to Labview where everything is visual and things get out of control pretty quickly.

Labview has m-script (which is matlab like)

How does this relate to the visual programming stuff? Can you go back and forth or is it a separate thing?

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

#117

Post by kpil »

jakelazaroff wrote: post #53
kpil wrote: post #39

Earlier quoted context omitted.

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 langua…

Obviously these are sweeping statements, but the problem with this generalization is that successful DSLs become invisible because we take them for granted. Regular expressions are a DSL. SQL is a DSL. LaTeX is a DSL. The Wikipedia page on domain-specific languages even lists HTML as an example: https://en.wikipedia.org/wiki/Domain-specific_language#Examp... With regard to LaTeX or HTML, you could even argue that the…

I would argue that perhaps with the exception of regex, the examples you mentioned are excellent ideas that are awsome despite their suboptimal DSLs, and they would have been even better if their DSLs had been implemented as extensions in a Lisp-like language.

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

#118

Post by nailer »

dyarosla wrote: post #47
nailer wrote: post #8

Earlier quoted context omitted.

Arrays and Objects and trees and everything else in an AST (including the AST itself) are shapes. Shapes are better built with our hands. They're often filled with text, which is more easily said than written. Someone can already use a visual programming language to simulate the ocean in UE4 in 2018, in 20 years we'll have a mainstream general purpose visual programming language. More people might be using a visual p…

UE4 blueprints are an example of a domain-specific VPL that I've mentioned above (a good example of where VPLs can work great). They however do not solve the problem of working with abstractions well- UE4 blueprints are akin to, how the author put it, "property dialogue programming". So far, any attempts to model abstractions for general purpose VPLs have ended up more difficult to parse and read than textual code (t…

Sorry, why isn't it a solid argument? I'm imagining building an AST representation that looks like our current one, since there's less abstraction, but using our hands and voice. Optimising the appearance can come later.

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

#119

Post by stinos »

jki275 wrote: post #114
stinos wrote: post #109

Earlier quoted context omitted.

Well, enlighten us then. What is the right way according to you? In case of my example: what is a better way than getting things done in a few hours, with no bugs whatsoever, with all functionality needed, and just working? I'm actually truly curious as to what would be better and more right.

To begin with, the labview run time is riddled with bugs. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason. Yes, drawing out some things in a visual IDE and having it work is nice. The problem is that eventually LabVIEW is going to update their runtime and it won't work anymore. Now what? Take the time and do i…

do it right up front,

Ok, but again what do you suggest is 'right' then, any example? Because as laid out, for me, it is right, since we have zero problems.

Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason.

Hmm, strange. Sounds to me like those creators must be doing something wrong. I mean, we've been running a couple of Labview applications for +10 years and I honestly think none of them ever crashed (where 'crash' means suddenly stops working without apparent reason because of a bug in Labview itself, not come to a halt due to programmer error). Also wen to, I don't know, 3 or 4 updates, without much problems. Again I think it just comes down to hwat I said first: the hard part might be fuguring out how to do Labview right, I guess.

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

#120

Post by posterboy »

maxxxxx wrote: post #116
blbviviv wrote: post #115

Earlier quoted context omitted.

Labview has m-script (which is matlab like)

How does this relate to the visual programming stuff? Can you go back and forth or is it a separate thing?

It is used to write additional components to be used in the visual editor. A code block, like a custom macro in spreadsheets.
Post reply on HN