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

41–50 of 122 posts

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

#41

Post by hinkley »

> The lack of good source control is another major disadvantage of most visual programming tools.

I think this is underselling the point.

Lack of good source control is a non-starter for any programming paradigm. If you want to do visual programming or any other kind of programming that doesn't dovetail with directory tree of text files, you are not going to get anybody serious to work with you until you fix that problem.

The first problem you should solve is not how to compile the code, nor how to debug the code, but how to store it.

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

#42

Post by jononor »

hinkley wrote: post #41

> The lack of good source control is another major disadvantage of most visual programming tools. I think this is underselling the point. Lack of good source control is a non-starter for any programming paradigm. If you want to do visual programming or any other kind of programming that doesn't dovetail with directory tree of text files, you are not going to get anybody serious to work with you until you fix that pro…

Jupyter notebooks is a counterexample. Its annoyingly unfriendly to source control, but is still quite popular (and growing).

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

#43

Post by AnIdiotOnTheNet »

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…

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 his article "Big and small computing" [0].

[0] https://hackernoon.com/big-and-small-computing-73dc49901b9a

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

#44

Post by jack_h »

> The final misconception is that visual programmers can do without all the tools that have been developed over the decades to support programming. Consider the long evolution of code editors and IDEs. Visual Studio, for example, supports efficient intellisense allowing the look-up of thousands of APIs available in the base class library alone.

I think this point the author makes is an interesting one because I see it form a different perspective. I think the biggest issue is that we mix presentation with representation.

> The lack of good source control is another major disadvantage of most visual programming tools. Even if they persist their layout to a textual format, the diffs make little or no sense.

At the same time tabs vs spaces is still a thing. In languages which aren't whitespace sensitive, the diffs similarly don't make any real sense in my opinion.

I believe (and have no idea how to implement) that the representation of a programming language should be modified more directly and the rendered presentation (textual, visual, interpretive dance) should be irrelevant to the tooling.

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

#45

Post by wenc »

This sounds analogous to the argument that mathematicians used to have: whether abstraction trumps intuition, especially in geometry.

For instance, you can't really plot a 25-dimensional object, but the same object is trivial to manipulate with equations.

It's clear to most people that both approaches have their place. In geometry, the visual component is very important to develop important intuitions about how objects behave in low dimensional space. On the other hand, if one were to insist on the visual, one would be stuck with purely intuitionist ideas and never be able to move into more complicated realms where you cannot visualize objects graphically (e.g. high-dimensional space).

The Bourbaki group was a group of mathematician who aimed to put mathematics on a rigorous foundation by developing the abstractions that shaped modern math, and by moving mathematics past its intuitionist foundations. Some argue that this caused modern "geometers" to lose their feel for geometry because everything became about symbols. But without this development, a lot of modern discoveries might not have been possible.

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

#46

Post by DonHopkins »

Years ago I developed a visual interface to an existing non-visual language, the multi threaded object oriented dialect of PostScript in the NeWS window system. Since PostScript is homoiconic, the data viewers and editors could also be applied to code!

It didn't try to replace text based PostScript programming, just augment it: there was an interactive shell window you could type expressions to, which had a stack "spike" sticking out of it representing the PostScript stack, which would update in response to the commands you typed, or you could drag and drop objects to manipulate the stack and the state of the system.

You could perform "direct stack manipulation" by dragging objects up and down or on and off the stack, open up nested objects and functions in an outliner, adjust the point size and formatting style, open up special editors on data and code, drag and drop objects and code around, etc. It was like a live Smalltalk system, in that you could explore (and vandalize) the entire state of the window system, and use it as a debugger to inspect and modify and debug processes of other NeWS clients (including itself).

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

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

#47

Post by dyarosla »

nailer wrote: post #8
dyarosla wrote: post #4

Pros The author well formulates the limitations of VPLs (Visual programming languages). Cons The rant seems to jumble in VPLs for general purpose programming with VPLs for domain-specific usecases. So although VPLs may be "a bad idea" for general purpose computing and does a good job of explaining its downsides, it is a little reckless in saying VPLs are a bad idea overall. The author also offers two straw man argume…

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 (that argument can also be made for UE4 Blueprints[0]).

Talking about "shapes are better built with our hands" isn't a solid argument for why general purpose VPLs are bound to happen. Note, too, that I would love for them to.

[0] https://blueprintsfromhell.tumblr.com/)

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

#48

Post by maxxxxx »

AnIdiotOnTheNet wrote: post #43
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…

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.

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

#49

Post by hinkley »

jononor wrote: post #42
hinkley wrote: post #41

> The lack of good source control is another major disadvantage of most visual programming tools. I think this is underselling the point. Lack of good source control is a non-starter for any programming paradigm. If you want to do visual programming or any other kind of programming that doesn't dovetail with directory tree of text files, you are not going to get anybody serious to work with you until you fix that pro…

Jupyter notebooks is a counterexample. Its annoyingly unfriendly to source control, but is still quite popular (and growing).

There are a lot of very complicated documents and visual displays that can be built by a collaboration of 2 or 3 people where word of mouth suffices to deal with problems of simultaneous edit. Effectively it's ad-hoc optimistic locking with a coordination phase.

None of these models scale to teams of 10, 20, 100 people. Even at 4 they begin to become tedious.

The biggest problem with software developers is confusing "successful" with "applicable to everybody", and this is a prime example. It doesn't matter if it's successful. It's not applicable to my work. Excepting, perhaps, for Wiki-like workflows, which are less than 10% of my duties.

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

#50

Post by weberc2 »

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 vs textually.

For example, the article claims that the idea behind scratch is that programming is fundamentally easy but text makes it hard. I don't think that's the idea at all, but rather that programming (i.e., modeling a program) is fundamentally hard, but the difficulty is compounded because text is not a natural way for the current crop of humans to think about a program.

Another example is his criticism of the failure of enterprise UML tools--presumably the problem with these is that UML is just not a very good way of _modeling a computer program_, regardless of whether the interface to UML is visual or textual.

Another example is the criticism that the current crop of VP tools are procedural. Why can't a visual programming language be functional?

Another is the claim that VP is bad because the current crop of tools combines visual and textual programming (I'm not sure this is even true; I don't recall LabVIEW requiring text, for example). Is there any fundamental reason a programming model can't be purely visual? Why can't you represent a whole programming model (all the way down to primitives) visually?

I think most of these would be solved with more trial and error and more investment; none of these support the thesis that VP is fundamentally a bad idea.

To be clear, I think this article has a lot to offer people who are trying to solve visual programming issues, but it doesn't make the case that it sets out to do--that visual programming is fundamentally a waste of time.

Post reply on HN