Ask HN: Why isn’t visual programming a bigger thing?

185 点作者 remolacha将近 5 年前

Visual programming seems to unlock a ton of value. Difficult concepts can more easily be grokked in a visual form. Programming becomes more approachable to first-timers. Since text is difficult to manipulate without a physical keyboard, visual programming opens the doors to doing development on mobile devices. And yet it only seems to be mainstream in education (i.e. Scratch). Why?

108 条评论

barrkel将近 5 年前

Symbols are pictures too; and they have denser meaning than diagrammatic pictures.It's not that difficult concepts are easier in visual form. It's that concepts are verbosely described in visual form. Verbosity puts a ceiling on abstraction and makes things explicit, which is why things seem simple for people to whom everything is new (experts, on the other hand, find it harder to see the wood for the collection of tall leafy deciduous plants).When you need abstraction, you need to compress your representation. You need to replace something big with something small. You replace a big diagram with a reference. It has a name.Gradually you reinvent symbolic representation in your visual domain.Visual programming excels in domains that don't need that level of abstraction, that can live with the complexity ceiling. The biggest win is when the output is visual, when you can get WYSIWYG synergies to shorten the conceptual distance between the visual program and the execution.Visual programming is at its worst when you need to programmatically maniplate the construction of programs. What's the use of building all your database tables in a GUI when you need to construct tables programmatically - you can't script your GUI to do that, you need to learn a new paradigm, whether it's SQL DDL or some more structured construction. So now you've doubled what you need to know, and things aren't so simple.

评论 #23257311 未加载

评论 #23257480 未加载

评论 #23266634 未加载

URSpider94将近 5 年前

I have led the eviction of LabView from three different engineering organizations now. It’s seductive how easy you can get started with building a bench top system. Then it grows from there and pretty soon people are doing linear algebra and trying to automate tests by writing data into a database - screen after screen of multiply nested windows. It’s not pretty, it’s not fast (you need a much more powerful computer to run LabView than a comparable Visual C++ or Matlab program). It’s also very hard to document it well, really hard for a third party to bootstrap into your code base, doesn’t play well with common version management tools, requires a full license for every machine you run it on, and if your developer leaves, it can be hell to hire someone to maintain it - LabView consultants cost a mint and are hard to find.We had a bake-off once, once you have the instrument control DLL’s and link them into Matlab, you can code up a new experiment in Matlab in about 10% of the time it takes to do the same thing in LabView. And from there, you can do pretty much anything that needs doing in terms of data work-up. I’m sure these days you could do the same in Python, which has become the new science and engineering language.

评论 #23256924 未加载

评论 #23256316 未加载

评论 #23256156 未加载

评论 #23259443 未加载

评论 #23259140 未加载

评论 #23256179 未加载

prewett将近 5 年前

Having worked with LabVIEW a fair amount, the problems I have with visual programming are:1) takes up a lot of space2) each subroutine (sub-VI) has a window (in the case of LabVIEW, two windows), so you rapidly get windows spewed all over your screen. Maybe they've improved that?3) debugging is a pain. LabVIEW's trace is lovely if you have a simple mathematical function or something, but the animation is slow and it's not easy to check why the value at iteration 1582 is incorrect. Nor can you print anything out, so you end up putting an debugging array output on the front panel and scrolling through it.4) debugging more than about three levels deep is painful: it's slow and you're constantly moving between windows as you step through, and there's no good way to figure out why the 20th value in the leaf node's array is wrong on the 15th iteration, and you still can't print anything, but you can't use an output array, either, because it's a sub-VI and it's going to take forever to step through 15 calls through the hierarchy.5) It gets challenging to think of good icons for each subroutine6) If you have any desire for aesthetics, you'll be spending lots of time moving wires around.7) Heavy math is a pain visually (so you use the math node that has it's own mini-language, and then you're back to text)

评论 #23260036 未加载

评论 #23256277 未加载

评论 #23256744 未加载

DangerousYams将近 5 年前

It's pretty main stream in the CG industry. Houdini is a great example of a very interesting take on visual programming in a non-destructive procedural workflow. Visual programming is a staple at Pixar and features heavily in all their internal tools for shading, animation, set dressing etc. At Pixar they push it to its limits, expressing all manners of development patterns through these tools to artists who don't know any software development at all. I often think of a modified version of your question which is "Why isn't visual programming a bigger thing for trained programmers?" What needs to improve for that to happen? It's already a big thing for visual artists in the CG industry.

评论 #23258332 未加载

评论 #23256885 未加载

评论 #23256595 未加载

评论 #23255758 未加载

评论 #23255903 未加载

评论 #23255886 未加载

mimixco将近 5 年前

This comes up in comp sci every so often since the 80s when it first gained traction. I think the short answer is that boxes and wires actually become harder to manage as the software increases in complexity. The "visual is simpler" idea only seems to hold up if the product itself is simple (there are exceptions.)To my mind, this is analogous to textual writing itself vs drawing where text is an excellent way to represent dense, concise information.

评论 #23255455 未加载

评论 #23256691 未加载

评论 #23253647 未加载

评论 #23254361 未加载

评论 #23269594 未加载

评论 #23255317 未加载

fossuser将近 5 年前

You’d probably like Bret Victor’s inventing on principle talk: <a href="https://m.youtube.com/watch?v=PUv66718DII" rel="nofollow">https://m.youtube.com/watch?v=PUv66718DII</a>He demonstrates some good examples.I’m not quite sure it’s what you mean by visual, but it seems obviously valuable and tools that enabled some of what he shows would be really useful.I’m not sure why we don’t have these things - I think Alan Kay would say it’s because we stopped doing real research to improve what our tools can be. We’re just relying on old paradigms (I just watched this earlier today: <a href="https://www.youtube.com/watch?v=NdSD07U5uBs" rel="nofollow">https://www.youtube.com/watch?v=NdSD07U5uBs</a>)

评论 #23266996 未加载

评论 #23256928 未加载

DarrisMackelroy将近 5 年前

I discovered TouchDesigner [1] a few months back- it’s an incredibly powerful visual programming tool used in the entertainment industry. It’s been around well for over a decade and is stable enough to be used for live shows. Deadmau5 uses it to control parts of his Cube rig [2]. I’ve seen a few art installations based around it as well [3].There are some really amazing tutorials and examples here: <a href="https://youtu.be/wubew8E4rZg" rel="nofollow">https://youtu.be/wubew8E4rZg</a>[1] <a href="https://derivative.ca" rel="nofollow">https://derivative.ca</a>[2] <a href="https://derivative.ca/community-post/made-love-touchdesigner-v99-cusersdeadmau5" rel="nofollow">https://derivative.ca/community-post/made-love-touchdesigner...</a>[3] <a href="https://derivative.ca/community-post/making-go-robots-interactive-motion-tracked-dance-installation" rel="nofollow">https://derivative.ca/community-post/making-go-robots-intera...</a>

评论 #23255384 未加载

giantDinosaur将近 5 年前

I'm curious as to which difficult concepts become easy to understand when presented visually. To me, the difficulty of programming has never been in its textual representation. Just as in mathematics, the real challenges have always been related to conceptual understanding. Is there a good example of visual programming making difficult concepts easy?

评论 #23255564 未加载

评论 #23256788 未加载

评论 #23257729 未加载

评论 #23260491 未加载

评论 #23256688 未加载

woggy将近 5 年前

I rarely see Grasshopper [1] mentioned in these threads. This is a very successful visual programming tool used by designers and engineers, primarily for generating geometry.Where I work (structural engineering firm) some of the engineers do use it for general purpose programming. I see the appeal of it, but keeping the layout tidy and all the clicking is just too much effort. However for generating geometry it's quite a useful tool.[1] <a href="https://www.rhino3d.com/6/new/grasshopper" rel="nofollow">https://www.rhino3d.com/6/new/grasshopper</a>

c2the3rd将近 5 年前

Written text IS a visual medium. It works because there is a finite alphabet of characters that can be combined into millions of words. Any other "visual" language needs a similar structure of primitives to be unambiguously interpreted.You say visual programming seems to unlock a ton of value. What can you do with a visual language that is much easier than text? Difficult concepts might be easier to understand once there is visual representation, but that does not imply creating the visual representation is easier. And why should pictures be more approachable than text? People might understand pictures before they can read, but we still teach everyone to read.

