Easy: because it's meant to be consumed by people who don't yet agree with the claim, and they are more likely to consume it as text. Same reason you wouldn't write an article about why "You should learn Italian because it's the most beautiful language" in Italian.

The probable reason that this is not a video is that video production is not only more expensive than text production, but also involves entirely different skills. As a rule, visual programming does not require you to buy a video camera or learn how to present yourself on camera so I don't really think that your argument follows.

Disagree. While there are reasons, this comparison isn't apt. Videos suck because of their linear format and inability to search/reference, which doesn't plague visual programming. I could just as easily write "Why are there images and not all texts in these articles? That same reason is why visual programming can, in fact, not suck".

Visual programming suffers from the same low information density as video. I've actually had to work in visual programming environments and anything of moderate complexity (lets say a single average source file length) is simply visually untenable. A simple class you can page through in 1 minute is 20 screens in each direction represented visually.

I think that's more of an indictment on the specific environment/software you used than visual programming in general. One could argue thinking in terms of classes is invalid. Visual programming has value at a higher level of abstraction e.g. workflow management/stitching of components.

I used class as an example but the product was for workflow management and stitching of components and it was, frankly, ridiculous. Nothing was wrong with the product itself, it was sound. But the entire concept of representing working software visually that is unmanageable.

Honestly people can read and process text much easier then they can follow active visual nodes and lines. And I'm not talking about an abstract diagram; we are talking about visually designing something detailed enough to be executable. I think most people imagine visual programming based on pretty high-level abstractions but that's not the reality of programming.

Anything even moderately complex is too big to see all at once but could easily fit on a few screens of text. Making changes is even worse. I can easily move to the top of this paragraph and add another paragraph (which I just did). Have you ever tried moving around 20 visual nodes? Almost impossible to do easily. I just re-wrote a few sentences; easily 6 clicks and typing in a visual environment.

You are talking about deficits in the tools to work with graphical representations and lack of language support to contain behaviour to a single box (like a decent type system and separation of effects from pure computation)

I am the first person to admit that visual programming goes wrong about 95% of the time, but it doesn't have to... also nobody is expecting everyone to swap out their tools for statebox haha

Search and reference is a particular pain point of visual programming tools, as highlighted in other comments here.

Non sequiturs aside, the fact that you are not the target doesn´t mean that it sucks.

When the article calls it "Visual Programming" then I'm the target. If they describe it as domain specific visual editor then you will have a point.

check back in a few weeks... we are working hard on the tools and you should be able to try it yourself.

I definitely want a good demo video on the page.

but listen, I get it, I tried literally 50 different such tools, they all suck. Nobody in their sane mind decides to write one if you don't have a good reason. Certainly not in Idris :-)

but we have good reasons:

1) compositional theories of diagrams exists 2) such diagrams can express many "topologically equivalent" expression in the same diagram, this is a huge win! and very different from (AFAIK) all existing node-based editors 3) use cases in decentralised computing require fault-free tools that work like this

but really, I think generally applicable usable 2d-syntax exists...

I think most people here disagree with general applicability but if you had simply sold it for your specific use-case/domain you'd probably have much more positive responses.

I also disagree with general applicability :-)

But fair enough, I hear this a lot.

OTOH, a side-effect of working categorically is that we really assume very little, so we can apply the system is many things (at least the core doesn't restrict us, of course you still need to write code etc).

this is unlike all other systems which are domain specific.

you should think of it much more like an alternative syntax for bits of constrained Haskell code... anyway, thnx for the feedback, I am mainly surprised to see this on HN =)

:) valid point! We are not quite ready for HN prime-time, we are still working hard on the tools and will def. show a demo once we are there

but I come pretty much from the same standpoint: that visual programming sucks; but it doesn't have to be, that is what we are trying to demonstrate.