21 ms·

Ask HN: Why does visual programming suck?

• cocktailpeanuts 9y ago
  If you want an answer to your question, you yourself should know what you're asking. I honestly don't know if you're asking a rhetorical question, complaining about the reality, or asking for feedback on your idea. You are talking about multiple things at once here: 1. asking why visual programming sucks; 2. Talking about your experience with Alan Kay; 3. talking about your idea of an ideal visual programming method.
  • dvdhsu 9y ago
    Thanks for the feedback! I'm asking about 1. and 3. 1. I have a theory on why VP sucks -- is it right? What do other people think? 3. Yes -- I'm looking for feedback, but in the context of why visual programming is no good. Also because of below: 2. I brought that up because visual programming is big, which is a good point that Alan Kay made. So I provided an example, or idea that I had. Is visual programming bad in this case? Why, or why not?
  • freehunter 9y ago
    Luckily we're on an Internet forum where people can take their time to read the question and then have even more time to figure out how to respond, what to respond to, and what to ignore. It's entirely possible to have complex conversations here where more than a single topic is being discussed at one time. This isn't Stack Exchange.
• mabynogy 9y ago
  Because of the Deutsh limit: https://en.wikipedia.org/wiki/Deutsch_limit https://en.wikipedia.org/wiki/Deutsch_limit
  • jpm_sd 9y ago
    That's like saying it's impossible to design a motherboard because you can't show all the bypass capacitors on the top level schematic. Hierarchical design and layers of abstraction are vital in both hardware and software.
    • BevanR 9y ago
      True; but visual programming means you need more 2D space (screen) to see the same amount of logic. Maybe with bigger screens it could work better?
  • BevanR 9y ago
    Which is; > "The problem with visual programming is that you can’t have more than 50 visual primitives on the screen at the same time."
• petra 9y ago
  One modern incarnation of visual programming is called "low code", and it seems pretty successful. This is a good introduction and discussion about whether this is a fad or it's here to stay: https://medium.com/softwareimprovementgroup/low-code-wave-of-the-future-or-blast-from-the-past-7fcd618371b2 https://medium.com/softwareimprovementgroup/low-code-wave-of...
  • bcherny 9y ago
    Looking at the website [0], this is a joke right? Flashy marketing business speak sales site with charts, but what does the product look like? [0] http://low-code.com http://low-code.com
    • petra 9y ago
      You're kidding, right ? that's a really low effort search :) Anyway, i gave a link above, with good info, including names of leading companies. Here's one: https://www.mendix.com/ https://www.mendix.com/
      • dalacv 9y ago
        Also , outsystems and bubble.is, oracle Apex
• mcphage 9y ago
  That's how Interface Builder on macOS/iOS works, especially in concert with Key Value Coding and Key Value Binding. It's cool stuff, check it out.
  • thebaer 9y ago
    As a fellow mobile developer, I highly prefer Android's non-visual option with human-readable and -editable XML. I always find myself editing layouts textually and then just using the visual editor to preview how things look. Interface Builder was great for me at first, when learning iOS-specific controls and how everything worked, but as I've gotten better I've found it's always more of a hindrance. Things really start to break down when you need to move fully laid-out controls to a new container, for example, whereas Android's XML layouts let me do that by deleting/changing a few lines of text.
• eikenberry 9y ago
  Part of the problem might just be that you are ultimately comparing it to using text for programming and that text just works extremely well for the vast majority of programming.
• hacker_9 9y ago
  There is a couple of reasons. First, VP is essentially just putting code snippets into nicely coloured boxes, which adds no value apart from making you have to scroll/zoom more. Additionally the structure of the visual becomes important, opposed to text which can be infinitely appended to, and so once you add enough complexity the whole thing becomes complete spaghetti. VP also hides away a lot of implementation details from you, and assumes the computer will be able to figure out something better than the programmer. For example, when would the dropdown run the SQL query? on page load? on drop down open? As you scale the app bigger, you may want to run a single SQL query and then chop up the results and hand them out to several dropdowns. If your VP interface doesn't support this then your done for, but with code there is always a way. There is always Clojure of course, which lets you edit your GUI while the app is running, and upload code changes without having to rebuild, allowing you to tweak stuff as you go. REPL driven development is great as it gives you both the flexibility of written code, as well having close to the interactivity that VP offers.
  • phkahler 9y ago
    >> For example, when would the dropdown run the SQL query? on page load? on drop down open? You seem to be dancing around what I came to comment on, and that is event driven programming. It's OK for simple UIs but it tends to break down as complexity increases.
• FrankyHollywood 9y ago
  Picture says it all: http://thedailywtf.com/articles/Labview-Spaghetti http://thedailywtf.com/articles/Labview-Spaghetti :)
  • mathgenius 9y ago
    See also: the mighty spreadsheet.
  • nikofeyn 9y ago
    i program in labview daily, and it's always a little disappointing to see this same dumb picture posted all the time in reference to labview and visual programming. NO respectable labview programmer would work like that. you could make the same argument for text-based languages as well, as i have seen some atrociously formatted code in addition to poorly structured code. one of the main issues with labview is that people simply don't take it seriously as a programming language. if people watched how i work everyday, i work just the same as, if not more efficient than, a good text-based programmer.
    • Too 9y ago
      I've also done labview and have to agree that the picture is a bit extreme. Even so, extract the bottom left corner of that picture for something a bit cleaner and more representative of code in the wild but it's still completely impossible to see wtf is going on there.
    • stinos 9y ago
      it's always a little disappointing to see this same dumb picture posted all the time in reference to labview Yup. It's not unlike the -insert whatever language here (C++ being a good choice)-haters ranting but not actually having used it a lot, or at all. Moreover: depending on the type of UI, I don't think there is any language out there which can get me the results I need as fast, when I need something 'process control'-like, i.e. lot of display of e.g. electrical signals and a bunch of control buttons/textboxes/comboboxes. Then there is just no match for Labview. And I have quite some experience with writing UIs in WinForms/WPF/Qt... (typical example: good luck writing a pannable, zoomable, cursor-able live multisignal 2D graph in any of those - with labview you just feed data into the premade component and you're done) It even goes so far that even though the backend is in C++ or Python, I might take the overhead of writing IPC between backend and Labview frontend over doing the UI in the backend language.
• ThomPete 9y ago
  Because it's not optimal for programming. It's however great for scripting. If you are a good enough programmer you want the power of ex regular expressions and you can solve almost any problem out there. If you aren't you aren't much better off as you still need to learn how to program. As a scripting language however it can be great because you can be much more opinionated about what should be prioritized. What would be much more interesting and useful IMO was if normal languages created a visual environment akin to the visual programming languages we see sometimes.
• mafribe 9y ago
  Graydon Hoare (Rust creator) has an interesting post on a related matter "always bet on text" http://graydon.livejournal.com/196162.html http://graydon.livejournal.com/196162.html
  • trevyn 9y ago
    I deeply enjoy how this post uses images to illustrate its points. :)