评论 #23255396 未加载

评论 #23255621 未加载

评论 #23255745 未加载

tluyben2将近 5 年前

I am working (with a grant) on 2 different concepts of visual programming; one is kind of more traditional wires/boxes dataflow type but with some novel twists and the other is something completely new. I have built many of these in the past (some of them ran production for years before getting phased out in favour of a 'normal' PL) and it never felt right, but I keep trying. Normally I started top-down; first visual tooling then, as an afterthought, the storage of the language (xml for instance, jikes). Now I started with the language in textual form (not meant to program in directly but readable) and that works much better; so there is a language, runtime, debugger and introspection tooling all done and now we are putting 2 different visual frontends on top to see if it works. So far the results have been good; our sponsor is looking to launch something as a product and it's quite cool work.

评论 #23257180 未加载

评论 #23255725 未加载

asfarley将近 5 年前

In practice, most visual tools aren’t compatible or easily usable with things like Git for diffing. This gets tough for large projects.Labview does have a visual-diff tool, but when I was using labview regularly on a complex project, no-one used the diff system. They just checked out the entire file and compared it visually to another version.Another thing: you can’t ctrl-f for control-flow structures. You end up mousing around for everything.Another problem, all major graphical languages I’ve used are proprietary (labview, simulink, Losant workflow system).

评论 #23269191 未加载

glopes将近 5 年前

I've been developing a visual reactive programming language, Bonsai (<a href="https://bonsai-rx.org/" rel="nofollow">https://bonsai-rx.org/</a>) for the past 8 years and it's proven successful in neuroscience research. It is an algebra for reactive streams and addresses some of the issues raised in this thread about GPVPLs:a) it's amenable to version-control;b) you can type/edit a program with the keyboard without the need for drag-drop;c) the auto-layout approach avoids readability issues with too much "artistic freedom" for freestyle diagramming languages like LabView;d) because its mostly a pure algebraic language w/ type inference there is little complicated syntax to juggle;e) the IDE is actually faster even though Bonsai is compiled because there is no text parsing involved, so you are editing the abstract syntax tree directlyIt definitely has its fair share of scalability problems, but most of them seem to be issues with the IDE, rather than the approach to the language itself. I've never probed the programming community about it, so would be curious to hear any feedback about how bad it is.

TheOtherHobbes将近 5 年前

Difficult concepts can't be represented in visual form. There's a hard limit to the amount of complexity you can represent visually. On the far side of that line everything starts to look like spaghetti.But... this can be improved with good tooling and clear abstraction layers. Some of the problems with visual systems are caused by poor navigation and representation systems. Making/breaking links and handling large systems in small windows makes for a painful level of overhead.This also applies to text - jumping between files isn't fun - but visual representations are less dense than text, so you have to do more level and file hopping.If someone invented a more tactile way of making/breaking links and you could develop systems on very large screens (or their VR equivalent) so you could see far more of the system at once, hybrid systems - with a visual representation of the architecture, and small-view text editing of details - might well be more productive than anything we have today.

评论 #23269235 未加载

wrnr将近 5 年前

To represent a program as a graph you need a hyper-graph. That is a graph where every edge is also a node, for example:<pre><code> (1)--[2]-->(3) (2)--[3]-->(4) </code></pre> There is no good way to draw this visually without losing the ability to be able to draw all possible programs. The grammar of both natural and programming languages use various strategies to get around this, and they are actually very efficient at it (from an information theoretic point-of-view).Thats not to say one can't improve on the current culture of writing programs in what is basically ASCII text, but visual programming is just not powerful enough to describe arbitrary computations.

评论 #23255697 未加载

评论 #23255703 未加载

techdragon将近 5 年前

Just dropping in DRAKON to the mix. <a href="https://en.wikipedia.org/wiki/DRAKON" rel="nofollow">https://en.wikipedia.org/wiki/DRAKON</a>Its actively designed to both prevent several typical problems of visual programming:First, the overlapping wire mess getting out of hand. It doesn't let you overlap wires, if your program gets this complicated it forces you to break it down into a smaller unit. It takes some adjustment, but you get benefits from it.Second, the "cant use it for general purpose stuff" problem is solved by the fact DRAKON can output to multiple different programming languages, meaning you can use it to build libraries and other components where you want without forcing you to use it for everything.

PopeDotNinja将近 5 年前

When I first got into programming, I asked myself the same thing. The low hanging fruit task it creating something like a CRUD app. Trivial drag & drop CRUD forms are pretty achievable.Let's say you whip up something cool using visual programming, and then you have a business requirement that requires something you can't easily squeeze into your CRUD app: maybe a database join, a query that doesn't cleanly fit into your access patterns, or you just wanna make a certain thing faster.Then you design a scripting console, and now you have something that lets you build custom solutions. Well, at that point you're basically implementing non-visual programming. And at a certain point you reach the limits of what you can script in a hacky way. or you become more comfortable with the console than they UI, and you just chuck the visual programming altogether.As I'm writing this, I'm thinking that I actually do visual programming, except I'm doing IN MY MIND. Who needs a body brain interface when the goal of using your hands is to get it into your brain?, but it's already in my brain?! Well, it'd be nice to get some stuff out of my brain cuz cognitive load. And as much as I'd like to develop tech that makes it easier to get stuff out of my head, I'm mired down in trying to get the latest feature from the product team to work at all :)

评论 #23258484 未加载

vectorboost将近 5 年前

I will just add some practical experience, we work with WebMethods flow languages (used for business integration). It looks cool because you can make "code" which is more readable for non IT people. The problem is that some task which would require one or two lines of codes needs several graphical "nodes" and just too many clicks. The more complex the diagram gets the easier is to make mistake and eventually some things has to be implemented in Perl, Python or Java because the flow languages also has it's limitations. I would say it is great for simple or medium complex solutions but very complex solutions tend to be messy and developers tend to avoid them. They say it is easier to iterate and skim through complex text code, where you can search and use some IDE features, than to expand and click through the whole graphical diagram. The graphical notation also does not show all the information so you cannot get it by scaning the code, instead you need to manually click and open the nodes to get e.g. the connectiong interface name. The graphical notation needs to abstract from some information otherwise it would be messy and hard to read.

asdfman123将近 5 年前

Try making a complicated program in a visual programming language and you'll see why pretty quickly.My company used Azure ML Studio, which is a great program for making quick ML predictions. But making any kind of reasonably complicated data processing pipeline takes a lot of effort. I switched to writing code to process and run my predictions and my life became much simpler.Language is extremely expressive and you can pack a lot of meaning into a small space.

toomim将近 5 年前

Let me refer you to a 2018 post called "Visual Programming — Why It's a Bad Idea:<a href="https://news.ycombinator.com/item?id=18495094" rel="nofollow">https://news.ycombinator.com/item?id=18495094</a>

Mandatum将近 5 年前

As soon as anything gets beyond basics, and you require a "power user" to either comprehend, fix or add features - suddenly visual programming becomes a fucking pain in the arse.And you're required to go into code / the "source" representation or deep "configuration" of the visual elements, which just takes 10x longer than writing code in the first place, suddenly the last mile takes months to get right.

gentleman11将近 5 年前

Unreal engine has a visual scripting system called blueprints. It’s very strange to follow the logic, the work is mouse heavy, code review and merging is hard, and it feels very convoluted compared to actual programming. However, the visual scripting for materials/shaders, particles in unity, and ai with behaviour trees is quite nice.Visual scripting is growing but it’s better for some things than others

评论 #23254222 未加载

zyl1n将近 5 年前

At work, I am required to use SPSS modeler which has visual programming model, and I mainly dislike it for the reason of not having a way to easily diff and find out what has changed.That aside, I think most of us actually code in visual programming style, but all the "visuals" are constructed in our head on the fly as we read the code text. So how good you are at coding maybe a function of how well you can represent these structures and how long you can maintain them in your head. Maybe an external tool that does it for us produces a representation doesn't mesh well with the internal representation for programmers experienced in text based programming.

