Show HN: Powerful Visual Programming Language (Book)
pipelang.comBut TBH, I'm with the rest that say this kind of visual programming is DOA for most applications.
I think the only way to prove that the responses here aren't AI would be for the developers add the sum of the first 30 even integers, then the next 30 odd integers, and the next 30 even integers after that...17 times.
The book itself IS the documentation. In fact, there is a "Hello world!" example of Pipe diagram in the book, which can be downloaded for FREE from Amazon Kindle or Apple iBooks.
Regarding the non-readable language of our article - we will fix the problem by polishing the language. Sorry about that. However, I would like to note the fact that article is hard to read is evidence contrary to AI generation which would definitely generate a pretty polished text.
For your convenience, we just added a link with a PDF of a book preview - please find it at the end of the posting.
While the copy sounds like complete fluff-n-puff, I honestly believe almost all of it is right, both about what's coming for the future of coding and the role that visual "lego" programming will play in it.
There's just one really major thing the author got wrong: the reason visual programming hasn't (yet) seen broader adoption. The reason is that each visual programming tool consists of one language married to one editor. Who wants to re-learn a whole new editor each time they need to work in a different language?
I used LabVIEW heavily for a few years in the mid 90s. What killed it for me was the sheer physical labor of programming in a graphical environment. All of that detailed mouse work gave me severe eyestrain headaches and wrist fatigue. When I'm typing text, I'm barely looking at the screen. Granted, this may be a personal physical limitation, so I can't offer it as a general argument against graphical programming.
Another issue is that decoupling the tools and the language lets you experiment with new languages and features with a bare minimum of effort. I've even tried out my own toy languages. But building a graphical editor, even a general purpose one that could serve multiple graphical languages, seems like a boatload of work.
Also, AI can generate textual code calculating x=x+1. It means we mostly do not even need to touch textual code - AI will do it for us perfectly. All we need to do is converting AI-generated code into visual components for composing visual workflows.
To sum up, AI and visual programming create a perfect synergy: AI generates code and visual programming composes generated fragments into visual components. This should minimize physical efforts needed to manipulate visual workflows as devs are going to work only on high (visual) level of abstractions while AI will be providing low (text-based) abstractions.
I feel like my time was wasted.
Have you heard the expression “putting the cart before the horse”? I just don’t see the logic here.
There is nothing preventing release of an idea before finalizing implementation. We are not the first going this route and I am sure there will be more after us. Like everything else, it has its cons and pros.