• pshc 9y ago
  I'd like to share some thoughts: - Visual programming tools usually only work at one abstraction level (your first point) - Often centered around a gimmick and cannot encode "normal" detail-oriented imperative code efficiently - Only a fraction of a given program is amenable to flow charts, Visual Basic-style forms, etc. Unfortunately, most visual programming environments are all-encompassing. - So VPs tend to become blunt, awkward tools that lack power of expression, ergonomic editors, scalability to real usecases, etc. FWIW, I do believe that a better code editor is possible through non-plaintext programming. (Serialize token trees and ASTs, instead of plaintext.) But such an editor would likely be used in text-editor-mode >50% of the time, just due to the high information content and sheer readability of text.
  • meredydd 9y ago
    > I do believe that a better code editor is possible through non-plaintext programming. (Serialize token trees and ASTs, instead of plaintext.) Funnily enough, this is itself another of those mirages, like visual programming, that have been chased for years and failed to gain traction (outside specialised applications). For my money, the reason for this is that a human editing code needs to write something invalid - on your way from Valid Program A to Valid Program B, you will temporarily write Invalid Jumble Of Bytes X. If your editor tries to prevent you writing invalid jumbles of bytes, you will be fighting it constantly. The only languages with widely-used AST-based editing is the Lisp family (with paredit). They get away with this because: 1. Lisp 'syntax' is so low-level that it doesn't constrain your (invalid) intermediate states much. (ie you can still write a (let) or (cond) with the wrong number of arguments while you're thinking). 2. Paredit modes always have an "escape hatch" for editing text directly (eg you can usually highlight and delete an unbalanced parenthesis). You don't need it often (see #1) - but when you need it, you really need it.
    • pshc 9y ago
      I've been thinking along the same lines. The "fighting your editor" problem cannot be ignored, and it's common in VPs. Real programming code needs "jank". We need to be able to move between different states: Bags of characters <-> Unstructured trees of tokens <-> ASTs (BTW paredit is super cool and I'd like to see more of its kind!)
• david927 9y ago
  I disagree with several here: The problem is that we still program in text, and that's deeply sub-optimal.* Once we move to programming in data, visual programming becomes both natural and intuitive, much like data visualization. In other words, VP itself is a red herring. The leap that needs to first to be made is that from text to data. *https://www.emaze.com/@AWOCZQLL/Text-is-for-Novels https://www.emaze.com/@AWOCZQLL/Text-is-for-Novels
  • icebraining 9y ago
    That's the claim, but where's the evidence? Is there any implementation that can show us that?
    • david927 9y ago
      It will come. Nothing today. The leap that needs to be made is actually in the data structures themselves but I understand your skepticism until it arrives.
  • nzonbi 9y ago
    Interesting presentation. One thing that we agree, is that the current state of programming is not final. There have to be better ways for humans to program. I wonder how much people thinks like that. A poll would be interesting. In reality, programming has been stuck in the text approach for many years. Perhaps some people take that as evidence that there is no more progress to be made. Another factor that may be undermining research in programming, is the AI boom. Perhaps some think that AI will displace programmers in a not too distant time. I agree with you that programs are data. And would benefit from a more specialized representation. I have been researching the aspect of program logic. For example, one thing that I think is terrible in programming, is deep nesting levels. That makes it complex to follow programs. I have been exploring ways to improve that. In my opinion graphical visualizations can provide ways to improve that.
• Edmond 9y ago
  I don't think it is the paradigm that sucks but the existing implementations...it is a hard design problem to solve. No one has quite figured out the right approach....often the existing implementations make you click and fill out enough fields to make the entire exercise much worse than just coding something up in a text editor. I believe the solution lies in coming up with a way to compose pre-built components into complete applications...I think the existing efforts involving Angular,React,VueJS,Vaadin..etc are all pointing in the right direction....I have been working on Solvent (www.crudzilla.com) for sometime now and solving the UI building (drag-drop) is something that I am still actively thinking about...one of these days someone will crack the problem :)
  • djedr 9y ago
    > I don't think it is the paradigm that sucks but the existing implementations...it is a hard design problem to solve. No one has quite figured out the right approach....often the existing implementations make you click and fill out enough fields to make the entire exercise much worse than just coding something up in a text editor. True. That's why a proper visual programming environment should build on existing text-based environments and offer the same capabilities while adding power. Not disregard all progress, conventions, and achievements and start form scratch offering some unique features, but at the same time taking away stuff that's already been figured out.
    • Edmond 9y ago
      Agreed, that is more or less the approach I have taken with Solvent...it has a familiar IDE environment with the additional visual layer on top of it.
• threefour 9y ago
  Imagine a world where people only bought bespoke suits. You go to a tailor and are measured and pick out your fabric and wait a few weeks. Then you pick up your suit. It's perfect. You pay $5000 and take it home. Most of us don't do that. Most of us make due with off the rack suits with some tailoring for 1/10th the price. With programming we have an expectation of bespoke design, so anything less, even if it's much easier, seems lame. A potentially useful reframing of the question is, "What are all the common use cases that could be solved sufficiently with significantly less effort using visual programming?"
  • nickpinkston 9y ago
    More like you please :-)
  • dsjoerg 9y ago
    you win the prize for asking the right question. the answers are like with AI, where once it's done in a certain domain, then that's not AI anymore. that is, with visual programming, once it's done in a particular domain, people don't think it's programming anymore. the big examples i have in mind are: * spreadsheets -- very visual, everything's in a grid. the relationships are spatial. * electronic music -- people lay out their various effects in a flowchart format and chain them from one to another * video games -- consider a game like RimWorld. you're clicking on all kinds of things and specifying what you want done with them. the behavior of the actors in the environment are modified by your specifications. So, it's all in various optimized subdomains. As it should be!
    • kig 9y ago
      And who could forget the most successful visual programming tool of them all: Photoshop. A relatively simple visual programming language for putting together programs that generate images of various kinds. Most of the things you do are achieved through a visual programming environment specialised for that particular task. Maybe text-based source files in complex directory trees, managed through a structured text editor with UI composition helpers represents one kind of specialised visual programming environment as well.
• skadamat 9y ago
  The way people have implemented visual programming has turned out to be a bit of an oxymoron. Visual and symbolic are entirely different channels of representation & understanding (for the most part). Representing a program using lines of code and throwing some "visual magic" to spread out lines of code across a screen doesn't take advantage of what EITHER visual or symbolic manipulation has to offer. Visual programming efforts have tried to visualize code and operate at the wrong abstraction. Programming is just the act of creating programs. In a visual programming environment, the author / programmer should use visual interactions to "write the program". This means a few things needs to be considered: - the representation - how is a computer program represented? how is state represented? - direct manipulation - imagine using a tool like Photoshop having to compile / build to see your changes between every edit. - input devices - mouse / keyboard works for writing lines of code. Touchscreen is a better input device / interface for visual programming but still lacking (no tactile response). In my opinion, not enough is reinvented when visual programming efforts are tried. I think the entire stack (human input --> program state) needs to be reinvented and reconsidered. Bret Victor has a great section on visual program in his FAQ for one of his talks - http://worrydream.com/DrawingDynamicVisualizationsTalkAddendum/ http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...
  • nzonbi 9y ago
    I have been working on xol, a graphic based programming language. xoL is a graphic based programming language. It represents programming concepts with graphics instead of text. It is product of a long, painstaking design effort, to get an optimal graphical presentation of programs. A good description of it is available in this blog post: http://lignixz.github.io/blog/posts/17/xoL_graphics_based_programming.html http://lignixz.github.io/blog/posts/17/xoL_graphics_based_pr... A partially working prototype from a previous version is available online. The newer current design has fundamental improvements over that previous prototype. The way some program elements work was redesigned. The control method was also redesigned. It is now aimed primarily at touch based controls. Here is the prototype for the previous version: https://github.com/lignixz/xra9 https://github.com/lignixz/xra9 . The prototype is not optimized for performance so excuse that. It is functional to some extent, if you can figure how to use it. You can add and modify programming elements. Would welcome any opinions/feedback. Also interested in finding partners/investors/sponsors that may be interested in this project.
• antender 9y ago
  VP isn't a bad idea by itself, but its implementations usually have the same problems: 1. It's hard to make a scheme in editor without spaghettifying it. (Partially mitigated by blocks incapsulating parts of scheme in themself, some discipline is required) 2. Usually VP makes it hard to work with complex data structures. The only solution is to basically write the same code as text losing all VP in the process. http://hiasm.com/ http://hiasm.com/ : Very usable constructor for small programs, the only problem with it is that website is in russian.
• kilon 9y ago
  Every time a VPL (Visual Programming Language) has gone against a TPL (text programming language) , VPL not only has come out a winner it has massacred its opponent. There are 3 areas that I am aware of that VPLs have appeared a) modular audio synthesis b) 3d graphics c) game programming (a) has been the first with origins back to 1995 , there are like a ton of programming apis for building modular synthesizers , there even programming languages that specialize in this that have existed for decades now like CSOUND and Supercolider but Reaktor and Max/MSP have literally mopolised the market. Reaktor itself has been such a massive success that made Native Instrument as the dominant company on audio software. (b) 3d graphics is no secret that is probably the richest software industry with the generation of the well knows CGI for films and games its a goldmine for developers and has been dominated by VPLs. You are not aware of this most likely because we never refer to them as VPL but rather as procedural material, textures, animation etc. Not using a VPL for todays standards is considered insane even if you try to do it via a very lovable language like Python. Text languages like POV RAY that specialize in 3d graphics have died a miserable death. 3d is where TPLs go to die and are used strictly for generating the software alone and thats about it. (c) computer games there VPLs are something new but Unreal has definitely changed that with Blueprints. Probably the best and most powerful VPL. If you have played any kind of AAA game chances are that the game you played uses Unreal which in turn makes heavy usage of Blueprints and C++ code. The rule of thumb among Unreal developers is "Do it with Blueprint and if you cannot avoid it do it with C++". Unity has smelled the roses and has implement its own VPL as well very similar to Blueprints. So if VPLs are so amazing why we do not see more of them ? They are actually very hard to make. If an implementation of lisp , a basic one, needs a few hundreds lines of code a VPL needs thousands and that imposes a high barrier for language designers. Hence why we have thousands of TPL and only a handful of VPLs. The majority of them are crappy obviously because that is how quality works , you have to have high quantity for high quality. But a high quality VPL will kick high quality TPL ass any day and this is why VPLs are massively more popular than TPLs for the same task. One that does not work as well as it looks and it depends on drag and drop is a crappy VPL . Yes a crappy VPL will suck, not as much as a crappy TPL (see C++ , Javascript etc) but it will suck none the less. you can also read my quora answer here for more details why VPLs dominate so easily and why they will replace TPLs in the not so distant future to a very large extend https://www.quora.com/Why-did-graphical-programming-languages-never-really-%E2%80%9Ctake-off%E2%80%9D https://www.quora.com/Why-did-graphical-programming-language...
