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

Visual Programming Is Unbelievable (2015)

outsystems.com

Post reply on HN
Print view View original

41–50 of 107 posts

Re: Visual Programming Is Unbelievable (2015)

#41

Post by DonHopkins »

ksnieck wrote: post #34
hacker_9 wrote: post #26

Earlier quoted context omitted.

Yet user's of LabView describe it as a horror to actually use practically [1]. [1] https://jshoer.wordpress.com/2007/08/03/why-i-hate-despise-d...

This person is very inexperienced with LabVIEW. The first two points are not true, and there are lots of hidden shortcuts for removing mouse use. (Ctrl-Space) I was similarly furious with LabVIEW before I started working with people who had been using it for decades. It's the easiest language I've used for making graphical user interfaces.

There are so many vastly different approaches to visual programming out there, that anecdotes about one person's bad experience with one particular decades-old system or application doesn't invalidate the whole idea of visual programming.

I'm very impressed by the usability of Grasshopper [1], the visual programming language in the Rhinoceros3D [2] nurbs modeling tool.

It feels like the people who designed it use it themselves regularly, which can't be said for many other visual programming languages. Plus the user interface and component libraries are built on top of and integrated with the wonderfully powerful set of graphics capabilities that Rhino supports.

Grasshopper is very popular for architecture design [2], and even jewelry [4] and 3d printing.

[1] http://www.grasshopper3d.com/

[2] https://www.rhino3d.com/

[3] http://www.grasshopper3d.com/video/video/search?q=architectu...

[4] http://www.grasshopper3d.com/video/video/search?q=jewelry

Re: Visual Programming Is Unbelievable (2015)

#42

Post by carsongross »

Visual programming does not work well mostly due to a physical problem: typing characters into a computer is much faster and flexible at generating imperative code than using a mouse. There are declarative domains, such as simple UI building, where that is less true, but even then, when you kick out to the event handler, text is much faster.

IntelliJ has done more for visual programming, by integrating visual/wizard aspects seamlessly into a text-dominant environment, than almost all the visual programming advocates of the last fifty years.

Visual environments do demo well, and sometimes convince businessmen that they won't need to pay those annoying and expensive programmers so much money. Hence its enduring appeal to the business world.

Re: Visual Programming Is Unbelievable (2015)

#43

Post by aniijbod »

Software developed using visual programming languages often has the potential/necessity to include content which constitutes a 'visual/non-visual hybrid' as the application becomes more complex: the boxes to which arrows are connected usually contain things which are lines of text/symbols/formulae, i.e. are not 'diagrammatic'. Visual programming languages tend to use diagrams for structure and 'notationally rich text' for content and are therefore addressing requirements for simplifying the representation of and increasing the intelligibility of the structure of application development as their highest priority. The reason why this rationale can seem to be problematic is because justifying/achieving the job of meaningfully 'separating structure from content' in software brings it's own highly contingent/subjective challenges (as any detractor of object-oriented design will be aware). For instance, how far could/should you go in trying to 'diagrammatise' the notational content of boxes in a boxes and arrows language. Is the fact that you are diagrammatising the app at all enough of a benefit in terms of reducing the learning curve/programming aptitude requirement, such that 'further/total diagrammatisation' is nothing more than a 'diminishing returns' consideration? What criteria do you use to decide the 'diagramtic benefit limit'? The biggest growing business in software development today is 'triple A games development' and visual programming languages are used as a way of giving designers the means to create content and gameplay without requiring the designer to have programming skill levels that match those of developers (developers can then optimise the designer's work by converting it into C++ to get the frame rate up and integrating it with the rest of their native codebase). Here's an example of an impressive case in point done in UE4 Blueprints without a single line of C++: https://www.youtube.com/watch?v=EjCandEgtHo

Re: Visual Programming Is Unbelievable (2015)

#44

Post by nwah1 »

bantunes wrote: post #38

I don't get it - isn't the Outsystems Platform (following the link from the blog) a visual programming environment? This article seems very odd coming from Outsystems itself. What am I missing here?

Showing that you're aware of all the drawbacks may give customers more confidence that they've been addressing them.

I've used outsystems, and it was straightforward. Although I prefer C#.

Re: Visual Programming Is Unbelievable (2015)

#45

Post by 127001brewer »

...otherwise you might just end up in the wrong side of history.

And I don't believe it worked within the US Army [0][1][2] - unless I'm not correctly remembering the history of Outsystem's Visual Programming there...

[0] https://www.outsystems.com/company/news/2012/outsystems-us-a... [1] http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_f... [2] http://www.afcea.org/content/?q=us-army-innovates-cloud-comp...

Re: Visual Programming Is Unbelievable (2015)

#46

Post by zapov »

bantunes wrote: post #38

I don't get it - isn't the Outsystems Platform (following the link from the blog) a visual programming environment? This article seems very odd coming from Outsystems itself. What am I missing here?

They are probably dissatisfied with developer stance toward their RAD framework.

I'm sure various business apps can be built successfully on top of their Visual programming IDE, but even Microsoft has mostly abandoned that route.

But I dislike that even they propagate the lie that systems are slow when built on top of "High level language". That is mostly an optimization problem and you can often optimize well beyond what people would be willing to do in lower level language.

Re: Visual Programming Is Unbelievable (2015)

#47

Post by pier25 »

Visual programming is exploding in Unreal Engine with Blueprints to define in-game behaviours.

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...

I for myself think visual programming is not really programming, since by following that train of thought any GUI like Photoshop Actions could be considered programming.

Re: Visual Programming Is Unbelievable (2015)

#48

Post by tluyben2 »

I worked quite a bit with Outsystems and like with all the tools that use boxes(/balls) with lines between them as 'visual programming', it depends largely on how you organise things if / when it becomes a big mess. After a while of working with it we usually just wrote what we needed in C# and when we had very abstract things hooked them up. It looks/works well but needs a lot of discipline (and thus training) and it's crazy expensive (for what it does) imho.

Re: Visual Programming Is Unbelievable (2015)

#50

Post by mtanski »

RealityVoid wrote: post #20
mtanski wrote: post #9

There is one place where visual programming is alive and well and has been for a long time. That's programming PLC (Programmable Logic Controllers). It's easy to forget about PLCs[1], but it's an old and large niche in large corporations that do a lot of industrial automation like assembly lines, (automobile) manufacturing, oil & gas... Most PLC programming is done using Ladder Logic [2] and various visual tools tool…

Except the programming is shit. My first job was building DCS software for coal power plants. We had such a graphical programming language. I can assure you, it was a pain in the butt to work with. Oh, you want to build many similar logic systems? Go ahead, do the SAME thing 200 times, click spamming is your job. The technology is used not because it's good, but because the industry is stuck in the 80's. I understand…

Never said it a great experience, just that they used visual programing to express logic flow.

And I agree, the "language" forces you to repeat yourself. I believe that over the years there's been attempts at alternatives but none of them caught on. The only new things you see if faster hardware (PLC), new buses (took forever for ethernet to catch on) and new classes of IO / devices to control.

The controls / industrial automation industry has different set of constraints & values. It's a very conservative industry. Double so if what you're programming is safety and error proofing.

So the industry values tools that consistent, maintainable (by current / future staff). There's many cases where you might be supporting an installation with a mixture of both new and 20 year old hardware.

It is just a different world.

Post reply on HN