Live data from Hacker News

Bubble – Visual Programming

bubble.is

81–90 of 124 posts

Re: Bubble – Visual Programming

#81
This is maybe a bit too far away from technical people, but the ability to drag and drop components has been around since visual basic and delphi etc. we want the standard components we're all used to, panels, button, dividers, windows, menus, dropdowns, imageview, etc to be their to drop onto an app but also have the peace of mind that if a component doesn't exist that it's possible to create one.

for example here are ides for react:

https://nuclide.io/

http://reactide.io/

https://www.decoide.org/

I believe this is just a stop gap, there should and hopefully will be a multiplatform delphi of sorts in the future that will also target wasm/html/js/css

to target wasm as a first class citizen we should make sure libraries such and xlib (because you can build gtk and qt with it)/win32/cocoa have clones/implementations for wasm for example

Re: Bubble – Visual Programming

#82
post #3

No code required!.. unless you want need something that isn't a date picker or Google maps widget, then yeah you need to write code [0]. [0] https://manual.bubble.is/building-plugins/building-actions.h...

that's a plus, imagine the same but not being able to write code for what's missing.

Re: Bubble – Visual Programming

#83
post #47

Earlier quoted context omitted.

> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. This is something that a lot of game and graphics programmers are doing already. UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. I also think that having multiple ways to interact with programming languages is awesome fr…

>UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. Yep, and they produce things which look like this: https://forums.unrealengine.com/filedata/fetch?id=1137264&d=... That's an A* pathfinding algorithm, it looks like this in code: https://rosettacode.org/wiki/A*_search_algorithm#Python On top of that, blueprints are stored in a binary format which can't be diffed, which me…

For that complicated stuff, or essential things like well, pathfinding, you could just use C++ for it. There's no need to have everything in Blueprint.

Re: Bubble – Visual Programming

#84

Professional programmers often scoff at these kinds of tools, a lot of time for good reason. However I believe that with the right approach such a system could also speed development for a lot of serious and complex development efforts. It would have to use standard pro level libraries and tools underneath, with the easy UI being essentially and abstraction over of subset of the functionality. This would allow it to…

If by "easy UI" you mean a WYSIWYG UI editor, those exist for most serious development of applications, such as for Windows, iOS, and Android, though they still aren't the norm in web for some reason. But if by "easy UI" you mean the visual programming language, or the graphical DDL, then I'm skeptical it has any value to programmers. No programmer I know would want to use a visual programming language at all, even w…

Actually, the most popular (if not the only viable) business platform in my country has GUI for heavily modified / application-server backed SQL dialect and everyone is using it, rarely going down to the source to write a complex logical expression or copy things if it seems faster than clicking them. Not that more than half the logic goes into these queries, but it is definitely used. That is possible because the schema and migrations (and forms) are available, edited and maintained by the IDE, also via point-click and property bars. If that was not true, the cheap and quick high-level business programmer market would have a hard time no doubt. In fact, this text field is too small to explain how different it is from “regular” software development, but you can get the idea from PythonicDelphiVisualAccountingORMIDE fusion.

Back when we worked in the area, we could do 3-6 clients per day each, solving every task in a less than couple of hours, including conversation, problem analysis, coding, testing (manual, ofc) and receiving cash.

Re: Bubble – Visual Programming

#85

Earlier quoted context omitted.

Type safety isn't nearly as simple as you think when it comes to visual programming. There are lots of expressions/functions that need more than "Is the input the right 'type'?" What if the input is the right type, but doesn't have the right count for the expression? How do you deal with that? There are ways of course, but it's not so simple to figure out an elegant, scalable solution. This might be true, but object…

> What if the input is the right type, but doesn't have the right count for the expression? I'm not sure what you mean by that. > object orientation is a great way to have a good enough type system. It means different things to different people. The type systems the various kinds of OO provide are subsets of the existing type system, which will soon be extended to support dependent typing. > In a vertex-edge model, t…

I wanted to add: I skimmed your paper and slides. Your work is very, very interesting and well thought out. I'll take a deeper look when I'm not so tired.

One important thing: in your slides you write that data flow is underpinned by graph theory.

You are absolutely correct that data flow diagrams (whether a directed graph, directed acyclic graph, etc.) are underpinned by graph theory.