• trentmb 9y ago
  What would the United States Code look like as some painting or interpretive dance?
• samblr 9y ago
  (may be) google app-maker (+ more AI) - something to watch out for.
• lisper 9y ago
  > The type of visual programming I'm thinking about here is a WYSIWYG drag and drop interface for building UIs. The main challenge in this particular domain is describing what is supposed to happen to the layout when the size of the window changes, or if there are dependencies among visual elements (e.g. some element only appears when a check box is checked). When laying things out visually you can only ever design one particular instance of a layout. If all your elements are static, this works just fine. But if the layout is in any way dynamic (with window resizing being the most common case) you now have to either describe what you want to have happen when things change, or have the system guess. And there are a lot of options: scaling, cropping, letterboxing, overflowing, "smart" reflow... The possibilities are endless, so describing all of that complexity in general requires a full programming language. This is one the reasons that even CSS can be very frustrating, and people often resort to Javascript to get their UI to do the Right Thing.
  • worldsayshi 9y ago
    Yes there are a lot of options but I don't think that it would be inconceivable to have such options split out as separate components. I want an hide-overflow behavior to this component, then I just wrap it with a hide-overflow component. Doing that drag-and-drop should work. Then again you would need to design such components in a way that makes them intuitive to use, but that's always the case.
• m0ther 9y ago
  Your code, as text, serializes structures that change in all sorts of beautiful ways over time. It's hard to represent that in two dimensions. We can write about it though, in a language the computer can interpret/deserialize. Building a good visual programming environment I'd imagine would require either having a way to visualize and move around in higher dimensions, or dumbing down and limiting what can be done to fit neatly in two dimensions. I like Reaktor Blocks a lot, by native instruments. They took the second tactic, and the result is beautiful (but limited). For what you use it for, it works great.
• robertlagrant 9y ago
  My company sells a product that just does integration between things, and the main way to program it is a visual language that does impedance-matching between XML data structures, loops, conditionals, etc. For that it works really well, and is superfast. But I can't imagine using it for general-purpose programming.
• nikofeyn 9y ago
  i think most people that have an opinion on visual programming have not actually ever used a visual programming language in earnest. i have worked in labview very seriously over the past 4-5 years. at this point, i am essentially an expert in the language. i have done object-oriented programming (OOP), functional programming, and also programmed using an actor framework. all of that is in addition to obviously adopting the dataflow-first paradigm. my projects have not been simple applications. they have been large applications, with many different components and non-trivial user interfaces. it's amazing how such a simple and small base language can be so powerful due to the dataflow nature. my programs are almost always essentially bug free when i am done. this is due to how labview works, which is rather advanced. as i program labview, i work on VIs. these are small blocks of code that perform a certain task. oftentimes, these are purely dataflow functions. in other words, they take in information and pass information out without modifying things via references. since every VI has dynamic type propogation and compilation as you work on it, you get immediate feedback on wehther or not your types match up and whether your VI runs. once your VI successfully compiles (by the way, you never kick off the compile process as it's automatic), you can run it. so i build up systems out of basic dataflow processors, almost all of which i am able to run freely with inputs to see how they interact. out of those that i can't, mainly due to needing a "mock object" to test, it still makes it easy to reason about to due simply having to understand how the data flows through your code. if something's not available, it's pretty easy to trace it back to where it should have come from. all of this also makes labview easy to debug. data is just flowing through your program. just navigate to where you want to view your data and place a probe on a wire to see what's happening at that point in your program. all of this is quite advanced. this type of interactive writing of code, running, and debugging doesn't really exist in other languages. then you have the ability to easily create modern looking user interfaces (my interfaces are almost untraceable back to labview based upon their look) and program desktop, real-time OS, and FPGA applications all with the same language. and i haven't even talked about how labview is concurrent by default. want two while loops running concurrently? just draw two while loops on the screen, and you're done. multithreading is so easy in labview that you don't even have to think about it. it's inherent to the language, and labview takes advantage of multiple cores by default. many of these features are discussed ad nauseum in reference to other languages: type propagation, REPLs, dataflow, concurrent/multithreaded programming, etc. these are things people throw out in praise of a language, and yet labview has all of them. finally, i will mention that labview does struggle with some things, but it is not due to the visual programming environment being inadequate in most cases. most of the time it is because the language is manufactured by a company, which has finite resources in what they can do to the language. there are plenty of problems with labview, but they are all solvable. they just need attention from national instruments and the research community at large. it's just that visual programming is different and necessitates different approaches. people somehow forget that it took them years to understand how to program computers using text. it isn't that text is THE way to program computers, but people certainly seem to think that. i am convinced a hybrid approach is appropriate. i myself am slowly designing a language and environment along these lines.
• deleted 9y ago
  [deleted]
• antaviana 9y ago
  I think that Delphi nailed Visual Programming. It has a mix of speed and convenience that I do not find in other Visual environments. The fact that Pascal compiles so fast also helps with the instant gratification when prototyping an application. The downside is perhaps that this very same instant gratification makes you very prone to add business logic in the UI, and it the application sticks around, you eventually want to refactor the whole thing.
• anotheryou 9y ago
  WYSIWYG fails for two reasons: - Programming errors most of the time break everything. You probably know how bitchy Word can be. Errors will be frequent und finding them when you don't really know what happens under the hood will be very difficult. - WYSIWYG does not abstract very well. The big power of programming however is, that you can build your own tools from a minimal set of building blocks. Visual representation for self-build tools and routines will not be pretty out of the box. --- Those visual languages that do have a big userbase do the following: - no WYSIWYG, just "nodes". The visual parts of the nodes: - - inputs and outputs are often connected with "wires" - - simple control UI like a knob or a button can be shown directly - they allow wrapping a bunch of wired mess in to a box with simple in- and outputs again - some allow to jump back in to code where necessary - in general nice for small art-projects - difficult or at least in-flexible for complex stuff - often a lot more copy+pasting ---
• dalacv 9y ago
  please try Bubble.is