tester34将近 5 年前

Show HN:<a href="https://www.luna-lang.org/" rel="nofollow">https://www.luna-lang.org/</a>> Luna is a data processing and visualization environment built on a principle that people need an immediate connection to what they are building. It provides an ever-growing library of highly tailored, domain specific components and an extensible framework for building new ones.

评论 #23256893 未加载

jasonhansel将近 5 年前

Saying "Visual programming will replace text-based programming" is like saying "Flowcharts will replace novels." People tend to prefer text over diagrams for anything longer than a page, partly because text follows the structure of natural language.Another issue: it's hard to pretty print visual programs or to put them in any sort of canonical form. This makes it harder to read them--there's no way to enforce a consistent style. It also makes various processing tasks (e.g. diffing, merging) much harder.

cammil将近 5 年前

I think in some ways spreadsheets are visual programming tools. You have data, functions and layout / presentation, all working together in one space.I think this is one of the draws of spreadsheets for simple "programs" and non-programmers. And of course, spreadsheets are ubiquitous.

aasasd将近 5 年前

Aside from everything else, visual programming as it's usually implemented is inherently slower than typing text when the latter is not ‘hunt-and-peck’. Because, after some experience with the keyboard, your brain knows exactly how to jerk a finger to get a particular character and can do that very fast (touch typing particularly excels at this since the normal positions of the fingers are fixed—and it's aptly called ‘blind typing’ in some languages). Meanwhile, to lay stuff out on the screen you need to 1) find with your eyes where to grab a block and 1b) where to put it; 2) move the mouse to grab the block and 2b) to drop it, and sometimes also do that with connectors too. Both of these kinds of operations—visual and manual—are way slower than mechanical jerking of the limbs, especially due to them being prone to error. Even worse if you have to drag-and-drop instead of just clicking. All this fiddling requires you to pay close attention to things on the screen, while typing mostly allows the visual system to coast along or tune out altogether. Multiply this by hundreds of words a day, and you'll see that visual programming is in large part an exercise in mouse-brandishing amid visual load, in the vein of FPSes. And usually you have to regularly move the hands to the keyboard anyway, to name your blocks, variables and whatnot.On phones, the difference shrinks since typing relies on just two thumbs with no fixed position and no physical keys—while onscreen manipulation gets more immediate compared to a mouse. However, phones suffer from short supply of screen area where you pick and place the blocks. In my experience, it would still make sense to choose blocks with typing (by filtering in real-time from the entire list), and to minimize the work of placement—like in Scratch or Tasker.Visual programming might have distinct value if it allowed to manipulate higher-level concepts compared to text-based coding. However, it turns out that the current building blocks of code work pretty well in providing both conciseness and flexibility, so visual blocks tend to just clone them. Again, the situation is better is you can ride on some APIs specific to your problem domain—like movement commands in Scratch or phone automation in Tasker and ‘Automate’. Similarly, laying out higher-level concepts like in UML or database diagrams has its own benefit by making the structure and connections more prominent.

评论 #23259548 未加载

gapo将近 5 年前

You are completely ignoring the vast swathe of 'engineering' programming market that is covered by Simulink, LabVIEW etc.

评论 #23253561 未加载

gen3将近 5 年前

In college I had to use labVIEW; a visual language normally used for automation. I found it significantly harder to work with compared to programming the robot in C. Part of it has to do with my familiarity of the language / learning what the shapes meant, but another part of it was trying to juggle the programs layout. Eventually, everything became a big mess and was hard to maintain.Using labVIEW over C did have some benefits. It seemed like streamlined concurrency is a major advantage.

评论 #23253807 未加载

评论 #23254084 未加载

评论 #23254157 未加载

danielscrubs将近 5 年前

It was a running joke that every year in our school another student would start its master thesis journey in " visual programming for the masses, but that works! ".Can you start with using an WYSIWYG HTML editor and do a really good webpage to see the benefits and drawbacks?

评论 #23255672 未加载

评论 #23255693 未加载

onedognight将近 5 年前

Is there a visual programming language that is self hosting? i.e. one where the entire system is written in its own visual language including the compiler and any runtime VM?

评论 #23255671 未加载

evilotto将近 5 年前

I think at least part of it is image. "real" programmers dismiss visual languages, especially ones aimed at kids like Scratch or Snap as toys, not the kind of thing Real Programmers use. (insert references to all the Real Programmer humor)Aside from that, there is the issue of tooling (source control, etc), editing large blocks, etc. which the visual languages I've used are not great at.But it should be recognized that some things are better visually and some things are better textually. Typing "a = b + c" is way simpler than dragging a bunch of blocks around to describe the same thing. But visual tools are superior for understanding relationships - a connects to b, which connects to c makes a lot more sense when you see it as "[a] -> [b] -> [c]", and an ascii diagram like that quickly becomes unwieldy while graphical boxes still work.I find an interesting comparison between drawing diagrams with a diagramming tool (e.g., Lucidchart) vs with a textual description language (PlantUML). I find the textual language far easier to use to quickly produce diagrams, but LucidChart is superior for tweaking the exact dimensions and alignments of things.All of which is to say, both approaches have cases where they work better, and others not so much.

评论 #23269326 未加载

foreigner将近 5 年前

I'd love to see an editor for textual programming languages that can display the code visually. For example a tool which can show the code within a single JavaScript function as a flow chart. I don't see why that shouldn't be possible but I've never found one.Note I'm not talking about class diagrams, I want to see a flow chart of the actual imperative code (for loops, if/then, etc...) of an existing popular text-based programming language.

评论 #23258606 未加载

评论 #23256311 未加载

jchw将近 5 年前

Visual programming, imo, is not popular for general purpose programming largely because there doesn’t presently exist, and it’s unclear if there ever will exist, general purpose visual programming tools that work well and provide a notable benefit over text-based programming.When you add some constraints in, like for example, the limitations of a spreadsheet, visual programming can work exceedingly well. It works great for these domain specific usages. But honestly, a text document of textual statements is a pretty good way to represent a general purpose programming language made up of procedural statements. You could make a UI like Scratch for other programming languages, but:- the interface would be cluttered and likely not nearly as efficient as just typing- other than virtually eliminating syntax errors its unclear what you are accomplishing - its not easier to break down problems or think procedurally.- You could probably get similar benefits with a hybrid approach, like an editor that is aware of the language AST and works in tokens.So my view is that visual programming is perfectly mainstream and just has not been demonstrated to have substantial benefits for typical general purpose programming languages.

watt将近 5 年前

I worked with a team working with visual programming tool once. The tool was connecting programming blocks with arrows. The complexity of finished program was such, that it looked laid out like a motherboard, full of arrows (traces) - and an idea that you could follow the control flow from that was laughable.It does not end well. The results are not pretty. Stick to text representation of any control flows.

perl4ever将近 5 年前

Well, so you're using the term "visual" as though it were a commonly understood term, but implicitly excluding all of Microsoft's products with Visual in the name?I've been trying to implement something with Power Automate, and presumably that's "mainstream", but it strikes me as falling into the classic pattern of appealing to buyers rather than users. I feel 10-100 times less productive than with, say, VBA, for no advantage.One thing that is particularly frustrating to me is that it's so slow and buggy I am afraid of losing my work at any moment. You can't save your work unless it passes preliminary validation, but sometimes reopening it makes it invalid by removing quotes or whatever. Copying something out and pasting it back often fails to validate too, as the transformations are not inverses like they should be. Sometimes it just gets corrupted entirely. I'm not aware of any way to manage versions, or undo beyond a few trivial actions.But the more fundamental reason I hate this is because it seems not to be designed to let you take a chunk of logic and use it in a modular way. At least this style of "visual programming" seems to apply the disadvantages of physically building things out of blocks, where it's entirely unnecessary. You've got some chain of actions A->B->C, but the stuff inside those actions is on a different level; you can't take that chunk of stuff and use it as a tool to do more sophisticated things. As far as I can tell. I keep thinking "it can't be as simplistic as it seems" and thinking I'm about to find a way to create general functions.See: <a href="https://flow.microsoft.com/en-us/" rel="nofollow">https://flow.microsoft.com/en-us/</a>