But the critical issues of visual programming are an algebraic problem, not a problem of graph theory. If it were just a graph problem, then you'd maybe be able to write a tool that allowed you to diagram an abstract syntax tree and you'd be done.

When I say the problem space is algebraic, I mean the problem space of computation ultimately involves sets of operators and operands that define an algebra, and the boundaries of this algebra determine what kinds of problems your data flow language can solve.

I've found abstract algebra (the notions of identity, commutativity, associativity, and closure) to be particularly helpful in breaking these problems down. I've already discussed closure in my longer response to you, but the axioms of identity, inverses, and commutativity are very useful for building strategies to handle type conversions in visual programming.

Re: Bubble – Visual Programming

#86
post #80

Earlier quoted context omitted.

Type safety isn't nearly as simple as you think when it comes to visual programming. There are lots of expressions/functions that need more than "Is the input the right 'type'?" What if the input is the right type, but doesn't have the right count for the expression? How do you deal with that? There are ways of course, but it's not so simple to figure out an elegant, scalable solution. This might be true, but object…

> What if the input is the right type, but doesn't have the right count for the expression? That just means that your type system isn't powerful enough to talk about counts. Of course most type system that can do this are probably too complex for untrained users. Maybe this could be mitigated by providing simple counterexamples for each type error. (Actually, if someone knows about research into understandable error…

You have good comments.

In another response here I discuss the problems with iterations and notions of algebraic closure. Your remarks about 'variable sized collections' are exactly the sorts of problems that arise when your data flow language can't/doesn't directly represent all the elements of computation.

When that happens, things either 'leak out' of the data flow diagram, or they remain locked inside impenetrable abstractions. Both of these problems broadly underline a lot of the complaints that programmers have about visual programming tools/languages.

Stated simply, the complaints are:

"I can't declare a loop/recursion in this visual programming language. This sucks!"

Or:

"Implementing loops in visual programming sucks because I can implement the loop/recursion, but there's no debugger/stack so I can't inspect the loop/recursion at a particular iteration step/stack frame. This sucks!"

Re: Bubble – Visual Programming

#87

Earlier quoted context omitted.

If by "easy UI" you mean a WYSIWYG UI editor, those exist for most serious development of applications, such as for Windows, iOS, and Android, though they still aren't the norm in web for some reason. But if by "easy UI" you mean the visual programming language, or the graphical DDL, then I'm skeptical it has any value to programmers. No programmer I know would want to use a visual programming language at all, even w…

> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. Here! But perhaps not as in typical visual programming tools. When I programmed ABAP which is traditionally heavy on methods/functions with lots of in and out parameters I always wished for the possibility to just drag some lines between parameters I want to map witho…

It is cool to hear this from fellow business-app developer. Half-proves my hypothesis that ideas just fly in the air once you get deeply in the field.

From regular developer point of view, I would like to operate blocks that merge/sort/filter datasets (dataflows), visually presented almost the same way they are in conceptual electronic blueprints, where output pin arrays are connected to input pin arrays, both having different names, but wires themselves unnamed. Current flow is not much different from datasets flow.

Re: Bubble – Visual Programming

#88
I am stuck currently with microservices orchestration. Is there a known visual tool to manage such use cases? For example to debug scenario, (may be based on Kibana). Or define the steps, preconditions, of the workflow?

Re: Bubble – Visual Programming

#89
post #47

Earlier quoted context omitted.

> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. This is something that a lot of game and graphics programmers are doing already. UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. I also think that having multiple ways to interact with programming languages is awesome fr…

>UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. Yep, and they produce things which look like this: https://forums.unrealengine.com/filedata/fetch?id=1137264&d=... That's an A* pathfinding algorithm, it looks like this in code: https://rosettacode.org/wiki/A*_search_algorithm#Python On top of that, blueprints are stored in a binary format which can't be diffed, which me…

Since its UE4, you probably should have linked the C++ code for A* since that's the alternative for most UE4 games these days. As a professional programmer, I find the code (both in Python and C++) to be quite clean and clear, but in my experience most production code is not that nice. Also, while it looks clean and clear, actually understanding the code is not that easy for me. The Blueprints screenshot is too low resolution for me to compare to see if that's any easier to understand or not. My point is that the textual format isn't necessarily easier and if it is, its largely because we've spent many years reading and writing code like that and presumably very little time reading and writing visual code. Of course we would be more fluent in textual languages!

A few years back, I used Max/MSP and Max4Live for a little while and I found it a liberating experience. Max has some, IMHO, rather deep problems which prevent it from being a realistic replacement for a "real" programming language[1], but it also had a bunch of things that made it great. First of all, I realised that the reason that most of the code you see online is a spaghetti-code mess is that most of it was written by people who did not have any software engineering training -- artists and musicians -- and therefore they did not learn the principles that we use (and are just as important even in textual languages) like encapsulation, abstraction, good naming, good factoring, single responsibility and so on. Without these things, code is a horrible unreadable mess regardless of if it is text or pictures. The target audience of Max (and the non-programmer designers that often use Blueprints) are not professional programmers with these principles ingrained, so their code doesn't look great, but it would look like that in text too[2]. However, these people, despite their messy code, manage to do great things! I've seen some write-only mess of Max code that generated awesome music and visuals and I've seen some write-only mess of Blueprints code that a game designer made to test out some gameplay ideas. In that respect, I think they've both been very successful.

Another thing I really liked about Max is experimentally developing a piece of code: throwing down a rough outline of what I wanted and then experimentally working towards a solution. One thing that Max allowed me to do that made this super streamlined is to not name things until I knew what they actually were. In text, you often end up with placeholder names. In visual languages, you have some unlabelled boxes or lines. Similarly, the debugging experience of being able to watch values flow through lines was pretty fantastic, as was the interactive development experience that Max provides. Finally, some algorithms are super clear in Max that are not so clear in text, but highly mathematical code does typically look and read a lot better in text.

For the record, I have not used Blueprints, but I have used a number of other visual languages: mainly Max and Flowstone/synthmaker, but also some mini-languages embedded in other tools (visual material/shader creation tools are popular in both game engines and 3d modelling tools).

[1] Max has quite limited datatypes. At least at the time, you could not have lists of lists and there wasn't really any other container data structures. That really limited what you could do (or at least, made the code a lot messier than it needed to be). I suppose the target audience doesn't need a hash map of lists of sets, but as a programmer, I really missed these things. I have a list of stuff somewhere that, if Max had these, it would be my ideal programming environment.

[2] That's if they would write it in text at all. I feel, at least for the musicians I know, they would simply look for other tools if they had to learn textual programming. I think one part of the appeal of visual for some of these people is that it tricks them into learning to program without them necessarily realising it, but if they were asked to learn a textual language they would make excuses about not being programmers. I've seen this happen.

Re: Bubble – Visual Programming

#90

Earlier quoted context omitted.

I've often wondered about this. The only graphical language I used ("G", in it's LabView incarnation) was terrible. But the basic idea: data-flowing through visible pipes is valuable. For one thing, functional programming shows that movement-of-data is a viable programming model. Secondly it's a great way to trace causality, helping with those debugging sessions you ask "how did this thing come to hold the value that…