• radva42 9y ago
  I've been working on a project that does exactly what you described for the last few years. IMHO vue.js/react really changed the game here, especially for CRUD apps. For example what I did was to code a server part in golang and use vue.js on the frontend and for the app builder. Using the web-based app builder (also 100% vue) the user can design forms. The forms are stored as serialized JSON in the database and the server renders dynamically vue.js components. It's super fast. And there's a complete freedom to design any form with a 16-column responsive grids and a lot of widgets and styling options. Forms are also nestable (thanks vue!) and completely extendable with custom JS code so it's possible to create a custom widget and then simply import it in other parts of the app. As I said I think the shadow DOM and frameworks like vue really made the difference. I started without using such frameworks and it was not only tedious, but the resulting app wasn't very interactive and felt like a customized Excel spreadsheet attached on top of a PostgreSQL database. Now it's a completely different story - it's easy to build fully reactive apps that feel like a "normal" cloud app and are actually pleasant to use. Of course instead of spending few months designing and building it, it was created in a few hours. So yeah... I think that drag-n-drop builders are definitely coming and will probably eliminate the need to write such apps in coming years.
  • sosodaft 9y ago
    I think if drag and drop builders find an audience it will be in a sweet spot between engineers and clients, maybe used by support engineers or customer success to build and modify applications to client specifications. Technical users will always want more control and in my experience clients are happy to pay for someone else to do the work, even with DND (I've worked at two companies that have built DND form/app builders, neither caught on much with clients).
    • radva42 9y ago
      I absolutely agree. That's why I don't target primarily developers, but the end-users of such apps. Of course knowing Javascript wouldn't hurt, because it opens a lot of more possibilities to further extend the entire app, but my idea was to make it possible even for non-developers to create apps for CRM, invoicing, accounting or inventory management for their needs. So in my case it's not really visual programming, but a drag-n-drop builder, which also has an integrated code editor in case the user needs it: if they know SQL, awesome - write a custom SQL and it is automatically mapped and available in the forms. This sweet spot that you talk about between ease of use & flexibility is definitely key.
• dragandj 9y ago
  Think ancient Egyptian hieroglyphs or Chineese pictograms. They seem like a good idea until you need to describe specific nuances. There is a reason alphabet won.
• lithos 9y ago
  It doesn't. The electrical world has been using contactor diagrams for complex logic for decades, and with the inclusion of more advanced computer components ladder logic (still the same concepts, symbols and logic) https://www.allaboutcircuits.com/worksheets/ac-motor-control-circuits/ https://www.allaboutcircuits.com/worksheets/ac-motor-control... is the link I quickly found. It's typical to see a handful of symbols handle what would take a hundred of lines of code for the level of user interface usability, validation, and core functionality.
  • Qantourisc 9y ago
    Difference here is, we are using humans to fill in the gaps. With visual programming, we either still have to draw the exact wire-diagrams, or exactly define the function of a symbol.
    • lithos 9y ago
      Quite a few PLCs have ladder logic as a programming language as a selling point. For physical systems it is pretty true.
• jstewartmobile 9y ago
  I guess it depends on what one considers to be programming. For certain DSLs (audio, control systems, UIs), it seems to be doing OK. For general-purpose work, I think they will always be less desirable than text. Even after thousands of years, words are still our most powerful tool for recording and sharing new ideas. Alan Kay's mistake is that a lot of his original work was with Papert on educating children. For early learning, having a visual/physical analog adds value. For professional work, when you already have the concepts down, it just gets in the way.
  • ChristianGeek 9y ago
    It's like the difference between a kid's picture book and an adult novel.
    • pavlov 9y ago
      I feel this comment significantly devalues graphic novels. It's a separate art from the novel, but not an inferior one. Pictures have value for adults too.
• the_hn_sux 9y ago
  Maybe I misundestood, but I think this already exists and does not suck. MS Access could do this 20 years ago. Expressing the connections isn't always easy, but this is more of a problem of the underlying programming language, not of the visual elements.
• jensgk 9y ago
  Always bet on text: https://news.ycombinator.com/item?id=8451271 https://news.ycombinator.com/item?id=8451271
  • egfx 9y ago
    True 3 years ago but 3 years from now? Maybe not.
• dirtyaura 9y ago
  Because language and abstraction goes hand in hand. The great leap 50,000 to 100,000 years ago did something to our brains that brought both our use of language and capability of our mind to another level.
• overgard 9y ago
  I think this is a minority perspective, but I generally think coding has a lot more in common with writing than it does with engineering. (I guess Literate Programming would sort of support this idea). Can you imagine trying to write an essay as a flowchart? I think it would just obscure the point, rather than simplify it.
  • indigochill 9y ago
    Structurally, a program is also similar to music. A program, if we view the bytecode, is read linearly by default but may have jumps at certain points forwards or backwards, like a coda in musical notation.
    • jononor 9y ago
      People make amazingly complex music in Digital Audio Workstations. Personally I think there is some inspiration to draw from their use/function into the programming experience.
• santaclaus 9y ago
  It has taken off in certain niches. When I was an undergrad all of the physics labs were hella into LabView for developing instrumentation software. Most shader development tools are essentially visual programming.
• gaius 9y ago
  What you're describing is Developer/2000 or more generally RAD which was all the rage in the mid-90s.
• xaduha 9y ago
  I can tell you where in my opinion visual programming works (or can work if anyone actually bothered), but you probably not gonna like it. First step is to think about IDE assisted programming as a proto visual programming. Second step is to have a real DSL, not just some general purpose programming language with some extra words sprinkled that sort of look like a DSL, but you can easily escape. Visual programming tools that aims to do the job of general purpose programming language is kinda doomed from the start in my opinion. Here's a snag - how many DSL languages do you know that have intelligent IDE support? Designing a good DSL language is kinda hard in the first place. I know of many, but they are called XML languages, deal-breaker for many. XProc can work as an underlying language for such a visual programming tool, with a good XML schema enabled IDE or editor such as OxygenXML you won't even work with XML as most see it, it's not really text anymore. Dropdown menus in a representation of a tree, that's what it becomes. There were at least two attempts to create an actual visual programming tool on the base of XProc, most advanced was this one https://community.emc.com/docs/DOC-4382 https://community.emc.com/docs/DOC-4382
  • jononor 9y ago
    Embedded DSLs (using the general purpose programming language as the host) is the way to go for an integrated workflow/experience. I think the same is the case for visual programming languages/tools.
• richard_shelton 9y ago
  I think the truth is somewhere in the middle. Look at complex CAD systems and editors. They focused on the visual side and still provide some kind of command line for scripting the things. Even in pure visual programming systems like PD you can type algebraic expressions in textual form. And in text-based systems you may have lots of 2d tables (Smalltalk), graphs of modules, semantic colors (colorForth) etc. Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.
  • djedr 9y ago
    > I think the truth is somewhere in the middle. Totally agree. I think the major reason visual programming sucks is exactly because some things which are simple to do using text-based programming become way harder when all you can do is drag graphs around. On the other hand, some things are easier and more intuitive when represented and manipulated visually using graphs or trees. I think that a visual programming environment which would be an extension of a text-based programming environment, in that you could do everything that you can do in IDEs everybody is already used to PLUS the cool stuff you can do with visual programming, would have high chances of not sucking. > Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive. I made a hybrid visual and text programming language and prototype development environment for it as a project for my master's thesis [0]. The main idea was very similar to what you are imagining. Textual code on the left side and visual representation on the right [1]. You can edit one and have the changes reflected dynamically in the other. Actually my idea was even more general and could be extended to parallel-editing multiple representation of the same syntax tree. I would love have the time to explore this stuff some more. [0] http://djedr.github.io/masters_thesis.pdf http://djedr.github.io/masters_thesis.pdf [1] http://djedr.github.io/gfx/masters-thesis/ide-prototype.png http://djedr.github.io/gfx/masters-thesis/ide-prototype.png
  • hakanito 9y ago
    For web apps, this is possible using Chrome and the style editor. Very effective way of live editing visual styles. Functionality is a different beast though
• VladimirGolovin 9y ago
  Filter Forge founder here, now working on a turing-complete functional visual programming language inspired mostly by Haskell: https://imgur.com/a/HkSgJ https://imgur.com/a/HkSgJ Here's what I currently think on visual programming languages: 1. I see no place for imperative and non-pure functional languages in visual programming. 2. Pure functional languages can absolutely be implemented with visual syntax. This is just another form of representing a program. Instead of taking text as an input, the compiler / interpreter takes the node-based representation, which may or may not directly correspond to the AST. Here's an example of the same toy program in Haskell, Racket and our visual language: https://i.imgur.com/dsNJYyx.png https://i.imgur.com/dsNJYyx.png 3. Visual languages shine on higher levels of abstraction. They work great in Filter Forge and similar systems, e.g. material / shader editors in 3D packages or game engines. However, I've never seen a visual language that remains usable and understandable on a lower level of abstraction. 4. Our civilization has settled on text as the lowest common denominator format of information exchange. We have accumulated an enormous amount of tools, infrastructure and software ecosystems built around text. Git, Slack, WWW, Copy / Paste, Ctrl/CMD + F, diff tools, IDEs, regexps, Unix pipes etc etc etc. A visual language will have to reinvent all these wheels. 5. Visual programs have no equivalent of line numbers for addressability. You can unambiguously refer to a location in a text program with just two numbers, line & column, but how do you do that in a visual program? "Uh, it's the red rectangular block with the blue output, to the left of the square green one. The connection you need is the second from the top."? 6. I see no way of quickly commenting out / deactivating a section of a visual program. 7. When you write a text program, you are compelled to give descriptive names to things like functions and variables. A visual program doesn't force you to do that. For example, in our language you connect function outputs to function inputs with graphical arrows, and named binds aren't necessary. In Haskell, however, if you don't want your program to look as a huge chain of function applications, you bind results of certain function to named 'variables', and the names tend to be human-friendly (well, at least in monomorphic functions). To sum up, visual languages lack built-in annotatability and don't compel programmers to annotate programs. Annotation feels extraneous, tacked-on. 8. I/O is hard. Sure, it can be done the Haskell way, but without some kind of monadic sugar (somehow adapted to a visual language) it would be absolutely unpalatable. Also, this would only work on visual languages that are capable of expressing a monad.
• Changu 9y ago
  I think the reason is that text is already a highly optimized visual way to represent information. It started with cave paintings and evolved to what it is now. "Please go to the supermarket and get two bottles of beer. If you see Joe, tell him we are having a party in my house at 6 tomorrow." It took me a few seconds to write that. Imagine I had to paint it.
  • GuiA 9y ago
    请你到超市去买两瓶酒。如果你见Joe，告诉他我们明天六点钟参加派对在我的家。 Here, that was quite fast to paint. Would have been even faster with a proper brush instead of a keyboard :p
    • ghurtado 9y ago
      If that was a painting then surely I would have some remote idea of what it represents. As it is, I (and many others) don't.
      • BenjiWiebe 9y ago
        Unless it was modern art, of course.
      • threatofrain 9y ago
        Maybe he's making a joke about how Chinese characters evolved from more pictorial-like elements, and are in a sense abstractions over pictures.
  • humanrebar 9y ago
    Even harder with pictures, searching and, sharing, and refactoring: "Joe has been way too busy yesterday. What did you ask him to do in the last week?" "Yeah, that's too much. Just ask Jessica to do the emails going out next week."
  • david927 9y ago
    So do you use text files for storage or a database? Is your company's accounting system in Word or Oracle? Are programs text, like a novel, or is it data? And to find out, would you query Moby Dick? Not really -- at least that's not how it's meant to be consumed. You read it from beginning to end. Would you read your program from beginning to end or would you query it? You query it, exclusively. I submit that programs are data, not text, and visual programming then becomes like data visualization. Text is holding us back.
• nickbauman 9y ago
  The old "Gold Standard" for WYSIWYG programming has been Apple's Interface Builder. But every iOS dev I know has moved entirely away from IB in favor of programatic construction of the UI (in Swift or Objective-C text). Why? Because they want to have automated tests over everything they can. The simpler way to say this is: "Complex ideas can only really precisely be expressed in text. To the degree you can express them visually is to the degree that there are expressed as complex text underneath."
  • jononor 9y ago
    Can't one test a layout built with IB? Load it in a unit test for instance?
• edejong 9y ago
  Things that are difficult in visual languages: - Humans are centered around linear communication. Spoken language is essentially linear, with good use of a stack of concepts. This story-telling mode maps better on a linear, textual representation than on a graphical representation. When provided with a graph, it is difficult to find the start and end. Humans think in graphs, but communicate linearly. - Graphs are rather hard to manipulate. You invariably need a mouse, which is a rather slow instrument. Using keyboard combo's is certainly possible, but is difficult to make intuitive. - A textual representation can be left in a syntactical incoherent position while editing. For example, I can have non-matching braces. This proves very helpful in quickly editing code. Visual programming paradigms generally require a coherent structure, in order to keep them editable. - UI builders are extremely valuable, but this is technically not visual programming. UI builders have problems as well. Complex UIs are often parameterised (the fields themselves are variable). By offering a visual context and a textual context, the coding experience can become incoherent and more difficult to learn. - Programming is very context dependant. A programmer focusses on a specific part, mentally forming a high-dimensional representation of the algorithm at hand and the larger context. Using a visual representation possibly competes with the mental map. Also, it forces upon the reader a scoping.
• dukoid 9y ago
  1. Try flowgrid.org 2. File an issue describing why it sucks 3. I'll fix it O:) Ok, realistically, I guess I agree with the top comment
• throwaway_c 9y ago
  VB6 and (especially) Delphi continue to have many fans. Sadly, there is little effort seemingly being expended in simplifying programming for normal people, so a lot of modern visual environments just haven't taken off, which further reduces incentives for investment in the field, and leads to them being (correctly) perceived as crippled and unsound. Also high-mean IQ dev outfits are likely to produce tools for people like themselves. "Cognitive empathy" is not going to be a strong point for the framework creators at Google or Facebook. Microsoft seems to have quietly abandoned Lightswitch, which was their last high-profile attempt in this space. Finally market forces mean that working developers have no incentive to adopt simpler technologies, so there is no pressure on vendors to simplify things either.
• jerf 9y ago
  Programming languages (and a lot of other things) have essential and accidental complexity: https://en.wikipedia.org/wiki/No_Silver_Bullet?wprov=sfla1 https://en.wikipedia.org/wiki/No_Silver_Bullet?wprov=sfla1 Progress in programming is in removing the accidental complexity to get to the essential. In the vast majority of domains, visual programming injects huge amounts of accidental complexity utterly irrelevant to the domain. So it isn't really surprising that despite it's superficially appealing elevator pitch and uniquely pretty demos, it doesn't appeal over the long term. The domains where it works are those where the complexity is limited, or where the usually-accidental complexity is actually fundamental... for instance, in circuit layout the usually-accidental issues involved with layout actually correspond to something. Visual programming is firmly established in some nights, and I expect it to stay in them indefinitely.
• calebh 9y ago
  Nobody here has mentioned language workbench tools, the best of which is probably Jetbrains MPS: https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/ These language workbench tools make it easy to switch between graphical and textual representations. Also you get intelligent IDE support and typechecking for free. The primary alternatives to MPS are Xtext and Microsoft's language workbench (formerly known as Intentional Software, Microsoft just bought them).
• ux-app 9y ago
  > Why does visual programming suck? It doesn't? Shameless plug, I build a visual programming tool for UI design (https://www.ux-app.com/static/learn-actions-and-events.html https://www.ux-app.com/static/learn-actions-and-events.html). It's great for a huge subset of people for whom coding is tangential to their job. Product managers, designers etc. It's not ideal for a programmer because it's not as dense as the textual representation and once you've developed that muscle memory, typing your code is a lot quicker, but increasingly, there are a lot more people coding now who are not career programmers. For these people visual programming is great since it's less intimidating and reduces the possibility of syntax errors.
• cageface 9y ago
  It doesn't suck if your code involves complex flows of relatively simple data. Programs like Reaktor and Max MSP have been hugely successful for this kind of coding in the music world. If your data structures are more complex and require more convoluted logic, which is more often the case than not, then the benefits of visual programming diminish and the downsides are much more apparent.
  • unclesaamm 9y ago
    GNU Radio is another example of this succeeding with manipulating flows of data. But I agree that's an intrinsically different problem than what OP is describing, which is essentially a WYSIWYG editor.
  • flor1s 9y ago
    I've seen a research lab in Tokyo use Max MSP for controlling the motion of a humanoid robot (using pneumatic actuators). I believe that whenever there is some flow involved it is easier to model it graphically than textually.
• mvindahl 9y ago
  I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. The UI looked a bit like UML, and it worked nicely for anything resembling "Hello world" complexity (anything more complex literally became hairy to look at). Since then I've twice found myself on projects where we had to work with visual programming tools (caused by skilled salesmen and inept managers). In both cases the only sensible action was to pound the "eject" button until we were catapulted away from the monster. All in all I consider myself vaccinated at this point. As for my reply to the question of the OP, I'm not sure that it differs much from everyone else. The main reason that it will never catch on, IMHO, is that the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. Also, every serious text based programming languages offers plenty of ways to hide complexity away, allowing you to focus your thinking at the desired level of abstraction. Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things. That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well.
  • nzonbi 9y ago
    My horse carriage is very useful. The horse just feeds itself, if you leave him in a grass field. It rarely gets sick and last many years. The wheels are easily replaced from the store. The other day I saw a crazy guy with a mechanical contraption that, according to the guy, moved by burning wood! The guy was demoing it at the town. He filled it with wood, and then had to start the fire. The crazy machine got so hot that nobody could get near it. The thing barely moved a few meters and then Kabooooom!! it exploded in a black cloud. What sane person may ever believe that one of these contraptions could be useful? Am I right? Are you right? we don't know. Research is the only way to know.
• adpoe 9y ago
  Personally, I think that written language is a more natural way to describe and reason about complex systems and symbols. It's the same difference between writing mathematical proofs as systems of equations vs. proof by drawing a diagram, or making a visualization. Proofs can be written using both methods, but if you have a strong command of the written/symbolic vocabulary, it is faster and more succinct. Put another way: I can describe the landscape of a lush, green Tuscan Countryside--with rolling hills, morning dew, and and crisp feeling of the first rays of sun cutting through the mist--in just a few lines. You get a picture in your head, and it is likely very similar to what was in mine. Imagine now, that we can't use words. We have to draw pictures. It will take much longer to get the same point across. Language--for certain purposes--is more efficient, and more information dense. That's my hypothesis/feeling.
• dgudkov 9y ago
  I believe general purpose visual programming hasn't become widely popular because currently it's not really needed for general programming. General programming used to be pretty low-level (e.g. i++) and linear (because it's single-threaded in vast majority of cases). Things slowly change though. Now popular functional programming tends to be more high-level and the shift to multi-core CPUs even on mobile devices encourages more and more developers write multi-threaded code. At the same time there are very successful niche cases for visual programming with Excel as the most prominent. Yes, there are no data flows in Excel (although it can display dependencies with arrows), but you typically can easily identify visual blocks (chains) of calculations on a sheet. I've designed a visual programming tool for data transformation (http://easymorph.com http://easymorph.com) which can be viewed as a visual programming language[1] because typically the task of data transformation is high-level and non-linear, and visual programming works very well in this case. [1] http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-functional.html http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-fun...
  • jononor 9y ago
    The common pattern of applying the same macro to each of the rows/columns can be seen as a SIMD/vectorized operation with the affected cells as inputs and outputs.
• empath75 9y ago
  We call visual programming that doesn't suck a 'graphical user interface'. Look at a daw like Logic or Ableton for example -- it's essentially visual programming.
• amatheus 9y ago
  Visual programming is used in Maya or Houdini for example (I think Houdini is more oriented towards it). While these are 3D software, I don't think there's anything 3D specific about how it works. I've seen a video of a guy showing how to create assets for game and building something that works pretty much as a function out of interconnected nodes (I can't remember the exact webinar I watched but found this other https://vimeo.com/202120820 https://vimeo.com/202120820). Now they don't call it programming but as I see it, that's programming and the basic idea could be made to work in other contexts.
• iEchoic 9y ago
  I think it's because some visual mediums are better at representing certain forms of information than others, and visual programming tools attempt to represent a form of information (programming logic) using a visual medium (images) that isn't optimal for that form of information. Analogies can be made for things like calendars (which are the preferred visual medium for visualizing schedules), sheet music (which is the preferred visual medium for visualizing music - though guitar tabs present an interesting alternative to think about), and movie scripts (for which text is the preferred medium). In the same way that a movie script is best represented by text, my belief is that text is superior to images for representing programming logic, and images are superior to text for representing UI elements. I think most people at least feel the same about representing UI elements, which is why visual programming tools are appealing. This leads to the conclusion that the best tools for building UIs would represent programming logic in text, and represent UI elements using images. In my experience, this is true; tools like Unity and Flash are, in my opinion, better for UI development than HTML/CSS (text). This also leads to the conclusion that unless someone invents a better way of representing programming logic than using text - like the equivalent of inventing a calendar to display a schedule, if we had never invented a calendar before - visual-only programming is inherently limited. Tools that keep UI in visual-land and programming logic in text-land - and don't try to mix the two - work great.
• pishpash 9y ago
  For event-driven programming like what you describe, Visual Basic worked fine. Too bad that kind of very efficient UI building got thrown out irrationally with the hate for Visual Basic the language.
  • meredydd 9y ago
    Obligatory plug: We're bringing it back! Check out https://anvil.works https://anvil.works - it's like VB, only for this century (the web) and using a sensible language (Python, both client and server). We just took it to PyCon, and the reaction was pretty gratifying :)
• sweetPete 9y ago
  The type of visual programming you're suggesting seems to exist in an extreme form as the apps we use to read and write data, like Facebook, Trello, etc. On the other end of the spectrum we have the very technical savvy that want more direct control of what's going on. There's a lot of middle ground that's been covered, from both ends of the stack. I don't think the idea of visualizing things to be more material is flawed, but surely you could overdo it or apply the wrong model at the wrong level of abstraction. All of our programming is visual. We rely on a set of visual units of some manageable size (an alphabet of characters), and then we compose them sequentially into strings (visual units of a more general alphabet) Stringing units together makes sense based on the way we experience a limited bandwidth of signal over time. While listening, signal is presented one unit of the sequence at a time. When reading, we are presented with a whole page of characters at a time. The surrounding area is displayed, and we can move the focus around at will. This leads to the development of the visualization models/techniques that we progress from simple features like spaces between words; parentheses/curly braces to group words; indentation of blocks to group/subordinate them, forming trees. The idea of the unit/object/thing, composed of unit/object/things is thematic. Files are units of text that are read/written one at a time. Eventually you stop directly typing, and you enter a different level of abstraction, where the units are displayed and manipulated with a different set of controls. I think this is the point where the flowchart (directed graph) model fits in with the text focused model. In Sublime, I like having the directory outline view and the zoomed-out scrollbar view with whatever single page of text I'm viewing. I think it'd be cool if these three were integrated, so that I open and close the files in a flowchart in the plane, where edges/arrows represent organization and dependencies. I'd like to import a module by dragging an arrow from one node to another
• nitrogen 9y ago
  Your example is still too closely tied to traditional textual methods of programming: "query", "statement", "string interpolation", etc. are not likely terms to be found in whatever visual programming paradigm eventually becomes successful.
• smilesnd 9y ago
  Unreal has a VPL and it is a pain to use. A simple piece of code takes up so much desktop real estate that you either have to slowly move around to see it all or have to add more monitors to your setup to see it all. You think spaghetti code is bad imagine actually having a visual representation of it you have to work with. Organization doesn't exist you can go left, up, right, or down. If you ever try to enforce coding standards think about adding x and y coordinations and other location standards. Finally I could only imagine the black magic that goes along with such a thing. Visual studio black magic is already horrible to deal with one little hiccup and you are lucky if all you have to do is create a new project and migrate your files/folders over to it.
  • Stratoscope 9y ago
    For the curious, here is an example of Unreal's Blueprint code: https://forums.unrealengine.com/attachment.php?attachmentid=116071&d=1478103220 https://forums.unrealengine.com/attachment.php?attachmentid=...
• analog31 9y ago
  I wonder how many people have physical issues with computer screens. My own anecdote is that I get severe eyestrain headaches and neck / wrist fatigue, when I have to do fine manipulation on a computer screen. I spent a few months using LabVIEW, more than 20 years ago, and it was physically debilitating. I also have a hard time doing CAD. When I'm typing code, I'm not really focused on the screen unless I need to be. Sometimes I close my eyes and type, or look away from the screen. Another thought about text based languages is that they make it much easier to create and explore new languages, because you don't need to program a full blown graphical editor every time, make it work on every platform, etc. Especially for languages that are supported by volunteers, maintaining graphical tools might not be the best allocation of effort.
• deleted 9y ago
  [deleted]
• nacc 9y ago
  I think it really depends on the task. We are just hijacking the brain machinery to do jobs it is not evolved to deal with. If we can find some highly evolved / optimized brain function which reflects the structure of the new job, the brain can process it much more efficiently. Text might be good for programming because, most of the programming are sequential, text is sequential, and text processing is highly optimized in the brain because language. But in fact, we also use a bit of visual programming (indentation, paragraphs) in text to reflect part of the program structure that are not sequential. If the program is completely non-sequential, visual tools which reflects the structure of the program are going to be much better than text. For example, if you are designing a electronic circuit, you draw a circuit diagram. Describing a electronic circuit purely in text is not going to be very helpful.
• adamb_ 9y ago
  At the end of the day, programming is symbol manulation, and nothing beats representing symbols like text.
  • DonaldFisk 9y ago
    No mainstream programming language even supports symbols as a data type. They process numbers and strings of characters. Symbol manipulation is done well only by Lisp and its variants.
    • lispm 9y ago
      Javascript (with ECMAScript 6) supports symbols as a datatype.
• rubyfan 9y ago
  I don't know much about how other people think but I'm fairly certain that I favor auditory mode. When I write code I generally am in auditory mode and then expressing logic becomes fairly easy with text. Further, I believe abstractions like classes and objects, etc. tend to favor text/auditory expression. Visual programming to me becomes very scattered and fragmented. Bits and pieces of logic seem to end up all over the place and become hard to keep a cohesive functionality together.
• groundshop 9y ago
  SQL Server Integration Services (SSIS) does a good job of this I think. SSIS is made for manipulating data flows. The flow of data happens to be very well represented in many cases by visual network flow diagrams. Most of the common patterns of data flow are implemented as drag and drop widgets. That said, as necessary, you can do pretty much anything in that environment as code if you want. The best thing about the language, though, is that /if/ you go down the path of coding something out instead of using a common pattern, it forces you to ask "Why am I doing something out of the norm here?" Sometimes you have a valid reason. Sometimes you don't and that question course corrects you back into a maintainable architecture. It's a very niche language (even mostly vendor locked down), but I think it's a great example of a visual programming environment that's mostly great to work in.
• vendiddy 9y ago
  One size does not fit all. UI creation is best handled by a WYSIWYG editor, animations are nice to visualize on a timeline, and math formulas are clearest when written as is. Picking the wrong model creates a mess. Try to express a sorting algorithm as a flowchart. It would be too difficult to follow. Yet a business process is great to model as a flowchart. A picture is only sometimes worth a thousand words. Take a look at the papers published from VPRI, the research org founded by Alan Kay. They have built languages for graphics, parsing, stream processing--each optimized for its particular domain. They could have used a general purpose language but it would have resulted in much more code than necessary. So the question everyone should be asking is: why hasn't a multi-paradigm programming environment taken off?
  • flukus 9y ago
    > UI creation best handled by a WYSIWYG editor, a business process is best modeled as a flowchart I disagree with those two. UI creation has generally evolved away from WYSIWYG, composing a UI with code is a much better approach and is now nearly the universal way of doing it. For the business process, the flow chart only works as an extremely high level overview, the implementation is always done in something like code.
    • vendiddy 9y ago
      > composing a UI with code is a much better approach and is now nearly the universal way of doing it Why is it a better approach? Universal does not always mean better. Javascript was built in 10 days and it's now universal. > the flow chart only works as an extremely high level overview, the implementation is always done in something like code I agree here. The core point I am trying to make is that one size doesn't fit all and we have to mix and match approaches based on the problem.
      • flukus 9y ago
        > Why is it a better approach? Universal does not always mean better. Javascript was built in 10 days and it's now universal. Easier to diff, easier to copy paste, easier to upgrade and easier to extend. In the 90's we had both approaches and it was the code based (Qt, GTK) and declarative (html, xaml) systems that (mostly) won. If I'm working with win32 or winforms then I love the UI designer, but that's because they come with an awful API, for anything else I'll take the code approach.
• lloydfischer 9y ago
  Way back in a previous life I made a living building a visual programming tool and language to specify simulations. After many years of work it became clear that visual programming works very well in industries that already have a well established visual paradigm. We had great success with simulating hydraulic systems by letting folks specify them with standard piping and instrumentation diagrams. The cooling system simulation for the space station simulator ended up being built that way with our system, as were many simulations of nuclear power plant cooling systems. However, after you do P&i diagrams and electronic schematics you very quickly run out of well established visual paradigms. Uml is just not useful in the way that a piping diagram is. As to text, a colleague once described the best feature of a text specification of code was "visual rhyme". You know, when you can look at a block of code and feel how it ebbs and flows. That's from the old days, I don't know if functional code rhymes like Fortean did.
• thenanyu 9y ago
  My pet theory: Code is N-dimensional - every set of braces, every nested function call, increases the execution by a dimension and humans are really only good at visualizing in 2 or 3 dimensions. Specific domains that are constrained to 2-3 dimensions are suitable for visual programming, but it's hard to generalize.
• wruza 9y ago
  What really annoys me in text programming is that I have to write constructs again and again, referring to manual for method names constantly. Completions may be smart typewise, but IDEs never assume what I am writing. Let's take a function: static string defaultFamily = "Sans"; bool foo(string s, Alignment a, int height) { Par_ Okay, it began. What can be done with all the available values? Seems that I'm going to create a paragraph and fill it with some arguments. One of autocompletion suggestions: bool foo(string s, Alignment a, int height) { Font f(defaultFamily, height); if (!f.isValid()) return false; Paragraph p; p.setAlignment(a); p.setText(s); p.setFont(f); <#rest#>_ return true; } How is it obvious? Because Paragraph told the completion system that it needs at least font and text values set. Height goes to font, other arguments go to paragraph. Names are selected from the style around. Since we return a boolean and few objects can be invalid after initialization, it assumes that it is a status. p is local, so there is something to be done with it, and another <?> block is created. Even better, you could just throw items together and get the result: // this->points is double[20]; { frame inset 0.5 red stroke; add points black stroke; --- { Rect r = this.frame(); r.inset(0.5, 0.5); Painter p; p.setColor(Color::red()); p.addPath(rect); p.stroke(); p.clearPath(); for (point in points) { p.addPoint(point); } p.setColor(Color::black()); p.stroke(); But the completion style that we have everywhere just sucks: int foo(string s, Alignment a, int height) { ParadoxDatabaseProvider_ ParadoxDatabase... ... Paragraph ParamsManager I can't point to good visual programming tool, but our "powerful" text IDEs are simply prehistorik typewriters.
  • Too 9y ago
    > Because Paragraph told the completion system that it needs at least font and text values set. If the class needs at least all those arguments it shouldn't have an empty constructor. It should have those as arguments to the constructor and then most good ide today would be able to help you at least a bit better. Have you tried intellij? Boolean return values without context is also an antipattern, how am I supposed to know whether true means success or fail or something else? There is no way any AI would be able to infer that either without annoyingly amount of false positives.
• badsectoracula 9y ago
  One thing that nobody seems to notice is that big thing in front of you with the tons of buttons: the keyboard. The main input device we use to enter stuff in our computers are based on typewriters, so everything more advanced than clicking widgets with the mouse revolves around typing stuff. Most visual languages feel like you are fighting with their code editors because the editors are not following the typewriter model that the main input device of our computers use. Perhaps this will change in the future with other input devices, touch devices like tables could provide for a different environment - currently programming with a tablet feels slugggish but this is because everything about programming revolves around typing. Touch is different. But it needs to be designed from the ground up for the interface you work with. Whatever that is, i don't think text is the only way to go. I believe our keyboards have shaped the way we think about programming - and interacting with computers in general - and if we are to explore other ways to program, we need to also explore other ways to communicate with the computer.
• tapirl 9y ago
  IfLoop is a visual programming language which is like text programming. It gets both the benefits of the two styles. It is very good for new programmers to learn programming. http://www.tapirgames.com/blog/ifloop-web-demo http://www.tapirgames.com/blog/ifloop-web-demo
• wruza 9y ago
  >Then you interact with their API: this table pulls in data from this SQL statement; this button executes this HTTP query; this dropdown publishes this value, which this SQL statement uses via string interpolation. These "widgets" publish their data, which can be used by other widgets (w1.value), and inside SQL queries. The tables can pull in data from SQL queries. You can use string interpolation inside SQL queries, so dropdowns can influence the query being run. So selecting a drop down value would cause the query to change, which would automatically propagate changes to the table. This is very similar to Xcode Cocoa/CoreData bindings, but these are too restricted to create anything nontrivial. IME I always had to fallback to delegate and data source methods in source code.
• paulryanrogers 9y ago
  Klik & Play had a curious mix of questionnaire and spread sheet programming when making games. I pushed it as far as a 14 year old could. I think the density of information and need to control abstractions are where visual tools break down.
• whateveracct 9y ago
  Why is pictionary a fun game to play? Because drawing pictures to express ideas is harder than using a language :)
• mschaef 9y ago
  For me at least, graphical programming tended to crank code style issues up to 11. If you think linear text code formatting is bad, laying out a flow graph on the screen is worse. If you think naming a function is bad, try drawing an icon to represent that function. (Or each function in a library of ten or twenty related functions... ) Graphical programming also walks away from a huge body of work dedicated to managing, searching, and manipulating text. As good as the graphical tools can be, there's nothing like all the work that's gone into text editors, diff tools, query languages, etc. These are all things that are central parts of my programming workflow, and they are all missing or considerably weaker in a graphical language. (This is not to mention the fact that graphical programming gives up two hands and ten fingers as input devices in favor of one hand pointing and clicking with a mouse.) I think as appealing as the idea is, whatever benefits there are don't outweigh the considerable costs.
• devcriollo 9y ago
  "Text is the most socially useful communication technology. It works well in 1:1, 1:N, and M:N modes. It can be indexed and searched efficiently, even by hand. It can be translated. It can be produced and consumed at variable speeds. It is asynchronous. It can be compared, diffed, clustered, corrected, summarized and filtered algorithmically. It permits multiparty editing. It permits branching conversations, lurking, annotation, quoting, reviewing, summarizing, structured responses, exegesis, even fan fic. The breadth, scale and depth of ways people use text is unmatched by anything. There is no equivalent in any other communication technology for the social, communicative, cognitive and reflective complexity of a library full of books or an internet full of postings. Nothing else comes close." http://graydon2.dreamwidth.org/193447.html http://graydon2.dreamwidth.org/193447.html
  • kbuchanan 9y ago
    I agree with this statement, wholeheartedly. I do, however, think programming languages could benefit from more visual augmentation. A program, over time, takes on more complexity than a programmer can hold in his mind, and eventually, the program's design will elude him. A disconnect appears between the text he types in the moment and the original design of the program. The sum total of the program's code no longer resembles the problems at hand. Here, I think, visual tools are underutilized. Not as code crafting tools, but as tools for reflection. Reflection on dependency trees, deviation in style, orphaned code, the ability to visualize how and where data might flow in unexpected ways, etc. Webpack's stats.json comes to mind for dependency tracing. Statically typed languages obviously have a leg up here.
    • nichochar 9y ago
      This is, I think, the idea behind IDEs
      • karmelapple 9y ago
        Yet which IDEs aren't simply really nice text editors with some refactoring help built in? Making these visualizations central to the IDE would be exciting.
• simplify 9y ago
  Check out node-red[1], a visual language for creating node apps. It's a good demonstration of the potential of visual-based languages (but it's also far from that potential). [1] https://www.youtube.com/watch?v=f5o4tIz2Zzc https://www.youtube.com/watch?v=f5o4tIz2Zzc
• awinter-py 9y ago
  tooling tends to suck, input ends up being slower once you know how to do it. (Argument to be made that visual is faster on a tablet with no keyboard. Okay). You still have to type to name things. Density of stuff on the screen is lower. Not sure about readability (you can find readability advantages for any format if you ask the right person). I would bet math expressions with many terms are clearer in a visual format like tex. Visual elides the connection between functions and files/modules, potentially making it hard to scale projects.
• gwbas1c 9y ago
  This was an active area of study in the 80s, with many journal publications. The goal was to make programming intuitive. Then one day someone published an article explaining that we need words to represent variables, doing it visually runs out of abstractions too quickly to do anything useful. There were no journal publications after. It's been about 14 years since I last looked at these publications and my memory is foggy. The point is that any useful program is too complicated to represent with pictures.
  • jononor 9y ago
    In dataflow programming, and some variations of functional programming, variables are pretty rare. But I'd be interested in reading the study you refer, do you know how to find it?
    • DonaldFisk 9y ago
      In dataflow programming, variables are unnecessary.
• kevin_thibedeau 9y ago
  It is unproductive. You waste time managing a 2D representation for little benefit. It's hard to do meaningful diffs and merging needed for revision control. You can program FPGAs in 2D with schematic entry. It is a huge time sink for anything non-trivial which is why few bother with it these days.
  • DonaldFisk 9y ago
    > It's hard to do meaningful diffs and merging needed for revision control. That's because existing revision control tools are specifically designed for textual languages, therefore unsuited to graphical ones. There's no reason why graphical equivalents can't be implemented.
• TheLilHipster 9y ago
  https://developers.google.com/appmaker/ https://developers.google.com/appmaker/
• andreapaiola 9y ago
  Have you ever try Drupal Views?
• phantom_package 9y ago
  I really enjoy Unreal's Blueprints. I program in a text-based language for work, so it's fun for me to go home and be able to hack on a game without having to spend more hours staring at text on a screen. A big difference that I've noticed is that in a visual scripting language, the "nodes" in the graph can change their shape/color/layout/etc based on what type of node they are. I love this. With blueprints, if I'm putting together a material and I put in a color node, a color picker shows up. If I put in a TextureSample node, a little picture of the texture shows up. In a text-based language, every variable is just a string of characters - if you want to be able to tell at a glance what type of object a variable contains, you need to adopt some kind of a naming convention (or use an IDE that highlights them). Debugging in unreal is also really cool. The "code paths" light up when activated, so it's really easy to see exactly which branches of code are and aren't being run - and that's without actually using a debugger. Side note - it would be awesome if the lines of text in my IDE lit up as they were run. Also, debugging games is just incredibly fun and sometimes leads to new mechanics. I initially thought that organization would be a problem, but it turns out that you can make functions just like any other programming language, and encapsulate blueprints inside of them. There are also some things that I don't like about Blueprints. Typecasting usually involves an extra node which feels verbose. If/thens are handled with a "Branch" node, which again feels verbose.
• doggydogs94 9y ago
  I avoid Text as much as possible. I find that Text is good for command line stuff. For building a good looking app, a visual tool mandatory. Of course, if I want a quick and dirty clunking looking thing, Text is ok.
• tyingq 9y ago
  Google's app maker talks a good game. Haven't been able to try it yet. Supposedly, you are able to script pretty freely on both the front and back end for situations where the canned functionality isn't suitable. https://developers.google.com/appmaker/ https://developers.google.com/appmaker/
• killin_dan 9y ago
  Honestly, I think most languages have shitty syntaxes (syntaxi?) and that the issue is not about visual programming. The other problem is that everybody who has a big idea for visual programming has the same, actually shitty, idea. Drag-n-drop blocks that represent logic. UML is not a thing anymore because it's useless and wastes time. Visual programming is great for describing high-level logic, but not low-level semantics. Try and describe your last trip to the grocery store with just emojis. Maybe you might get creative and come up with a paper for your list, some fruits and stuff like that, but how could you guarantee that the user on the other end of your description gets the exact same idea? You can't. With words, I can write my comment how I want, and I'm more or less guaranteed that people will read it the way that I intended them to, because it wouldn't make any sense any other way.
• sriku 9y ago
  Is there a VPL that's been developed without using any text?
• jmts 9y ago
  I did some work with webMethods Flow in a previous job. I hated it. Aside from the fact that it was slow from a point-and-click point of view, the interface was generally slow, and navigation and search were generally tiresome. To my memory it was not possible to have related flows side-by-side for reference, and much of it was abstracted to a high enough level simply due to language features that it was difficult to identify patterns and idioms within a set of logic at a glance. This also meant that any opportunities for refactoring or code reuse were few not only because it was difficult to do, but also because they were difficult to see. Much of this can probably be improved in the IDE, and it is possible that there were issues simply because we may have been abusing it (there other platforms/languages that were being used beyond their original design). What little I've seen of LabVIEW at my current job suggests that it has a more usable interface, however having written DLLs to be used by LabVIEW, it still appears to be quite restrictive at a language design level which I expect would still limit its usefulness (I hear regular talk of the use of singletons, users appear to be required to translate a C API to LabVIEW manually, useful C language features like structs and function pointers don't appear to have any support, the ability to maintain a reference to a context pointer gives rise to groaning developers). https://en.wikipedia.org/wiki/WebMethods_Flow https://en.wikipedia.org/wiki/WebMethods_Flow
