101–110 of 124 posts
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…
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…
Have you worked with Borland Delphi? Is it close to the ideal you described?
Earlier quoted context omitted.
>line-by-line in c++ 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.
man that makes even less sense to me. do you have an example of code produced this way?
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. 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 la…
> The biggest programming language in actual use is Excel Which has cost companies and investors billions and is the most accident prone. http://www.zdnet.com/article/excel-errors-microsofts-spreads... No Version control no way to audit your code. These also come with visual programs.
Existing visual languages might not have good version control, but you certainly can provide it. See http://austinhenley.com/pubs/Henley2016VLHCC_Yestercode.pdf
Earlier quoted context omitted.
> 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…
> 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…
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.
Earlier quoted context omitted.
> 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 impenetrabl…
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.
Earlier quoted context omitted.
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%.
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. 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 la…
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…
Also a wrong analogy.
You can have 100% power/syntax parity between a visual language and any text language.
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. 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 la…
> The biggest programming language in actual use is Excel Which has cost companies and investors billions and is the most accident prone. http://www.zdnet.com/article/excel-errors-microsofts-spreads... No Version control no way to audit your code. These also come with visual programs.
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.