评论 #23254549 未加载

sea-shore将近 5 年前

My assumption on what I have heard so far is that.. Ive been amazed for a good while now by the on-line-system from Engelbart, Sketchpad by Sutherland, Smalltalk from Xerox PARC, Nelsons Xanadu and later Bret Victors demos. They where/are visually and philosophically strong, and seemingly inspired countless weaker systems that in turn somehow got picked up as the "industry standard".Compromises where made, quick-fixes on quick-fixes made text interfaces just usable enough, sunk costs grew and habits formed. The visual programming I see in game-engines now are carrying those habits with it, because to build a language of nodes you first have to learn the ways of ASCII code.And from what I understand, hardware is optimised for what ever software is popular enough to sell, so even if the software changed, the hardware would take longer. It takes an awesome goal to justify starting over on a truly visual interaction path when there is a system that almost, kinda works. And what-ifs are not in budget.

simonsarris将近 5 年前

It's been a dream concept for a very, very long time. My company (long before I joined) started in 1995 making a visual programming language. We keep the site up for posterity: <a href="http://www.sanscript.net/index.htm" rel="nofollow">http://www.sanscript.net/index.htm</a>Lots of examples on Progopedia: <a href="http://progopedia.com/version/sanscript-2.2/" rel="nofollow">http://progopedia.com/version/sanscript-2.2/</a>It turned out, people weren't really interested. However people were interested in the diagramming library created to make the language, so by virtue of already having thought really hard about what goes into good diagramming tools, my company started selling that. Girst as C++, then Java, then .NET, now as a JavaScript and TypeScript library called GoJS: <a href="https://gojs.net" rel="nofollow">https://gojs.net</a> (Go = Graphical Object).

thefz将近 5 年前

Because complex programs ramp up in difficulty of reading and consumption (i.e "looking at") way faster than text does.

评论 #23255998 未加载

truckerbill将近 5 年前

What I would like to see is a hybrid approach - text input on one side, and a visual graph on the other. I'd like to be able to live-edit a graph by typing, and see how the data flows between objects. Likewise I can rewire the graph and have the references in the code update.It's one of those ideas I have no time to implement sadly, at least for now.

评论 #23256771 未加载

macklemoreshair将近 5 年前

Control flow is hard to describe visually. Think about how often we write conditions and loops.That said - working with data is an area that lends itself well to visual programming. Data pipelines don’t have branching control flow and So you’ll see some really successful companies in this space.Alteryx has a $8b market cap. Excel is visual programming as well.

评论 #23254252 未加载

评论 #23253682 未加载

analog31将近 5 年前

I used LabVIEW for a while. I noticed a couple things. First, it is actually physically laborious to create and edit code. I got really severe eyestrain headaches and wrist fatigue from it. Also, programs (including one written by a certified LabView consultant) bigger than one screen become very difficult to read and maintain. While LabVIEW programs can be refactored like any other language, the physical labor involved discourages it from actually happening.I think another issue is that it's costly to create a visual language, discouraging experimentation with new languages. With a text based language, all of the editing tools are already there -- a text editor -- on any decent computer. You can focus on refining your language, and getting it out there for others to try.

mikhailfranco将近 5 年前

Here is an early example of visual programming for scientific visualization from 1989:<a href="http://vis.cs.brown.edu/docs/pdf/Upson-1989-AVS.pdf" rel="nofollow">http://vis.cs.brown.edu/docs/pdf/Upson-1989-AVS.pdf</a>The idea spawned many imitators (VTK, IBM DX, SGI Iris Explorer). The product was spun out of Stellar shortly afterwards, and the company is still in existence:<a href="https://www.avs.com/avs-express/" rel="nofollow">https://www.avs.com/avs-express/</a>

thelazydogsback将近 5 年前

This is slightly tangential but I think is related in some way to the broader question of the effectiveness of VP. I can say from my experience with my son and trying to teach other kids programming, that visual programming does not seem to promote actual understanding, especially concepts composition, re-use, etc. Kids can write animation sequences or even simple games that "work", but then have absolutely no idea how to generalize -- every visual program is a one-off. As soon as you start teaching them Python (or whatever) then they start to understand what's going on. This is why I don't like the "gamification" of learning in general.Another way to look at it is the 7 +/- 2 rule of short-term memory attention -- when you look at something and try to "grok" it (a gestalt experience) you really need a limited amount of information in your visual field. To do this you need to move to higher and higher levels of abstraction, which is a linguistic operation - assigning meaning to symbols. Even in visual programming, you end up with a box that has a text field that holds the name of the exact operation - so you may as well cut out the middleman and stick with the linguistic abstractions.Now, if a program is "embarrassingly visual" -- dataflow operations in signal processing, etc., the visual DSLs do seem appropriate.

lmilcin将近 5 年前

I think it is because programming is inherently about working with abstractions and visual programming is typically removing abstraction and making details of your program visible before you.Part of learning to program is to learn work with abstractions especially if you have never been really exposed to something else similar (mathematics, physics, engineering, etc.) Things go out of sight but you still need to train your brain to manage these things.This is a bit like playing chess. Good experienced player will be able to plan long in advance because his brain has been trained to spot and ignore irrelevant moves efficiently. If you imagine training that would let the player learn recognize good moves but not learn how to efficiently search solution space, you would be training brute force computer that would not be very good player.I think visual programming is a different thing from regular programming. I think compromises like Logo <a href="https://en.wikipedia.org/wiki/Logo_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Logo_(programming_language)</a> are much better teaching tools. You still program a language with syntax but the syntax is very simplified and the results (but not the program) are given in a graphical form that lets you relatively easily understand and reason about your program.

badrabbit将近 5 年前

It's not efficient for large scale things. It's like communicating with memes, you can't exactly write a news article with just memes.It's useful to allow more "citizen devs" (regular folk with little exposure) to come up with prototype high level proof of concept apps,including UX design. It is a big deal in the corporate arenas I've had exposure too,but I think widespread adoption is still years away.You will always need non-visual languages to do things in a featureful and scalable way.

评论 #23255324 未加载

RNeff将近 5 年前

I have not seen any solution for tracking changes, differences,displaying versions, etc. I.E. git for pictures. Some visual languages can turn an area into a 'subroutine', I have not seen any solution to build libraries of reusable 'subroutines'. I used to draw flowcharts on size D (22.0 x 34.0 in) and size E (34.0 x 44.0 in) sheets of paper. I wish I had a monitor of either of those sizes.Visual programming works very well for data flow problems.

评论 #23255278 未加载

aSockPuppeteer将近 5 年前

It is pretty big in engineering. Labview or VEE. TLDR: the more complex the program becomes, the worse it is to use.I used it to easily connect to a piece of lab equipment, reset it, set whatever settings I want, run a test, and then log the output to a file. I could setup a test then walk away and return to data. Doing the tests manually would take many months.Both have labels as remarks/comments and you can easily put in a switch statement to test new code or use highlighting to see exactly where the program is running albeit slowly.One of the fun things to do was circle a repetitive task then turn it into a function. A large program requires a large screen to see it all. Widescreens are terrible for it.After basic settings and availability in libraries, it is better to move to a text language. Visual programming is a quick and dirty solution.

评论 #23253786 未加载

k00b将近 5 年前

I haven't used a visual programming language, but it's likely a lot harder to build a good visual programming language than a nonvisual one at a given level of expressiveness.I suspect visual programming is more common than we realize though. I had an acquaintance at Workday who claimed a lot of work was done there in a visual programming language.Also, arguably website/app builders are a visual programming "language" and they are extremely common.

runxel将近 5 年前