It should not be assumed that all visual dataflow languages are similar. They're as varied as textual imperative languages. I'm developing my own dataflow language. Before I began, I had already programmed in many different languages and even designed some of my own languages and dialects. I came to several conclusions about how visual dataflow should be done, which are different from the approach taken in LabVIEW an…

A lot of what you said sounds so obvious, yet I guess its really not since much of that is often missing from visual languages :)

(3) this is very true and simplifies things a lot! Functional languages largely do this anyway, so there is precedent for this already in textual languages. Iteration was always a stumbling block for me in my visual-language-design escapades because, while feedback-loops are a natural way of looping in dataflow languages, they added too much complexity (for example, Max's left-to-right execution order -- I really don't like the horizontal positioning of blocks to affect the execution!), but if the language doesn't have loops at all outside of looping "functions" like map, reduce, range etc, that problem largely goes away to be hidden inside the implementation of these constructs. Nice.

EDIT: Just re-read the tutorial and I see that you do support recursion. I suppose this is the building block for the higher order constructs? Just like many textual functional languages :)

> I've begun work on dependent types.

I've looked at your language before (because dataflow languages interest me), but I didn't realise how much was going into the type system. I will be very interested to see a working version when you are ready to release something. Dependent types sound pretty awesome in any language, so I'm especially eager to see how that plays out in a visual language with a real type system!

Post reply on HN