While I don't disagree with your comment, it's a little ironic that hardware is designed visually. Instead of writing a netlist by hand, it's drawn as a schematic. The same applies to mechanical, construction or any traditional engineering fields. LabView targets engineers in those fields rather than those in software.

So, you are right that visual programming doesn't represent how a computer software works.. But it's exactly how computer hardware works.

Don't most use something things like SPICE and Verilog? The reason a schematic comes into play with because there are physical and spacial constraints in hardware implementation. However, that's not at the logical level. Pretty sure you don't use any visual language for FPGAs.

"Pretty sure you don't use any visual language for FPGAs."

There are physical and spatial constraints in efficient implementation on FPGA's. Although I don't use them, I saw plenty of examples in my research of people looking at them visually and changing representations to make them more compact or something. Modifying the physical layout outperformed whatever the initial synthesis was.

Parent said nobody uses a visual language for FPGA's, and parent is mostly right (some do use LabView, legend has it).

Yes, visual tools for manipulating physical aspects of the design are used, but there is little to no abstraction there like a language provides.

LabVIEW can also target FPGA's. This capability has been around for ~10 years now. Interestingly, LabVIEW and FPGA targets get along quite well, the structure of LabVIEW programs lend themselves to being mapped to an FPGA's HDL (see http://www.ni.com/fpga/)

I don't disagree with your comment either.

In fact, my sentiment extends to hardware design, which is why I've been toying (and building real stuff for work) with SKiDL lately, a Python extension that allows for text based schematic capture for printed circuit board design.

Of course, the actual routing of the traces still must be done by hand. However, during schematic capture, instead of drawing the same Zener diode input protection 100 times with a mouse, I just call the code that builds it in a loop.

Interesting. I have not tried SKiDL. All my designs are in Cadence or Eagle. Thanks! I will try itout

Simple hardware is designed visually. When things get more complex people resort to hardware definition languages and scriptable CADs.

I really meant circuit/physical design rather than high level design i.e pre-tapeout. Also PCBs are visually designed though I learnt about using python above and need to check that out.

Those things are inherently mechanical, so there will always be a last visual step before production. That does not mean people don't try to push non-visual tool as far as they can.

Actually I'd say the visual languages do a much better job representing what the computer circuit is doing.

But that's exactly the problem. Handling that complexity is the reason we invented textual programming languages.

We have better abstractions for textual programming because there has been much more research poured into them, but there's nothing preventing visual languages from being used at higher abstraction levels - they don't necessarily represent the computer circuit level.

The typical strongest point of visual languages is that you can represent relations by proximity. This way, you can directly indicate the connection between a caller and its calles with an anonymous connector line, whereas in text you would need to declare a variable name, pass it as a parameter and assign it to a local variable. This makes moving data between components much more verbose in text than in graphs.

Textual programs try to approximate this relations-by-proximity with indentation levels, but the expressive possibilities in a visual language are stronger. This makes them also more difficult to lay out and organize, though. But I foresee than in the future, better support in IDEs will make it easier to mix visual and textual languages.

It is worse than that: we have 100k years invested in language and 5k years invested in writing language down. Pure visual communication went out of style with the cavemen and was never very effective beyond being used as supplementary material.

Visual has some large advantages as well as drawbacks. It uses a different part of the brain for reading that works more in parallel, and can actually augment your short term memory. However, making visual work requires taking advantage of its concreteness, which textual language styles can't do very well.

I think textual programming languages predates visual languages on account of the hardware available at the time...

> arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks.

Or the other way around: When you write a tangled mess of code you can still navigate it with /bin/grep, this gets much harder when your code is a picture (though, when stored in SVG, it should be trivial to write a /bin/svg-code-grep). BUT: If you follow pure functional design principles, you rarely have to keep more than one screenful of diagrams in your head.

I think we have to differentiate between "general purpose visual programming languages" and "visual programming languages actually used".

Drakon, respectively its visual aspect, for example was, afaik, developed initially to allow physicists and chemists to model their domain specific knowledge in a much more intuitive way and I think it overall succeeded there. The few snippets I saw were very convincing demos[1].

Of all the attempts at purely visual, general purpose programming languages I cannot remember one that did not fall into any of these 2 camps:

* academic exploration of visual programming languages - nobody expected tangible results but we got squeak, etoys and drakon

* attempts to make programming easier by people who know just enough of programming to understand it is hard[2] - they usually promise tangible results by yesterday but never deliver anything that could count as a practically usable language

[1] http://drakon-practic.ru/

[2] Excluding all environments created specifically to teach children to code - they might be turing complete but I'd not call them "general purpose".

I think you mean scratch, not squeak.

No, strictly speaking I was speaking of Morphic[1], squeak's main interface. But scratch[2] indeed should have been in the list.

[1] https://en.wikipedia.org/wiki/Morphic_(software)

[2] https://scratch.mit.edu/

Oh, then Morphic came out with self, not squeak. It lives on in squeak and the lively kernel, I think.

I've also worked with LabView and completely agree with your assessments.

I'd also add that line between a simple project which reasonable men might agree that was well suited for LabView and a large project which is destined to eventually become 'a complete and utter mess of tangled wires and hierarchical blocks' is not at all obvious or delineated... and that's when the suffering really begins.

Indeed, I guess. But really, that's the fault of the editors, not the concept. Xilinx graphical editor downright crashed frequently. The professional developers used vhdl or verilog instead, obviously (and even that would have been subpar because of a half assed linux port, I bet).

What I mean is, if the devs had to dogfood their own product, if labview was self hosting, it could become a lot better. But in the background it's all just lowered to an intermediate programming language, the front-end is just grafted on.

It's a marketing tool, just look at the camel case name. I hate it with a passion every time it comes up.

Edit: I said "just" a lot, although, apparently it's quite good for it's intended purposes so take that with a spoon of salt.

Edit: This thread repeatedly features screenshots of visual demo tools, for scenegraph and asset creation, e.g. werkkzeug 3: http://www.pouet.net/topic.php?which=8787&page=127

I had never thought about the importance of being self-hosting like that.

I missed the point about the camel case name. In any case, it's marketed as LabVIEW (VIEW standing for Virtual Instrument Engineering Workbench), not LabView.

Probably it's not intended as a full development environment, more like a scripting language.

The name just strikes me as unprofessional, or at least not very serious, just like the programming environment that it is, and I guess that's not even a bad thing if that's intended, considering the target group (of technically inclined but uninitiated or at least slow with a key board kind of lab rats).

The clear advantage of text-based programming languages for complex programs is that all the wires and arrows are represented by symbolic names. Instead of drawing a wire, you simply use an entity with the same name (be it a variable, a function, or a data type). This is much closer to natural languages than a tangled mess of wires which becomes unmanageable after a certain level of complexity.

Having recently finished playing MHRD I think there are contexts where the graphical representation is a lot more clear. Granted, that game's language is at a very low level where you write your wires kinda DOT-esque, but I basically had to draw everything from the ALU onwards on paper first.

i don't think it's obvious at all that visual programming languages don't represent how a computer works, but actually, i don't even see how that matters at all.

for labview, i feel large programs benefit tremendously from its dataflow nature. every labview project i have worked on has exceeded 1,000 VIs, and it's often very easy to componentize things such that local changes stay local.

labview works fine with source-code control. the diff and merge story could definitely be better, but they are at least usable, particularly the diff.

Well LabView has internal revision control. The only prob is there's no reasonable concept of a "diff".

Anyhow agree. Large LabView constructions are extremely difficult to grasp, modify, and test.

Source control shouldn't be a deal breaker I feel. The on disk representation would just need to be optimised for source control. For example an AST in the form of s-expressions could represent the visual structure of the program and would be amenable to VCS manipulation

I really like to use drakon to visualize algorithms. When I had a course that was going thourgh it last year i wrote the algorithms we used up in drakon. I felt it gave a good overlook of the algorithm.

About source control: do they have custom diff and 3-way merge tools? If they do they could potentially be used with git.

>I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well.

Citation needed. A graphical language can "obviously" represent anything a text-based language can.

One could just as validly make the much-overused "citation needed" call on the assertion in your second sentence - except that we can reasonably require a purely graphical response in this case.

What citation do you need? At the very least, a visual environment could always trivially display each syntax/AST node, which will be the same as seeing a plain text version of the code (but better -- closer to something like Apple's Dylan IDE or Smalltalk environments).

Strip out the text and see how clear it is.

Who said you need to "strip out the text"?

Text has been part of graphical representations for milennia.

The cool part is that you get to decide WHAT text you get to see -- you're not just left with seeing the lower level code.

It could be that, but it can also be boxes representing objects or functions, program modules, interacting programs, at any level of abstraction one likes.

Stripping the text out is a way to see how much information the graphical element conveys.

By allowing arbitrary text in so-called graphical languages, you have turned your original statement into a vacuous truth - an empty tautology - as all text can be diagrammed.

Strip out the "text" in your code and just leave the syntax - we'll see how readable that is.

Well, that would certainly demonstrate the value of the text aspect of the code...

Exactly. A graphical representation and a syntactic representation of code will both have text in them. They just have different syntax for equivalent structure.

You seem to be conflating visual programming languages/environments with pictography.

They are not about that.

I am suggesting that your concept of a visual language is just an enhanced presentation of one that is fundamentally textual.

And I'm suggesting the keyword is "enhanced".

Movies are fundamentally photography too.

The fact that you have to stretch for that analogy, rather than name a visual language that offers more than just an incremental improvement to the process of reading text, suggests that the alleged power of visual programming is mostly hypothetical at this point.

Confirmation bias much?

I see that you have given up on any attempt at a factual argument.

About as minimal a graphical representation as you can get would be to have a tree of application nodes with S and K combinators as leaf nodes.

You can compile any lambda calculus expression down to S and K and "run" them as a graph.

Doing this on real calculation probably wins a prize for non clarity though...