Visual programming is really hard to debug. Just as people tend to give the advice to limit a procedure/method to one page, because you start to lose control. You just can keep up with so much. Where does this line goes in? You just don't know. Collaboration is nearly impossible. Opening projects from others will be much worse than looking at pure code.Also it is too verbose. The 'functions' take away a lot of screen estate (this is most obvious for mathematical stuff). If you start on just a bit more than something you could have achieved in 50 LoC, it tends to get really messy.VP lacks referencing as well. At least most of those envs I know. Declared a variable? Too bad, you have to connect this node to everywhere you need it. Sigh.Reusing of components is possible, and for some envs it is implemented, but mostly just per file, not in general, e.g. you can make a custom component inside one project, and if you edit it, all instances get updated, but you can't save that as a standalone component you can XREF in other files/projects, which makes it hard to make a custom library of functions.But it depends on the industry. As others already mentioned, the more an industry is led by visuals in the first place, the more common it is to actually utilize Visual Programming (or rather Scripting), also it's quite useful in real time contexts – which is the place where the strengths are. The CG industry is one of those, but also architecture and design in general (think of McNeel's Rhinoceros with Grasshopper, THE most used visual scripting environment used as of today, especially in a professional setting).Conclusion: VP has its merits and is used extensively, just maybe not the places you expected/hoped for.

tylerlarson将近 5 年前

A visual programming languages are often high level and can only take the user so far. If you were to make a programming editor mode that visually shows how programs are structured that understood standard programming languages it would be easier to understand the structure of these programs but the actual edits would likely still be done in the native language. Higher level edits might be very powerful but how often would you be able to do this safely? From a documentation point of view I agree with your assessment, the ability to understand how things work is easier visually at higher levels but we also have other tools to do this like UML. There are also editors like <a href="http://staruml.io/" rel="nofollow">http://staruml.io/</a> that enable you to convert UML into code but I find this only works when projects are starting when you are trying to find the right high level abstractions. After this is set it is usually best to keep the high level structures that you have in place.

iamwil将近 5 年前

You might be interested in <a href="https://futureofcoding.org/" rel="nofollow">https://futureofcoding.org/</a>

todd8将近 5 年前

Around 1977-1978 I tutored a friend that was a fellow engineer. I could not get him to write structured programs. He insisted on creating large flowcharts with lines going in all directions. He had been introduced to this "visual" form of programming, and he kept going back to it each time he tried to construct a program.His programs ended up with state distributed all over the place and an impossible to keep track of control flow.Around the same time, I was intrigued by articles promising easy visual construction of programs; it seemed to be in vogue then. I took me several years to realize that the nice examples in journal articles were just that, nice examples. Visual programming is appealing, like flowcharts to my friend, but they suffer from lack of good support for building abstractions and an inefficient method of building visual programs and keeping track of changes.

mbar84将近 5 年前

If you're a bit frank and you're dealing with a person you don't particularly care for, you might use the expression "Do you want me to draw you a picture? How dense are you?"The thing is that it's extra effort for the author to draw pictures and think of image layout for what is ultimately the manipulation of symbols. If you're a proficient touch typist with a powerful editor, including macros, jump to definition, symbol search, multi cursor editing, you can spend a few minutes at a time without your hands ever moving far from the home row, let alone touching the mouse. We have very powerful tools for text manipulation and the highest bandwidth input device we have is a keyboard, so it's not at all surprising to me that text is still king for programming and probably will be until we have some kind of direct brain -> machine interface.

thom将近 5 年前

I think at best visual programming is good for tasks you might otherwise solve with a DSL. But for general purpose programming, you will end up with a visual grammar as complex as text, but harder for people to understand and compose (because we just happen to have a certain proficiency with written languages).

JaumeGreen将近 5 年前

