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 retain great usability, but still with no limitations for advanced users.
Of course this hasn’t really happened yet, but I think it’s because the right balance, architecture, and respect for both user experiences has not been applied. It would also involve leading and tightening some standards to allow things to work together more consistently. Remember how things were before package managers? Why couldn’t there be a better way to standardize scaffolding operations and configuration for example?
I realize a lot of this seems to be pulling in two different directions, but so many of the pieces already exist, and so much of pro effort is wasted on grunt work tasks like getting things glued together that should be easier.
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 with an option to fall into a full text-based programming language.
> 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 from an accessibility perspective too.
On top of that, blueprints are stored in a binary format which can't be diffed, which means it can't be version controlled properly. I'm not sure blueprints would be my go-to example of not-terrible visual programming.
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.
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.
Blueprint sucks balls, it's super slow at runtime, it's slow to create logic, and it makes your game code unmaintainable and almost impossible to reason about. Not to mention you can't diff changes.
> 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.
I started with C and then turned to VVVV [0] for a while (now using Python). VVVV enabled me to do a lot of media-related things, that I would have had a hard time doing otherwise. It still has a special place in my heart :)
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.
>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.
You'd be surprised. The biggest programming language in actual use is Excel -- which is a case of a visual programming language (turing complete at that), even if it has cells in a grid as opposed to some flow diagram.
And lots of people are programming with visual languages inside tools like compositing pipelines, musical environments like Max/MSP, CAD and 3D packages, business logic definition apps and so on -- with the most popular case perhaps being visual game engines.
>Which has cost companies and investors billions and is the most accident prone.
Since it handles untold trillions (almost every company processes their financial data through Excel at multiple points) the "billions" it might have cost is a drop in the bucket.
There's a reason why it's used nonetheless.
>No Version control no way to audit your code. These also come with visual programs.
There's nothing about visual programs that say "no version control" (and of course auditing the code is even easier with visual programs). You either add visual-nodes aware version control, or with a text serialization and back, you use git or whatever.
> There's nothing about visual programs that say "no version control"
Well, this is one of those "in theory" things. In practice diffing and merging visual programs never works well, if at all. Usually nobody has developed the tools for a particular binary format.
Visual programming also has a lot of non-functional information like the exact placement of items. Textual code has indentation and such too, but not as much. To keep visual code clean you need to move it around often, but how to you merge that with other changes?
That's true, but I wonder if that's not a result of having too few of them, which makes it harder to abstract basic components that can work for many languages, like letters and lines in text.
Imagine saving the visual programs as SVG images of boxes and lines, with properties attached. Then you could easily make a generic merging tool that worked on those objects. It would sometimes make senseless combinations, but so do text version control utilities.
Likewise, merging a move would be implementable, even if the result might have to be tweaked manually. But then again, git and hg have merge conflicts too.
All mainstream version control systems (e.g. cvs, perforce, git) are designed for text but otherwise language agnostic. They are unsuited to visual languages which don't have a textual equivalent.
Human language evolved over years to let us describe everything in detail on a very abstract level. Computer languages inherit a lot these features from human language.
My favorite analogy: Visual programming languages are like a foreigner going to a Korean McDonald's. He can grunt at pictures and get what he points at, but he can only do a limited set of things that were envisioned by the menu planner. You can't get the burger without tomatoes by grunting.
>My favorite analogy: Visual programming languages are like a foreigner going to a Korean McDonald's. He can grunt at pictures and get what he points at, but he can only do a limited set of things that were envisioned by the menu planner. You can't get the burger without tomatoes by grunting.
Also a wrong analogy.
You can have 100% power/syntax parity between a visual language and any text language.
You can make a McDonald's menu that can represent everything you want to say in a text language with 100% power/syntax parity. But then it becomes too burdensome for the user. Just like most visual programming languages that have all these features make things much more complicated just to make it visual.
> 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 without having to declare and use intermedia variables.
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.
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 holds".
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 and other visual dataflow languages such as Prograph, Max, and vvvv.
(1) You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This allows you to drag an edge in the right general direction and it will find what to connect to, and also means you can develop a powerful type system with type inference built into the editor. This makes the language safe, but why stop at Hindley-Milner? You can add units (metres, flight levels, dollars, etc.) to real number types. You can give the language dependent types to make it even safer. This would eliminate many errors inherent in developing in other languages. And with a good enough type system, you don't need object orientation.
(2) You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. All you need are vertices (where processing is done), edges (along which values flow), constant values, and enclosures/lambdas.
(3) Iteration can often be abstracted away, by having filters operating on streams of data instead of single data items. It might be worth adding an even higher level, with bidirectional flow between processes or agents.
(4) You can define new types by connecting existing types, just like new functions can be defined by connecting existing functions.
(5) Version control and project management can also be done graphically.
I encountered, and solved, some little-known problems associated with dataflow.
My language isn't yet ready for release. (There's only one of me, not a large team.) I've begun work on dependent types. I need to develop a non-trivial application, for which I have a few ideas. The language also needs a compiler. I'll add version control and project management when there's any commercial interest.
Documentation (which I need to update) is at
http://web.onetel.com/~hibou/fmj/FMJ.html
The papers on the site describe obsolete versions of the language but are still worth reading. The tutorials are more up to date.
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!
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.
<< And with a good enough type system, you don't need object orientation.
This might be true, but object orientation is a great way to have a good enough type system.
<< Version control and project management can also be done graphically.
Yes, but it doesn't make it better. For example, in many applications you use a stream of commands and operations in the GUI to get a job done. Operations in the GUI might include things like selections, etc. In visual programming, you might convert that stream of application commands to a set of nodes. It's simple enough at first, but it turns out that things like selections -even selecting a row or two of data- are very, very tedious to do with a visual programming tool (when compared to just doing it in a GUI). What often happens is that you end up duplicating work you'd do in a more standard application by adding dialogs that allow the user to select the data using a standard GUI process and then capture their selection in the node that stores the operation. It's a bit redundant, and it doesn't get around the fact that you're still using a standard GUI to deliver a nice user experience.
There's also another issue with visual programming using vertices and edges.
When you write code, you might declare a variable. Then later on in the code, you refer to that variable. In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used.
A vertex-edge model can get ugly and become 'hard to follow' quite rapidly. You have all these inconvenient locations for things, and it can be difficult to try and comprehend a vertex-edge model for some types of code / processes / problems.
Some things are definitely better in a vertex-edge model of computation, but a vertex-edge model is not always more user friendly or more productive for many types of work.
Source: have worked on very popular visual programming tools. I love visual programming for some problems, but I am aware of the many, many, many pitfalls in this approach.
> 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, there needs to be a connection between the variable declaration and anywhere the variable is used.
There are no variables in my language.
Some of your other points are valid, but I was already aware of them. Development isn't easy, or I'd have finished it by now.
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.
> What if the input is the right type, but doesn't have the right count for the expression?
Let's say you have type T. T stores one or more pictures. Let's say you have a vertex in the vertex-edge graph that wants an input of type T, but it also wants a T that stores a specific number of pictures.
You can ensure basic type safety by requiring an input T for the vertex, but you cannot ensure expression safety since T satisfies the type safety requirement, but not the requirements of the expression represented by the vertex.
In your initial remarks, you mentioned type safety as a relatively easy thing to do, but you neglected to mention expression safety, which is equally important.
That a vertex wants T is trivial. That the underlying expression wants a T with very specific properties is decidedly non-trivial.
Additional remarks:
>> You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible.
This also doesn't handle type conversion, which can be exceedingly complicated in visual programming. Should casting be done by vertices? Should you allow implicit type conversions at the vertices? Should the visual programmer be able to choose? I only ask because it is incredibly tedious and frustrating to work with data flow computation tools that say they make things easier, but then have all these super strict requirements about what can be plugged into a particular vertex. Strictness MURDERS expressiveness, and programmers LOVE text because it's super fucking expressive!
>> You can keep the language design simple. You don't need special constructs for things like iteration and conditionals.
Yes, ideally, you can keep things simple, but you will need to address things like iteration, recursion, and conditionals. Here's why: the REALLY hard part about visual programming is determining how to strike the right balance between the 50,000 foot view and the microscopic view. Many programmers complain (rightly) about visual programming because they feel stuck at the 50,000 foot view and it's incredibly frustrating. On the other hand, doing iteration and recursion with visual programming tools is often very painful.
I'll write a bit more about why.
To this point, you could make everything work with functions -a 50,000 foot view- but this quickly becomes very inconvenient because it makes it incredibly tedious to solve many types of problems. You'll be forever wrapping things up and trying to decide on the right function boundaries or how large (or small) to make a particular chunk of computation.
So then you go ahead and do iteration and recursion. Now your simple vertex-edge design might need a stack, or at the very least, it might need to understand that parts of its computations aren't going to be directly represented by the data flow graph. Now we run into some interesting problems that we can explore using notions from abstract algebra.
A data flow graph works best when every element of computation is represented directly in the graph. But if we're using iteration and recursion (using them to prevent us from being inconveniently locked in to a 50,000 foot view of our problem space) then our data flow graph is no longer closed. Problems arise because important (critical) algebraic axioms are no longer satisfied.
By closed, I mean that there are elements of computation that are outside the set of data flow nodes (here, the word 'set' refers to the data flow nodes from a set-theoretic perspective). The initial conditions of a for() loop (the initialization expression, condition expression, and loop expression) are represented in the data flow graph, but there aren't any data flow nodes for any subsequent iterations. Since this is the case, how would the user work with them? What about iteration that doesn't use for() loops? Those are much easier, but it doesn't solve the incredibly difficult problems that arise when the data flow graph does not contain all the elements of computation.
With our loop situation, we have to look at a very common use case with respect to loops. Often in a loop you'll do some work, but you might also write a value to an unrelated variable or object that you're going to use later. Right? You might initialize something at a particular point in a loop assuming a particular condition is true or false or if the loop counter is a certain value. Since all those loop iterations -elements of computation- are not in the graph, how would you allow a programmer to capture a value during loop execution? This might seem like a nitpick or corner case, but it certainly is not, and these kinds of shortcomings are exactly what programmers mean when they say they don't like visual programming.
These are some of the most seriously difficult parts of representing computation with data flow graphs.
*
I hope you'll post on HN when you have something complete!
> it also wants a T that stores a specific number of pictures.
With dependent typing, not only can you specify the size of structures such as arrays and lists, the type system has access to those properties at run time even in dynamically created structures, so when you extract an element by position, you have to index by the correct integer ranges instead of using unbounded integers.
Type safety is anything but easy, but it's obviously the right thing in visual dataflow.
Type conversion by casting is unsafe and unnecessary. If you want to add a list of numbers, you have supply a list of numbers, or a list with untyped elements, and then the type system decides your list can only contain numbers. If you want to read numeric values from a list of strings and add them, you need to convert the strings to numbers first - a function call instead of a cast.
Iteration and recursion are painful if your language doesn't have a good way of doing them. The approach I took was to have the simplest one (the feedback loop) as a base and see what can be developed naturally from that, instead of having a special loop construct. This is completely general, and there are examples throughout the tutorial. The lesson on macros, in which iteration is extracted away, hints at how to make iteration less painful.
There's a good reason why I wrote an interpreter first: to iron out problems with function calls, functional arguments, iteration and recursion. All the data values are tagged. There are queues at each vertex input instead of a global stack. So the underlying machine is dataflow.
If you like, you can give a simple example (in Lisp, C, Java, or Python) of something you think cannot be encoded in my language and I'll see what I can do.
You can ensure basic type safety by requiring an input T for the vertex, but you cannot ensure expression safety since T satisfies the type safety requirement, but not the requirements of the expression represented by the vertex.
You should look into Idris; what you describe is just another type.
> 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 messages for type systems, I'd appreciate a link.)
Alternatively, you could use a simpler type system to just narrow down possible connections (maybe highlight endpoints of the correct type when dragging) and leave the rest to be handled at runtime.
> Operations in the GUI might include things like selections, etc. In visual programming, you might convert that stream of application commands to a set of nodes. It's simple enough at first, but it turns out that things like selections -even selecting a row or two of data- are very, very tedious to do with a visual programming tool (when compared to just doing it in a GUI).
I think just having a node labeled with operations defined using a wizard would be a pretty poor use of visual programming. For data selection, I think the node should represent the data directly (e.g. when it's the content of a form, the node should look just like the form), and connections should be made directly to individual fields instead of requiring dedicated selection nodes.
To be sure, that won't work as easily for variable sized collections, and objects with lots of fields will clutter up the program; but you can always use the tedious way for those.
> When you write code, you might declare a variable. Then later on in the code, you refer to that variable. In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used.
There are ways to avoid that, e.g. by allowing multiple nodes for each variable (similar to ports in circuit diagrams) that can be placed closer to where the variable is used. That does mean you can't follow the connections from the variable to all usage sites, but is closer to the way textual programming works.
Disclaimer: I have almost no experience with visual programming, and I have been moving to using the keyboard for more stuff lately (i3 window manager, Vimium in Firefox, ...) so I'm almost certainly not in the target demographic for visual programming.
<< To be sure, that won't work as easily for variable sized collections
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!"
This is probably because particular visual languages were designed specifically for non-programmers, and programmers who use them find that features they take for granted in more mainstream languages are missing.
In my language's IDE, you can set breakpoints or step through the code and inspect the contents of the the tagged value queues at the inputs of vertices.
Your point being, that a secondary information channel is necessary because the whiteboard drawing itself isn't complete?
I guess a lot of times formal errors and the like will happen on whiteboard. So no, the drawings probably aren't precise enough.
The process needs to be a dialog. Similar to the interaction you have with your compiler: You provide stuff. "Computer says no" (or tells you what is missing/etc) You alter your stuff and give it back to your tool. That loop repeats.
Something similar will be necessary for "whiteboard programming".
I guess it is not as trivial to convert drawings to code as I stated. But it still a tedious task that should be automated as much as possible.
Ah, you are one of the creators. If Bubble is similar to Delphi, I wouldn't call it visual programming (can you develop IF statements, loops and functions visually?).
A better name for Delphi kind of tools would be "Rapid Application Development Environment". And it's more convincing name than "visual programming" - I have never seen a successful visual programming environment.
I'm trying to solve this issue at the moment - it's really quite difficult to distill the "core components" of something like web development without leaving that's commonly-used out of the picture, but my project is slowly getting there. I'm aiming for an MVP launch within the next couple of months, feel free to check my profile for the early signup link if you're interested.
Like the idea. Still how would this mix with custom components? I mean, one could do so by having some sort of actions layer and linking that to components which may be build from some more elemental ones but the exact look and feel will be dictated by the library of elemental components available.
LabView is the classic example of graphical programming used in professional practice. It works well, but has a large learning curve. My first paid programming job was an undergraduate summer research project. I was tasked with re-writing a LabView function, a simple coefficient of variation - mean divided by standard deviation, in C++. LabView can call C++ DLLs. The resulting function was 5x faster and meant that our imaging of blood flow could be done in real-time vs. recorded and post-processed.
FWIW, it took 10x as long to get the DLL call to work as it did to drag-and-drop the coefficient of variation box into the GUI. There are certainly rapid prototyping benefits to be had with higher-level languages. Nowadays I prototype in Python and rewrite line-by-line in C++ if I really need the speed. I think GUI programming languages might serve a similar purpose.
I don't understand how/why people do this? the languages are so different I can't imagine doing it - libraries, control structures, types! what exactly are you prototyping then? just the shape of the code?
You use black-box unit tests developed against the Python code. You then write identical code in C++ that produces the same output (i.e. passes the unit tests). Then you apply optimizations/refactoring specific to C++. It is the latter - premature optimization - that is a pain in lower-level languages like C++, and which stops you from getting the correct result.
Bubble is such a great tool, and you really put a lot of attention to the details. I really enjoyed trying it.
My question is: So one big strength of textual languages vs visual tools(and DSL's) is expressivity - visual languages are limited to their specific domains, while you can use, say, python to build complete systems.
Do you see this distinction remaining ? or we'll have some way to build multi-domain systems visually ?
Yes, this distinction will probably remain, but we're trying to push where we need to get back to textual languages. If you need to build a machine learning algorithm, I'm not sure visual tools will ever be the way to go (though i'd love to see this).
But both ways work well together. In Bubble, you'd build your optimization algorithm as a plugin, and then you (and even better, others, non technical colleagues) will be able to use the action you've built visually. The Bubble interface becomes the common language between business, product people and coders.
Yeah, I've tried it at a few shops and it tends to be a cultural problem more than a technical one.
It's also really hard to build the right tools. It's very easy to sink 3-6mo into a tool that doesn't get a ton of usage because you either don't have partners on the other side who are invested or didn't solve the right problems.
For it to work right you need a lot of factors to go just right. When it does it's pretty incredible but feels a bit like trying to catch lightning in bottle.
I think if we want explore ways to connect these worlds we should do same as we are trying to do our architecture: separate view and logic. Most programming languages are quite messy if you think those as abstract model and therefore compilers won't have very good API (if any) for building application from non-textual inputs.
On the other hand views should be much more data-oriented. For example user actions should be copy-pasteable, editable as data and therefore usable for automation.
-Text? Easy "it has been since 60's".
-Visual (button click, drag&drop etc.)? "IMPOSSIBLE!". I claim that it's just bad habit which started as "MVP"-syndrome, continued as "Typical user won't..."-syndrome and finally ended up to "This is what GUI is"-syndrome.
Yea I think I may cut some corners but I cannot see any fundamental barriers here. Therefore I am currently researching this area and hopefully get something out at some point (or die tryin’).
Not really, as long as it’s a data driven app (and not a platform game...). About half of our paying users build startup-type, customer-facing products, while the other half is small businesses building internal management tools (like invoicing, custom CRM, etc).
When I wrote it, I was thinking along the lines of "hey, I like visual feature x in this website. It would be great to just tell bubble I want that". Just thinking out loud.
You know, a lot of people criticize visual programming as not being powerful enough -- when you encounter some kind of edge case you then outgrow the tool. Instead the problem with these kind of systems are is that it requires structured, problem solving type thinking. Learning the syntax is the easiest part of programming.
I see people struggling with tools like Google Calendar, physical security alarm systems and parking a vehicle in a tight location. They don't apply basic problem solving, and without developing that skillset these kinds of tools will continue to be useless for that demographic.
Brooks concluded that visual programming wouldn't speed up development by an order of magnitude, and he's right. But it has other advantages.
There has to be a silver bullet though. I haven't seen a large system which couldn't be implemented in less than 10% of the code. Chuck Moore, the inventor of Forth, says 1%.
There's a big trend of low-code,or no-code tools. Some of the reviews/reports do talk about 5x and sometimes 10x improvement.
There are some tools(if you want i can look later) that you input math and you get fully optimized code for a variety of architectures, so it's kinda 1%.
Am I right in assuming these are only able to handle specific tasks? What I've noticed applies in general, and is usually the result of programmers trying to be too clever, using frameworks, inappropriate use of object orientation, or not refactoring.
I actually feel that being domain constrained is a requirement if you want to offer the maximum amount of expressivity and simplicity[1]. And this is a must for a tool that aims at domain experts.
So maybe the question we should ask: how do we constrain our users to the bone, while still letting them do everything ?
[1]Intuitively, i feel like even textual languages haven't focused on simplicity. even python. they all require good memory, and focus. But is it possible to design a textual language(with the right IDE) that you can do real tasks in, for someone with bad memory and focus ? visual languages will surely get you farther there.
You don't have to remember the correct syntax, or input and output types, because the editor won't let you enter an invalid program.
The type system constrains many of the choices the programmer can make. It's only possible to connect an output to an input of a compatible type, and doing this can instantiate a type parameter, e.g. [X] -> [car] -> [add1] is only possible if X outputs a List of Int. If you want to connect to an input which is absent, you're only given vertices with inputs of the correct type to choose from.
I should probably put more information about both the type system and the IDE on my tutorial pages.
I see signup with email+password, or google, or github. Did I miss something? It seems perfectly legit, there are alternatives, and github seems much more appropriate than facebook here.
Personally, I very much prefer people to ask me for a social, rather than storing my password.
Oh got it, sorry. Yeah, I can see reasons, but they should definitely split the authorization in 2 parts if you want to also allow access to private repos.
yeah.... but it got me thinking, if you wanted to target HN people, who could quite likely have hugely intresting things in their private repositories.... create a home page like the one shown, label it with tech crunch / etc, make it look enticing, then have a login page like that ask for access to private repos, then get a bunch of HN accounts, give postive comments, and see what you can harvest :)
I noticed that as well before I ultimately backed out.
> Public and private
I've not developed with the GitHub API, so I don't know if that just comes with the type of scope they're requesting or what. Still, wonder why they're requesting such access?
Can't you ask to expand the permission once that becomes relevant? I imagine that people who just want to try bubble don't want to give you all their private code.
Bubble changes the way non-technical folks can build things! As a customer, I'd definitely recommend it to anyone looking to build an app or website quickly.
I just tried it. Tried to keep an open mind. I couldn't get the button to change the text, or rather, I didn't have the patience to keep trying to get the button click's action to modify the text value. The paradigm and mental load is shifted to gui boxes with entries and arrows to actions and more boxes. This is a wip at best. An AI you talk to just like a programmer is what is truly needed.
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.
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
I think Bubble is great and we need more people experimenting with visual programming!
We have been working on a visual tool[0] for ourselves and the development speed gains are incredible. Hopefully, there will be more non-text based programming environments.
This seems like an idea that is tried again from time to time: direct manipulation form editor backed up with some high level graphical workflow or data flow language to express logic. I wish I could get some comparisons on previous visual systems so I could figure out what was new here, or is it a new domain being targeted?
Programming involves producing algorithms, and that is difficult, no matter how you do it. You have to write, or (if your language is visual) draw code. People have tried making programming easy, beginning with COBOL. It doesn't work.
There isn't any information about what kind of programming language Bubble is. Visual languages are usually either procedural (Drakon, Scratch), or dataflow (Prograph, LabVIEW, Max, Full Metal Jacket) or its variant flow-based programming. There have been a few attempts at functional ones too, I think.
It's obvious a lot of work went into it, and there might be a few good user-interface ideas in Bubble, but it's hard to tell from the web site.
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?
I have seen a lot of tools like this but they seem to fall apart as soon as some (mild) complexity is reached. Labview is a good example. Really easy to click together something simple but as soon as you have loops, conditionals or threading it gets really complex. VB or Delphi worked because they only had the UI through a UI builder but then you had regular code underneath.
I think there would be room for something like Delphi or VB for web apps though.
It's kind of interesting that after all these years text is till the best representation for software.
Max/Msp is the best Visual Programming environment I've ever used. Its often better then full text based alternatives for the domain it targets.
I think a hybrid like that, where the visual aspect controls the order of the program steps, where as the steps are encapsulated and implemented in code can be pretty powerful. Not sure it would work for all domains though.
This is great!
Does anyone know what the "onboarding system" is called? The one showing tips and videos as you go along, I'd like to use it in my own project
Thanks for the reply, wow you could sell it as a separate product, looks very impressive! I like the contextual videos and the fluent integration with the rest of the interface. Great work!
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 retain great usability, but still with no limitations for advanced users.
Of course this hasn’t really happened yet, but I think it’s because the right balance, architecture, and respect for both user experiences has not been applied. It would also involve leading and tightening some standards to allow things to work together more consistently. Remember how things were before package managers? Why couldn’t there be a better way to standardize scaffolding operations and configuration for example?
I realize a lot of this seems to be pulling in two different directions, but so many of the pieces already exist, and so much of pro effort is wasted on grunt work tasks like getting things glued together that should be easier.