Live data from Hacker News

Visual Programming Is Unbelievable (2015)

outsystems.com

101–107 of 107 posts

Re: Visual Programming Is Unbelievable (2015)

#101
Is there any visual programming language well-suited to implementing complex data structures like red-black trees? What about a recursive descent parser? File system?

I have not used visual languages extensively, but it seems like they are better suited to simple control flows with flat data structures and limited state mutation. This would explain their success for graphics shaders, audio, industrial control, etc.

Re: Visual Programming Is Unbelievable (2015)

#102
post #91

Earlier quoted context omitted.

> Why do you think that doesn't scale? Because it doesn't. Watch Bret Victor's last talk about Eve. All those ideas fail when you give them to novices and try to do anything more complex than describing a few static relationships. Maybe there's a way, but I'm skepitcal.

Yet end users are able to build fairly complex data structures and conditional processing using spreadsheets, so we know for sure that it can be done. Of course experimental tools will be severely limited compared with industrial IDE systems that have been polished literally for decades; it will take years before we get these new tools into shape and learn what their best use cases are. But I'm not skeptical, because…

Spreadsheets IMHO are a solution space that hasn't been sufficiently explored. However they are not particularly visual (especially if you try to do complex things with them), they are very much domain specific they are extremely computationally inefficient, they're very hard to version and they become intractably complex much quicker than equivalent imperative or functional programs.

I've thought about what could be done to improve on their weaknesses (like strong typing, bridging the gap to databases, better table naming), even wrote some code in this direction, but anything I can think of involves either making them less visual, less user friendly or both and doesn't even begin to address the lack of generality

Finally I have to point out that some spreadsheets have been around for longer than many programming languages in current use so they don't actually lack maturity, yet they have seen little improvement in over a decade.

Re: Visual Programming Is Unbelievable (2015)

#103
post #100

Earlier quoted context omitted.

> Wikipedia is not a good example: it is exclusively for humans. Not exclusively. Bots and Wikidata have shown themselves pretty capable of doing complex automated tasks on top of the structured data contained in the encyclopedia. And the wiki platform plus templates is a very general and flexible data structure that makes it easy for humans and software to collaborate. > In order for something to be understood by a…

You have a point about wiki bots, I hadn't thought of that. But isn't the "Wiki platform plus templates" an example of a textual programming language with a precise syntax and rules? As for the rest, I think it's a pipe dream except for the most basic, "build this out of predetermined blocks" apps.

Does the Visual Editor in Wikipedia count as a visual tool? :-P

My point is that the structure of a wiki, where each unit of content is a separate building block, can be used to build a visual system in the same way that you can build a textual one; the basic components of storage and APIs are the same, only the thin syntax layer is different. You are no longer dependent on the single stream of raw text following a strict syntax, which is the basis from which compilers generate binary code in traditional languages; you'd be able to build programs by arranging code and data in a network within a semi-structured platform, which is one of the characteristics of visual tools.

You're right that stuff like this has been a pipe dream for at least half a century, since the Mother of All Demos; but in the very recent years I've seen a lot of the required pieces falling into place, so I believe it to be possible.

If we apply the same amount of engineering work and refinements that went form Engelbart's demo to modern desktop systems, we could have a functioning system with this paradigm; the basis are in place for it, and many of us have the vision of the benefits it shall provide.

Of course, part of building a program may require describing some components using a textual representation, where it makes the most sense; but with a wiki-like "outliner" platform, parts of the working system could be programmed using visual code, and be integrated with those other components programmed in traditional languages. Heck, GUI builders and visual tools for database schemas already work that way; the only thing they lack is the capability to be expanded with new components, which this new family of visual tools have.

Re: Visual Programming Is Unbelievable (2015)

#105
post #53

Earlier quoted context omitted.

> stigmergy This is a new word for me—thanks :-)

It's a word that dictionary.com doesn't know. Anybody got a (ELI5-ish) definition?

Wikipedia: Stigmergy is a mechanism of indirect coordination between agents or actions. The principle is that the trace left in the environment by an action stimulates the performance of a next action, by the same or a different agent.

I usually think of it as "communication through modification of the environment".

And agent observes their environment, makes a decision about how to modify it, modifies it. The same or a different agent then does the same. Instead of a central authority dictating tasks, each agent knows the complete plan, and compares the current state to the plan to find the next step, then does it.

https://en.wikipedia.org/wiki/Ant_colony_optimization_algori... is how I first learned about the idea, and remains a good introduction.

Re: Visual Programming Is Unbelievable (2015)

#106

IMO, Visual programming does not have a proper definition yet. Coding frontend and coding backend are altogether two different things and sometimes users confuse the application of visual authoring (programming) in one area with the other. But I believe it is the future. I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. You would…

> I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. I disagree. I wouldn't have thought that Microsoft, author of Visual Basic, would be basically forced in 2015 to add improvements to their console system -- but here we are. If anything text-based programming is more prominent now than in the last 10 years. > You would be draggin…

>Your arms will get very tired. Ha ha, What about voice? Even without fancy stuff like gesture or voice, actually it wont be tiring. In fact if you prefer to use keyboard, you can solely work using pure keyboard to perform all of the visual wiring using configured shortcuts. It would be then much less effort (in terms of typing) that in traditional coding, as you don't need to do any boilerplate coding.

> I disagree. We have one giant visual-programmed workflow solution.

Why couldn't you break it up into multiple sub-workflows?

> They are snake-oil

Agreed. we need great open source solutions to move the needle from where it's been stuck for over several decades.

Re: Visual Programming Is Unbelievable (2015)

#107

Earlier quoted context omitted.

> I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. I disagree. I wouldn't have thought that Microsoft, author of Visual Basic, would be basically forced in 2015 to add improvements to their console system -- but here we are. If anything text-based programming is more prominent now than in the last 10 years. > You would be draggin…

>Your arms will get very tired. Ha ha, What about voice? Even without fancy stuff like gesture or voice, actually it wont be tiring. In fact if you prefer to use keyboard, you can solely work using pure keyboard to perform all of the visual wiring using configured shortcuts. It would be then much less effort (in terms of typing) that in traditional coding, as you don't need to do any boilerplate coding. > I disagree.…

> Why couldn't you break it up into multiple sub-workflows?

Oh it is broken up into multiple sub-workflows. There is even a way to call workflows like functions and there is a workflow that decodes XML.

Post reply on HN