Having tried for a long time for a viable option to practice programming in my phone while commuting (not seating, seldom having both hands available) I'd say that visual programming is not that useful in that medium, at least if it's Scratch-like. Maybe a language with better abstractions would be more useful.I tried a Scratch-like for android and did the first couple of days of Advent of Code a couple years ago. It was tyring (too many instructions to drag), midly infuriating (when something didn't fall where it should), hard to refactor (when experimenting).That's why that year I ended up transitioning to lisp, writing in a text editor and copying to a web-based lisp interpreter.The local maxima I found was this last year with J's android client. With their terseness array languages can be used quite effectively with mobile constrains.

solomatov将近 5 年前

I think the main problems is that it doesn't simplify things. Programming is not easy, no matter which representation you use. Visual programming systems might be easier for some categories of people, for example, electrical engineers, thought, due to the fact they got used to working with diagrams.

gfxgirl将近 5 年前

I recently had to fix some copy and pasted code across 11 files. So I write a regex something like<pre><code> /(.*?)somefunc$(.*?)$ {\n( *?)return a + b;/$1somefunc($2) {\n$3return a * b;/ </code></pre> And then search and replaced across the 11 files. I have no idea how I'd do that with a visual programming environment. I actually needed to do that about 7 times with different regular expressions to do all the refactoring.Also did this yesterday. I `ls` some folder. It gives me a list of 15 .jpg files. I copy and paste those 15 filenames into my editor, then put a cursor on each line and transform each line into code and HTML (did both). Again, not sure I how I do that in a visual programming environment.

评论 #23257333 未加载

globular-toast将近 5 年前

One point that I think people are missing is that language is the most powerful tool available for our brains. Language is what makes us human. Language causes our brains to grow and helps us to think about problems. Pictures don't do that. A picture is just a picture. If you try to make it more than just a picture then what you're making is a language.While visualisation is (sometimes) useful for grokking difficult concepts, writing a program is a completely different kettle of fish. I could draw some pictures that might convince you that you understand a Fourier transform, but you'd be no closer to being able to efficiently implement a Fourier transform in a computer.

robenkleene将近 5 年前

Visual programming languages aren’t plain text and therefore are harder to do version control for and harder to share. Whatever benefits visual programming languages have, and they are many, version control and easy sharing are more important.

gisborne将近 5 年前

Most of the problems described in other posts concern trying to convert text programming paradigms into a visual representation.Let me suggest two ways visual programming might be a big part of the future:1. New paradigms, such as constraint based programming, might well lend themselves better to a visual presentation; and 2. VR. Visual programming is indeed much less visually dense than text, but if you start over with the assumption you’re doing it in VR, that suddenly is if anything a virtue.Imagine something that was part Excel, part Access, with visual, animated 3D representations of other major programming abstractions also, and you start to see that VP might really be the future.

kazinator将近 5 年前

> Since text is difficult to manipulate without a physical keyboard, visual programming opens the doors to doing development on mobile devices.All content creation is difficult on mobile devices, other than passive content creation like shooting videos and taking pictures.Visual programming will be way easier on a desktop machine with a proper mouse, and a real keyboard (for the UI shortcuts you will end up using).But, about the main question, visual pogramming has no value beyond being friendly to newbies.This is like asking why don't Fisher-Price plastic tools for kids take carpentry by storm. They are so light and easy to hold, why don't we frame houses with them?

aldanor将近 5 年前

It's pretty big on some narrow areas - see, for instance, Max/MSP for audio design (<a href="https://cycling74.com/products/max" rel="nofollow">https://cycling74.com/products/max</a>)

noodlesUK将近 5 年前

I’m not sure it’s possible to keep the complexity managed (at least with current tools). If you’ve ever tried to build a complicated PureData patch or similar, you’ll notice that the complexity of visual programs just explodes.

pezo1919将近 5 年前

I think the problem is with more complex algorithms - where complex means dynamic in nature.Creating (new)/ destroying (existing) actors runtime is the hard part in programming, because the complexity dimension explodes via that. +1 thingy in the system means many new possible runtime flows - in theory, even if it's not a de facto new flow; you have to prove if it is and handle accordingly.You can show it in a visualisation, but to be able to do that it must be an animation; time matters.I think a higher language like Idris will be able to generate these animations from the code to make it easier to absorb existing codebases.

kweinber将近 5 年前

Salesforce is a visual programming environment that has huge adoption and reach.They are almost universal at large companies and have a large ecosystem of visually programmed/configured partner software companies and components.

sethammons将近 5 年前

> Emoji-only text seems to unlock a ton of value. Difficult concepts can be more easily grokked in visual form. Writing and Reading becomes more approachable to first timers.I can't imagine being able to write maintainable, well tested, scalable software (cough, software engineering, cough) with some version of drag and drop. I'd love a visual element added for helping navigate code. I like system diagrams, flowcharts, etc. But I'd like these to be generated by my code, not generate my code. I feel like this would be trying to write a book with only emoji and/or gifs.

gitgud将近 5 年前

Well, text is an abstraction for ideas. But text is a flexible abstraction, which is easy to store change, diff, read.Visual programming with nodes/blocks is another abstraction for ideas. But blocks and nodes are much, much less flexible. So these abstractions have to be much more precise... Which leads to problems.A good analogy is Lego vs clay.With Lego; you can make anything with the right bricks. The problem is each brick is precisely crafted and you're limited to the blocks you have.With Clay; you have the freedom to mold anything to whateber precision you need... But it might take you longer

pnako将近 5 年前

There are successful visual programming languages, like GRAFCET. But it doesn't scale beyond simple problems. As others have pointed out, it's about information density; what can be shown on a single screen, and also inputting data with a keyboard as opposed to a mouse.In principle, though, nothing prevents you in theory from writing very complex programs using visual languages. It doesn't really make things simpler; once you reach that point, as said above it's just more efficient to combine words than drawing shapes with a mouse.

iulian131将近 5 年前

There are a lot of solutions for doing programming in a visual way but most of them are not well known.For examples, for building backend infrastructures take a look at <a href="https://www.mockless.com/" rel="nofollow">https://www.mockless.com/</a>.They provide an easy to use interface where you can setup the data model and even complex functional flows. In the background the tool creates the source code and it's able to connect to your GIT repository and commit anytime you made some changes exactly like a developer would do it.

drbojingle将近 5 年前

If visual {x} unlocks a ton of value you'd expect someone would have been doing visual math or visual novels by now and the market would eat it up. It may exist but it didn't own the market for literature or science. Written word is still king. Not sure off hand what the advantage is but there does seem to be 'something' keeping writing on top of a visual centric approach across the board, not just in programming. Even on imgur where images are king the comments are mostly text.

评论 #23257337 未加载

collyw将近 5 年前

I have seen various promises of visual programming over the years (Java beans was going t be the next big thing when I learned). The fact is it gains you very little (in my opinion). The only thing that it solves is syntax, and that's actually a relatively easy thing when it comes to programming. MS Access had an OK visual query builder, but by the time you needed to anything moderately advanced it was as easy to switch to text SQL (plus text SQL is a more standard way of doing things).

ioseph将近 5 年前

I feel certain domains lend themselves better to visual programming. Reaktor is a great example in the audio space, but I'd hate to use a tool like that to write a csv parser.

slightwinder将近 5 年前

> Visual programming seems to unlock a ton of value.It gives some value, and sacrifies other values. So far tooling has not reched the point where the sacrified values are small enouhg to justifie the added values.> Programming becomes more approachable to first-timers.How is that relevant? In no industry should first-timers get any responsability. And textual code is easy enough to be grokh after a short while. The problems people have with textual code after that would still remain with visual code. So no value added.

lazyjones将近 5 年前

It's big enough to be available to the "mainstream", it just doesn't have the decades of tech debt C++ and other languages bring to the table.I've been programming for about 37 years now and recently, not wanting to mess with Swift for that, built a "quick action" command (for Finder) that converts/shrinks HEIC images to .jpg suitable for e-mail. Took something like 2 minutes with nearly no experience using Automator. It's not a niche technology.

cttet将近 5 年前

It is harder to get GUI right, UX in text/CLI is much simpler. In addition, developer UX is not quite profitable, the business side does not quite work out.

tmaly将近 5 年前

I think visual programming is just getting started. I have had good luck with teaching Scratch 3 to kids this past year.What sets it apart from previous versions of Scratch is that it can run in the browser. It makes much more accessible to a wider audience.Its my opinion with this browser based interface and the growth of instructional videos, we will see visual programming become more mainstream.

bor100003将近 5 年前

Visual tools seems to be harder to manage and add a lot of overhead.Have you heard of Informatica PowerCenter? It creates a mapping instead of writing down SQL query. The problem is you must manage inconsistent interfaces, resize windows, writing down in small textboxes.Of course it has its benefits, but in most cases it just doesn't help much in removing complexity but it adds its own.

AnimalMuppet将近 5 年前

> Difficult concepts can more easily be grokked in a visual form.Some difficult concepts can more easily be grokked in a visual form. I'm not sure that they all can. In fact, I suspect that it might be about even (as many easier in text as are easier in pictures). We just notice the ones that would be easier in pictures, because we're working in text.

rini17将近 5 年前

I think it is because of mainstream languages are all prose-first and don't expose the underlying graph structure in useful way for visual editor to manipulate. Closest I know are:* paredit/parinfer for Lisps are actually tree editors in disguise.* DRAKON. Having put critical business logic in it, was really a boon for quick understanding after returning to the codebase later.

tarsinge将近 5 年前

My guess is that in the majority of areas of programming the work is to express rules, and here text is simply more powerful. Are laws written using graphics? Visual programming can be useful for workflow (3D, movies or music DAWs). But otherwise for expressing rules (which is a good part of programming) visual is too limiting.

评论 #23255980 未加载

gabrielsroka将近 5 年前

Maybe slightly off topic, but has anyone seen Microsoft MakeCode? <a href="https://arcade.makecode.com" rel="nofollow">https://arcade.makecode.com</a>It can convert Visual to/from TypeScript/ JavaScript. And it works on mobile.It's for games, but you'd think the technology would be applicable for any kind of program.

MH15将近 5 年前

If you're a programmer that works on mechanical/fluid/aero systems there's a good chance you will use Simulink at some point in your career. It's great, but it's domain specific. Most everyone who knows the field will make a better simulation quicker in Simulink then in Matlab or C.

fxtentacle将近 5 年前

I can probably type 3 lines of source code in the time that it takes me to drag a block from the sidebar onto my document and then connect the inputs and outputs to other nodes.As such, I think Blender handled this very well. You can set up the material node graph both visually and through a scripting command line.

评论 #23255976 未加载

decompiled_dev将近 5 年前

I feel like this is covered already. Before I start coding I will always draw out diagrams of the components visually, where as the code is the details to make it actually work.Using box and arrow diagrams for documentation can give you a lot of these benefits without needing to adopt a radically new paradigm.

jki275将近 5 年前

Great teaching tool for hello world type stuff, and UML is nice for design documents that present data models and such.Beyond that, for real engineering? I've worked with EEs who write massive applications in Labview -- their codebases are all impossible to maintain masses of pain and suffering.

评论 #23254610 未加载

GoblinSlayer将近 5 年前

>Programming becomes more approachable to first-timers.As you said, Scratch is used in education for exactly this purpose. Visual programming fills the niche of high level scripting, when you have a system and want to script it in Excel style. On lower levels text is easier to deal with.

ripvanwinkle将近 5 年前

It has not hit the ergonomic standards necessary. It's like when speech recognition accuracy was 90% - that was high but still not ergonomic enough.I bet there will be a breakthrough in interfaces (likely aided by AI) though that will make visual programming a lot more widespread

scoot_718将近 5 年前

Programming in Scratch or Access or whatever is an absolutely painful experience. That's why.Beyond a small limit you'll start wanting abstraction - so good bye to seeing everything. Connections will become a mess, and moving between mouse+keyboard to keyboard is annoying.

mpweiher将近 5 年前

Maybe Visual Programming is The Answer. Maybe Not.<a href="https://blog.metaobject.com/2020/04/maybe-visual-programming-is-answer.html" rel="nofollow">https://blog.metaobject.com/2020/04/maybe-visual-programming...</a>

divan将近 5 年前

I wrote my thoughts on exactly this question here (long read, sorry): <a href="https://divan.dev/posts/visual_programming_go/" rel="nofollow">https://divan.dev/posts/visual_programming_go/</a>

koonsolo将近 5 年前

Next to what other people already said, I want to add that textual programming has a strong visual component. It's not just sentences separated by dots.A quick glance at source code reveals a ton of information, thanks to indentation and code blocks.

jasonlhy将近 5 年前

I used Visual Programming in my previous job. It is pretty good for waterfall logic and certain workflow. However, it is not scalable well for custom pattern, custom architecture, and Async, operation and functional programming paradigm

评论 #23254200 未加载

mwerty将近 5 年前

<a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD696.html" rel="nofollow">https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...</a>

brainless将近 5 年前

OK just think outside the whole context of programming. Would you write a medium-sized story (God forbid a novel) as a flow chart or something visual like that?Why/Why not?I am sure the first paragraph of that story as flow chart looks awesome, and then...

评论 #23256363 未加载

zubairq将近 5 年前

At <a href="https://yazz.com" rel="nofollow">https://yazz.com</a> we use visual programming to lay out forms, which are then scripted with code. Used in large enterprises. Is that not visual?

7leafer将近 5 年前

Try programming 7 Billion Humans and you'll see why. <a href="https://tomorrowcorporation.com/7billionhumans" rel="nofollow">https://tomorrowcorporation.com/7billionhumans</a>

JoeAltmaier将近 5 年前

It takes too much room. And you run out of symbols for detailed meaning. Try writing the Gettysburg Address in emoticons.It's essentially returning to ideograms like ancient Chinese or Egyptian writing. Not a good idea.

thrower123将近 5 年前

Because it is terrible. People keep trying to make it a thing, and bog down in the inevitable complexity where it becomes unworkably clunky to manipulate flowchart logic.

grandinj将近 5 年前

It does not scale beyond rather simple programs. Text has much higher information density for the specific problem domain of representing programs.

评论 #23257505 未加载

keithnoizu将近 5 年前

I'd be happy with just being able to color code files, hyperlink inbetween them and insert a few images along side code.

w_t_payne将近 5 年前

Visual programming has the potential to be really useful ... but I haven't seen anyone get the UX quite right just yet (although a few have come close).I spent a few years programming mainly with Simulink, and more recently have experimented a little with some graph-based game engine UIs. (Unity shader graph etc..)Now, as far as Simulink is concerned, I feel that it was (and possibly still is) an ergonomic disaster zone. There's just too much mousing around and adjusting routing between nodes. Also, merging is really difficult because of the save file format. This is a significant problem for many engineering organisations.For any visual programming tool, the value of a visual graph diminishes as the graph becomes more complex. It is most valuable when it is kept simple and illustrates e.g. high level components only.Now ... none of these problems is insurmountable, and having a relatively simple high-level graph to show the relationship between the major components of a system is an incredibly valuable communications tool -- but users do need to resist the temptation to use the graph for everything down to every if statement and for loop. These things are best used to explain the high level relationship between major system components and the overall flow of data through the system. Fine grained algorithms are better represented textually.So, over the years I've developed a configuration-driven framework that's designed to (eventually) be driven from a visual UI.Computationally, the framework implements a Kahn process network. I.e. it's a dataflow model, where the nodes represent sequential processes, and the edges have queue semantics. (The queue implementation can be replaced with implicitly synchronised shared memory in some situations, so it can be quite efficient).This enables me to e.g. implement intelligent cacheing of data flows, support record-and-replay style debugging, co-simulation, and automatic component-test generation.The nodes can be arbitrary unix-philosophy binaries, Python functions, or native shared libraries. (Eventually I plan to support deploying nodes to FPGA as well), and because of the Kahn process network semantics, behave in the same way irrespective of how the nodes are distributed across computers on the network. This makes it an ideal rapid-prototyping tool for quickly integrating existing software components together. E.g. throwing machine learning components together that have been written in different languages or using different frameworks. It's a bit like ROS in this regard.The dataflow graph itself is represented by a set of YAML files (or data structures that can be generated/modified at runtime), with different aspects (connectivity, node definitions, layout) separated to make textual diffs and merges easy to understand, and enabling teams to work more effectively together.Also, because the graph is explicitly represented as a design-time data structure rather than being a runtime construct, it's easy to use GraphViz to generate diagrams, allowing you to have documentation that's correct by definition without spending ages adjusting untidy connections and layouts. (Although I do want to spend some time improving the layout algorithms and providing some mechanism for layout hinting).Right now, you can only generate the visual graph from the textual description. In future I want to make it possible to edit the graph visually, so you can (for example), drag and drop compute nodes onto different computers really easily; stop, rewind and replay history, and simulate the effects of e.g. network contention and experiment with moving nodes around the available hardware to optimise performance.I'm also experimenting with hybrid symbolic/statistical AI techniques that use the data flow graph to help with fault finding, automatic safety-case generation etc.. etc..

narrationbox将近 5 年前

Story time (and a post-mortem of sorts): a long time ago I built a startup using Visual Programming for algorithmic trading.<a href="https://hackernoon.com/on-kloudtrader-and-visual-programming-5161e1e2b89f" rel="nofollow">https://hackernoon.com/on-kloudtrader-and-visual-programming...</a>It wasn't the most novel idea or anything but most existing systems were either clunky, expensive, or had UIs from the previous century. Ours was a hip SaaS inspired by Robin Hood, Bubble.is, and all the new Bloomberg terminal clones. We built an initial prototype using Google Blockly, did a ton of UI/UX research (studied every visual programming system from Sutherland's Sketchpad, to the Soviet DRAKON, to modern day MindStorms, Scratch, and the various PLC control systems and LabView derivatives) and slowly built out the rest of the algorithmic trading stack. It was tremendously difficult mainly because of lack of labor, our small startup only had 3 people. We were essentially translating by hand entire trading frameworks, backtesting tooling, and blotters into virtual Lego bricks. It was my first startup and I was inexperienced. We were fresh faced and between trying to raise funding, sales and marketing, product development, progress was slow. Patio11's (Kalzumeus) blog posts on Stockfighter were highly inspirational and we saw what they managed with only a small team and we tried to replicate. But between Patrick and the Ptaceks, they had several decades more engineering and business experience than us, something we completely discounted. The tooling around Google's visual programming system was like early Android development, works in theory but tremendously difficult to use. Microsoft's Makecode (which is also built on Blockly) had a magnitude more engineering manpower than us. Visual programming was not easy to build quickly — a production quality system wasn't something that you can clone in a weekend. We looked towards automation, around the same time, a code synthesis YC company called Optic appeared and we strongly considered leveraging them to allow us to build out faster.<a href="https://news.ycombinator.com/item?id=17560059" rel="nofollow">https://news.ycombinator.com/item?id=17560059</a>However, a couple months later, YC funded a similar company called Mudrex who had a prettier UI and a founding team with a stronger fintech track record.<a href="https://news.ycombinator.com/item?id=19347443" rel="nofollow">https://news.ycombinator.com/item?id=19347443</a>At that point we crossed the rubicon and pivoted to DevOps/PaaS, launching a Heroku-style product.<a href="https://KloudTrader.com/Narwhal" rel="nofollow">https://KloudTrader.com/Narwhal</a>Did the whole tour of Docker Swarm, Kubernetes, KVM etc. Built out our own cloud almost from scratch. Signed a contract with a broker to offer comission-free trading and everything. But it was a difficult product to sell in a crowded enterprise market with only a few (but big) customers and we were playing catch-up with companies like Alpaca, our product was being eaten from the corners by new features launched by companies like Quantopian and Quantconnect. Quantopian was where I cut my teeth on computational finance and automated trading, it was what inspired me to build a fintech startup in the first place, so in many aspects, our product being displaced was a validation of product-market fit if nothing else. In retrospect, at that time we should have switched to the ML Ops market instead, which is booming right now. Algorithmic trading, or at least the consumer focused variety that we were trying to sell, had a stack that is very similar to your usual ML stacks. In the two years I learnt about enterprise sales, the various shenanigans involved in FINRA, SEC compliance, and was tremendously valuable in terms of growth.These days however we are mainly doing productivity software for voiceovers and transcriptions with a bit of ML thrown in (voice cloning research). Fast growth, easy traction, great market. Not as lucrative as fintech, or at least a lower ceiling, but at our current rate of growth I am certainly not complaining. It is hosted mainly on Google Cloud, AWS, and other providers (after having to build our own Heroku we have had enough of DevOps)<a href="https://narrationbox.com" rel="nofollow">https://narrationbox.com</a><a href="https://twitter.com/narrationbox" rel="nofollow">https://twitter.com/narrationbox</a>If you are looking for advice or suggestions on building your own visual programming systems, I am available for consulting services.(On second thought I should probably turn this comment into a Medium post)

评论 #23254551 未加载

评论 #23256468 未加载

golergka将近 5 年前

Unreal blueprints and Unity playmaker are doing great, by the way.

aylmao将近 5 年前

I've thought about this, and I think I have a general sense as to why.First, let's look at the size of the keyboard in relation to the screen: it's huge. In most laptops, it is about half the size of the screen. Keys easy to use— they all work the same way, and we all grow up knowing how to use letters. You can press several at once, press them in quick succession, plus they are huge and haptic. You don't have to be precise with how you press one, and you feel it when it presses: your eyes, fingers and ears are all telling you that the information you're transmitting is making it to the screen.You effectively have a very big, very good, dedicated toolbar and the rest of your screen is either your canvas (the text area) or can be used for other tools to augment your programming.With visual programming languages, you have to reserve part of this screen real estate, for the input. It's like having to put your keyboard on screen: leaves you less space for the canvas or additional tools. Moreover, these UI elements are often smaller than the keys in a keyboard, and hovering/clicking something with a mouse doesn't provide haptic feedback. All this means a little more mental effort when composing with the mouse, and doing all the aiming, clicking, dragging and dropping. It's more "precise" and "delicate" movements that require more "attention", if you will.On top of that consider that there is no visual programming environment is ever "fully" visual— there's always typing involved at some point or another. You have to enter a number, a string, the name of a variable, etc. All this switching between the keyboard and the mouse is even more movement, more attention, more cognitive load to the layout of ideas. There is a reason all these modern IDEs have a "VIM mode"— you'd think our new tools would replace an older, more complicated way of doing things, but VIM has managed to survive in the hearts of experienced programmers because it allows them to type without reaching to the mouse.Let's delve into this. For an unexperienced programmer, "wording" the idea (remembering the syntax, etc) probably takes enough time that laying it out is not the bottleneck. For an experienced programmer, finding the idea is the bottleneck, but once found, wording it is quick, and so laying it down becomes the bottleneck. Being able to express things quickly becomes important.Moreover, revisiting this "finding the idea" and "wording the idea"— because wording the idea is fast, an experienced programmer might write while it's still looking for the right idea, as a way of "thinking out loud". They will type something, delete it, type something else, backspace repeatedly, etc. Seeing it in front of them helps the idea materialize, kind of how a musician might play notes as it's thinking of a melody, or digital tools allows artists to paint strokes and undo as they draw [1: notice in this link how a digital artist works. They're constantly drawing and erasing. It's the first video I found when searching "painting digital"].This is harder and slower to do with current visual tools.[1]: <a href="https://youtu.be/1lemi11CgLs?t=1200" rel="nofollow">https://youtu.be/1lemi11CgLs?t=1200</a>

评论 #23256292 未加载

评论 #23261298 未加载

toxicFork将近 5 年前

It's very early days.

anotheryou将近 5 年前

2D space is quite limited in arrangement I think (and with 3D you always have occlusion).There are very established graphical programming languages in the art-scene. They are easy to get in to, but become messy for complex projects.For the erst stuff think they are a bit like jupyter notebooks, but even better: everything compiles in real time and you can see it working. On the other hand it quickly just becomes a spaghetti mess..For everything else you need things with a limited scope. A single state to track (workflows, conversations) or really basic logic and strong abstractions (mangling two APIs together). Beyond that you need a programmer anyways and his gain from a GUI is limited.Generally there are a few things hard to represent, e.g. abstracting and recycling code (writing functions), parallel processes, state and highly interconnected things.A few examples for the curious:For Visuals:- quartz composer (old by now) <a href="http://www.mactricksandtips.com/wp-content/uploads/2008/03/networked-quartz-composer-patches.png" rel="nofollow">http://www.mactricksandtips.com/wp-content/uploads/2008/03/n...</a>- touch designer (modern, very nice nesting, you can zoom in to groups): <a href="https://youtu.be/hbZjgHSCAPI?t=49" rel="nofollow">https://youtu.be/hbZjgHSCAPI?t=49</a>Music:Pure Data and maxMSP (not strictly for just for music): <a href="https://youtu.be/rTQgfhsQ7xo" rel="nofollow">https://youtu.be/rTQgfhsQ7xo</a>Bitwig Grid (very skeumorphic, yet one of the modern "modular" ones. I dig the look of the droopy bezier curves though): <a href="https://youtu.be/dNdhbHGeHPw" rel="nofollow">https://youtu.be/dNdhbHGeHPw</a>More recent and really interesting to me is "no-code" environments that are now gaining traction.Business logic:BPMN + Camunda (you still need to code everything in text, but you can shuffle the flow around afterwards): <a href="https://youtu.be/HxtZf5VD6lQ?t=625" rel="nofollow">https://youtu.be/HxtZf5VD6lQ?t=625</a>No-code API plugging:Appmixer: <a href="https://uploads-ssl.webflow.com/5a9d00dba5e9fa00010cb403/5c8b82a6e9c13e6c33e03b7a_AM-2019-Screenshot-2.png" rel="nofollow">https://uploads-ssl.webflow.com/5a9d00dba5e9fa00010cb403/5c8...</a>AI-assisted chatbots:Cognigy: <a href="https://youtu.be/QSJ-nTwjn-c?t=1525" rel="nofollow">https://youtu.be/QSJ-nTwjn-c?t=1525</a>

ajuc将近 5 年前

I worked on a warehouse management system where we moved from C++/PLSQL to J2EE solution with JBPM 3 library (it's a java library that implements graphical language - looked like this [1]). It was very good fit for our system, but it still had lots of problems.The tooling was pretty bad (it was a plugin for older version of eclipse, had pretty bad bugs). We added our functionality to that plugin, and these were big usability wins, but also it made the plugin even less stable.Sometimes the graphical editor would "desynchronize" and if you haven't noticed you could be editing the process in graphical editor for 2 hours, but the XML file would remain unchanged (or even broken).So developers became paranoid about changing to the XML view every few seconds to check, or they just edited the XML directly all the time :)We had problems with several things that are solved in regular languages. For example there were subprocesses (analog of functions) - you could invoke a subprocess, pass arguments, wait for it to end, and receive return values from the subprocess. That solved problem of duplication of common functionality, but also required us to add support for pretty complex mappings when invoking subprocesses.For example we had a node that does a HQL query and shows the results in table on the user terminal. These queries were parametrized, and some parameters were constant in each process, just changed between processes. So we added a way to specify these parameters. Then there were some processes where it would be useful to specify additional conditions for a query in the graphical editor. So we added that.Then it would be useful to pass around that conditions between subprocesses, and fill some parameters there in some subprocesses, while the others remain to be filled by the app server.It was much too complex (I am mostly to blame - I was straight out of university and was amazed by this cool technology and wanted to add all the bells and whistles I could think of :) ).What we should do instead is just duplicate the subprocesses with different conditions, or construct these conditions in java code on app server and just call that from the graphical designer.Eventully like half of all our business logic was encoded in the nodes that invoked subprocesses in the mapping between inner and outer process variables.The other half was mostly in the conditions on transitions between the nodes.Both of these things weren't visible when you looked at the whole graph - transitions only showed labels (which were sometimes outdated vs the REAL condition code), and the invoke process nodes showed nothing until you clicked on them.So when you had a big process with 40 nodes you had to click on each node (and scroll through sometimes 30 mappings) to see "who set that variable".Same with transitions - you had to click on each transition to see the conditions.We tried to show the conditions in the main view but it wasn't easily changed in that plugin.Overall I think the graph language was great, the automatic transaction and persistence support was the best things about it, but the visual programming aspect of it was rarely useful, and very often problematic.I would now go the other way - have the graph language be text-first (with some nice DSL), and rendered to a nice graphical view on-demand.Better tooling could probably help, but we spent maybe 3 man-years on fixing and improving that plugin and it never worked great.[1] <a href="https://docs.jboss.org/tools/whatsnew/jbpm/images/multiple-processes-in-folder.png" rel="nofollow">https://docs.jboss.org/tools/whatsnew/jbpm/images/multiple-p...</a>