• reaanb 9y ago
  Text doesn't interfere with a programmer's imagination or ability to visualize the system. Visual programming suppresses imagination and imposes a very limited and impoverished visualization.
  • jononor 9y ago
    On the other hand it can be really tricky to reconstruct an understanding of a non-trivial system which someone else made from the textual code. With visual diagrams overall architecture can be conveyed quickly and relatively concisely.
• dsego 9y ago
  You are describing asp.net forms in visual studio circa 10 years ago. It was not a bad experience to use the UI tools and "code-behind", but then MVC and Ajax came to the scene, and it fell behind I guess.
• simonh 9y ago
  A picture might be worth a thousand words, but if I give you a thousand word essay there's no way you'll find any number of pictures that fully express it. Text is hugely expressive and can be precise and unambiguous in ways visual information struggles with.
• tiago_simoes 9y ago
  Here's an article summarizing the major problems (real and perceived) of visual languages https://hackernoon.com/visual-programming-is-unbelievable-heres-why-we-don-t-believe-in-it-ad52ba24c98 https://hackernoon.com/visual-programming-is-unbelievable-he...
• zmoreira 9y ago
  It doesn't. Try Outsystems: https://www.outsystems.com/learn/ https://www.outsystems.com/learn/
• dennisgorelik 9y ago
  Visual languages never found a good solution to most of software development tasks. For example: 1) How do I view diff between old and new version? 2) How do I search for an element in my visual code? 3) How do I email example of visual code to my colleague? 4) How do I message an example of visual code? 5) How do I blog about visual code?
