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

61–70 of 122 posts

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

#61

Post by keithnz »

seems from the bottom of the post, since he posted a picture of scratch (which is a fantastic tool!) that the author really just has an opinion about this and actually hasn't done really solid research and measured anything by actual outcomes.

The block based visual programming embraced by scratch and things like the BBS micro:bit are really good, my 7 year old son can do really cool things with these systems (also check out the new beta https://beta.scratch.mit.edu/ which is done with React for anyone interested )

You can even add this kind of visual block based coding into your own systems using something like https://developers.google.com/blockly/

I think it's a little shortsighted to think just because there's been tools that didn't really work out too well that the idea is bad

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

#62

Post by baldfat »

kpil wrote: post #39
barberousse wrote: post #25

Earlier quoted context omitted.

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

I think the future is General Purpose Languages that make DSL. Right now we have Racket and that is such a powerful thing to create DSL simply.

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

#63

Post by Junk_Collector »

blululu wrote: post #57
dpwm wrote: post #20

Earlier quoted context omitted.

There are people who swear by Labview, especially those more familiar with electronics than code. There are very good researchers I know of in soft condensed matter Physics who know they can't code but feel confident using Labview. One of the interesting things I found was that the 2-dimensional layout helped a lot in remembering where stuff was: this was especially useful in larger programs. I believe Labview barely…

Having spent a lot of time using Labview I would agree that it can be an amazingly useful tool (highly performant code and easily interfaces with data acquisition devices). That being said, LabView shows the limitations of Visual Coding: Sharp Learning Curve Difficult to find help or code snippets online Lack of decent Version Control Finding the function you want is hard (requires navigating several submenus) *All o…

Some of your complaints come from the fact that LabVIEW is pretty niche. It would need at least an order of magnitude more developers to see numbers like C/C++. That's why you're not finding much online help.

There is also the fact that LabVIEW is old. Like REALLY old. LabVIEW came out over 30 years ago and as such has a lot of legacy cruft along with lacking some of the more modern goals such as good scaling source control. LabVIEW was also designed by a hardware first company and has always been geared towards building that hardware ecosystem.

Finally, yea, poor programming practices exist in all languages. In visual languages, it makes them hard to read. Sometimes this forces you to be clever to reduce the flow complexity by increasing the logic or mathematical complexity which is it's own can of programming worms we could debate for hours.

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

#64

Post by enobrev »

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…

Back when I was doing tech-work in the financial districts of Chicago and NYC (late 90s, early 00s), some of my very favorite people were salesmen and analysts who had built these intricate and complex applications on top of Excel or Access or FoxPro or whatever.

I was just starting out as a programmer (professionally) myself, and once I was finished doing whatever I was sent to their office to accomplish, they would pull me to the side and show me their applications and pick my brain about ideas and ways to improve them or if it made sense to try a "more serious" programming language.

I was always completely floored by how much they had accomplished with every-day tools that people generally slog through out of necessity. Some of these guys were selling their applications for a solid slice of monthly income and support as well. "Normal" people building real, and truly useful applications with real domain knowledge are an absolute inspiration for me.

It reminds me a lot of web development, actually. Because everyone in their potential client-base had Excel, just as we all have browsers now. So building in Excel made perfect sense. I see the same thing happen with Wordpress or Shopify these days. Building these amazing applications that extend far beyond the purpose of the underlying application.

My early interactions with those people them helped me immensely when I went on my own full time, where I would walk into a small business and see this complicated app built upon - something - by an overworked "tech person of the office", who was clearly a bit sad that their creation was about to be replaced by some stranger. That was the person I was going to get to know and work with daily to get the application right, and I made sure they were part of every conversation.

Most of my projects are greenfield these days, but I still hold those programmers - in the truest sense - in the utmost highest regard. I still love to discuss their projects with them in the rare cases that I get the opportunity.

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

#65

Post by chaostheory »

keithnz wrote: post #61

seems from the bottom of the post, since he posted a picture of scratch (which is a fantastic tool!) that the author really just has an opinion about this and actually hasn't done really solid research and measured anything by actual outcomes. The block based visual programming embraced by scratch and things like the BBS micro:bit are really good, my 7 year old son can do really cool things with these systems (also c…

I think what makes visual programming like blockly and scratch great is that you can actually see the restrictions of various constructs like loops. The visuals are just a lot less intimidating then just seeing a bunch of seemingly free-form text where the rules aren't as obvious.

The main immediate downside that I can see is that normal programming refactoring tools are probably not going to work... yet.

I feel that this is a big opportunity for AirTable, MS & Google (for their Office software), and Salesforce to look into.

Maybe once AR and VR really take off, visual programming will have a major professional revival.

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

#66

Post by mmsimanga »

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…

To add, can you imagine if IT had to develop every single application the business thought up? They would never cope. I think Access, InfoPath and CMS systems like Drupal allow business to create prototypes. Once the application has been validated and becomes business critical then IT can take over and develop a "proper" application.

It makes sense to use a visual programming language to create basic CRUD applications. A central task list with fields that are specific to the business process can go a long way in improving operational efficiency in a business unit. Beats an excel spreadsheet.

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

#67

Post by DonHopkins »

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…

There's so much interesting prior work!

I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems.

http://donhopkins.com/home/documents/taxonomy.pdf

It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before:

http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S...

I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher.

https://archive.org/details/visualprogrammin00shu_2pf

https://archive.org/details/watchwhatido00alle

Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32:

C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion

http://www.cs.cmu.edu/~bam/acronyms.html

Also, here's an interesting paper about Fabrik:

https://donhopkins.com/home/Fabrik%20PE%20paper.pdf

Danny Ingalls, one of the developers of Fabrik at Apple, explains:

"Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"

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

#68

Post by lozaning »

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…

As a non professional programmer I much prefer the way you think about this than the author.

Rarely ever do I find myself programing for the sake of programming, it's always to serve some goal, to make some thing, fix some problem. If I write the worst code, in the worst way, and it still makes the light flash or the robot arm move, etc, then i succeeded.

I make heavy usage of the MIT Android app maker thing in my arduino and esp32 projects, and I'll be the first to admit that I use it so heavily because I have some minimal grasp of it and I've wrapped my head around most of its paradigms.

I'll admit that because I've only got a hammer, every problem is a nail, but taking away my hammer because im using it wrong just means I cant build anything.

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

#69

Post by Junk_Collector »

wenc wrote: post #59
Junk_Collector wrote: post #52

Earlier quoted context omitted.

I think it really depends on how you define a programming language. Simulink can generate a variety of codes from models, the most common being C as you mentioned, but Simulink models can also be compiled into an executable using the Real-Time Workshop toolbox. This packages the simulation engine into the model. You're right about needing code scaffolding like S-functions to compile into C but those physical model si…

I'm not entirely sure about that. Simulink solves an ODE (more or less) system internally. How did you write Pong in it, with interactive controls? I'm also not sure if Simulink (without S-functions, .m or any external programming language) is Turing complete, and even if it is, Turing-completeness is a very low bar for a programming system. Not trying to be contrarian, but from my experience, despite its many logic…

I wrote pong by encoding the ball position as a continuous complex variable and used a star chart (I-Q) with minimal persistence as the output. The paddle inputs were just variable sliders bound to a limit threshold equation. Ball motion was implemented as a normal physical system of momentum and boundaries.

Simulink models are Turing complete. You can set a discrete clock simulation (very common with the DSP toolbox) and implement Flip-Flops/Boolean logic. They are also for lack of a better term, Shannon complete, that is they have all the analog components to satisfy general function computability. They also have flow control outside of those conditions and full memory storage. If you were infinitely bored and long lived, you could write Windows in Simulink flow logic and run the modeler to make a VM.

I agree with you here. Simulink absolutely isn't meant to be a general purpose programming language. It's an extremely domain specific programming language but one that in it's specific domain offers considerable advantages over textual programming. I don't want to advocate writing software in Simulink because it's a bad idea, and I only do it myself in very limited cases because I have a hobby of analog computing and Simulink is very good for that at a certain level of abstraction.

Mostly, I just take umbrage with the Article and the author's reasoning. Simulink is a counterpoint to some of his arguments but those counterpoints were made well elsewhere in the thread so I was just providing an example.

Sorry if I am starting to drone on or come across hostile.

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

#70

Post by baldfat »

Matrix/EA used a visual language for Spore. http://puredata.info/exhibition

Pure Data (Pd) is a visual programming language developed by Miller Puckette in the 1990s for creating interactive computer music and multimedia works

https://en.wikipedia.org/wiki/Pure_Data

This is the one shinning example where a visual language actually accomplishes something that a general language can't not. Make programming accessible to creative people.

This is the only visual language that I felt was worth learning.

Post reply on HN