61–70 of 124 posts
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 ou…
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…
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…
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
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 p…
In general, yes, https://en.wikipedia.org/wiki/No_Silver_Bullet Though for simple tasks, syntax is the biggest blocker, and visual programming is preferable. See the success of IFTTT as an example.
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%.
Anyone know of a decent programming flow chart system? With drag and drop ifs, etc. This is for educational purposes.
Earlier quoted context omitted.
Yes, that's the vision. But then other people can use the plugin without coding, so the work is only done once. Disclaimer: I'm the founder, but didn't initiate this thread. Happy to answer questions though.
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…
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…
Which you're going to have in any non-trivial program.
This is a problem specific to particular dataflow languages. I've solved it without adding complexity.
Loops: http://web.onetel.com/~hibou/fmj/tutorials/Iteration.html
Conditionals: http://web.onetel.com/~hibou/fmj/tutorials/Conditional.html
Some non-trivial code: http://web.onetel.com/~hibou/fmj/tutorials/GregorianCalendar...
MIMD programming is built into the language at its deepest level, so threads aren't an issue.
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…
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…
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 orientation is a great way to have a good enough type system.
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.