• nottorp 9y ago
  Funny enough, all examples of successful visual tools in this conversation are domain specific (yes, even UI builders are domain specific). The ones mentioned in the 'it's unusable' category are the ones trying to do everything. That should answer the OPs question better than any specific answer...
• flohofwoe 9y ago
  Programming through typing text has already become 'visual programming', just from an unexpected direction: syntax highlighting, compile error checking while you type, code completion, fuzzy searching, argument type popups and so on. The only thing that's missing is better debugging integration (essentially show how the program state changes while you type).
  • skibz 9y ago
    Your comment is definitely an interesting take on the question. I would argue, however, that integrated debugging in the way you describe (along with the various programming text editor features) is what constitutes a live programming environment.
• mseebach 9y ago
  Programming is inherently difficult. We can do a lot in tooling and increasingly higher level languages to help make a lot of the details a lot easier, but a the core, it remains abstract symbolic manipulation. It seems to me (and I have by no means done an extensive survey of the field, so YMMV) that efforts in visual programming suffers from mis-diagnosing that the difficult part of programming is the act of writing the code (indeed, the empty editor is intimidating and code in any language looks impenetrable to outsiders), rather than understanding what code to write in the first place.
• afpx 9y ago
  But, isn't text just abstract signs and symbols? Why can't we, programmers, make new or better symbols? Why can't the language be augmented to incorporate concepts of computing? I never desired visual programming until recently. I never had the need for it. Plus, I always found the existing visual languages and tools to be clunky. But, lately, I often find myself with just my tablet and stylist. And, during these times, I want to 'sketch' out programs. I have some ideas on how this would work in practice. There would have to be detection of gestures, and instant feedback that provides visualization of the changes.
• unabst 9y ago
  Imagine trying to do math without numbers. That's why visual mathematics sucks. Numbers are needed to count. We do it with our fingers when we're little, and we're limited to 10. Then we take off our socks to get to 20, but that's it. Imagine trying to reason without words. That's why visual programming sucks. Words are the smallest units of abstraction that we can reason with. So when a visual programming language provides us with glyphs, we are already limited in our vocabulary and in what we can reason with. It becomes excruciating. What we need is not a visual programming language, but more tools to visualize the programs that we have. Ultimately, all visuals need to fall back to literal code a parser can reason with, so there is no escaping code. In fact, there are already layers going down from the higher level languages that we use now. A practical graphical language would be one built on a higher level that adds a layer to the stack, and one which we can use or skip based on our problem at hand. Also it is because graphics too easily limit abstractions that most graphical languages are best being domain specific. A WYSIWYG editor is for the web, the form designer in Delphi was for application layouts, and Scratch is for games.
• jokoon 9y ago
  Look at this https://scratch.mit.edu/ https://scratch.mit.edu/ The idea is similar... I'm really curious if one could compile this directly into some form of AST...
• dev4people 9y ago
  I think that Visual Programming could be more suitable for building modern applications that may need to make web services to monitor physical devices (for example) or to gather and analyze values coming from sensors,etc... That's exactly what has driven the design or our new Visual Programming language : the need of being able to rapidly and easily build applications that connect and use technologies that were not made for working together (https://www.youtube.com/watch?v=uRWIlDXeLdk https://www.youtube.com/watch?v=uRWIlDXeLdk and https://www.youtube.com/watch?v=JccLWZ6nPlY https://www.youtube.com/watch?v=JccLWZ6nPlY). (Full disclosure, CEO of Hackeet)