VisualCode approach

[toivo...@gmail.com]

Hi All!

I want to show little bit different approach.

Goal is to have lightweight, very little overhead and close to ordinary java code.

Hopefully latency is very low, but current code generator is not very advanced.

Generated code is directly callable from other java code, from outside it looks just like any other java method. After code generation no other runtime is needed.

So generated flows can be embedded to java code.

https://github.com/ToivoAdams/VisualCode_Site

VisualCode is probably not FBP.

But many ideas are same.

Externally flow looks like many other FBP systems have.

But working principle is little bit different.

There are no IP between ports, instead typed data is used, type can be any java type.

And data flow is pull based. Meaning block can ask data from inputs.

Any comments are welcome.

Thanks

Toivo

[Paul Tarvydas]

...
> Any comments are welcome.

I hope that this doesn't sound too harsh...

IMO, The main feature of FBP is the use of concurrent components (see, also, goroutines in GO). Everybody love(s/d) shell scripting on *nix because each component (command) is concurrent and does-one-thing-well. This, IMO, IMX, cannot be done using call-return. Collapsing components into Java call-return routines, IMO, defeats the purpose of FBP. FBP is like an uber shell-scripting notation - it allows for many more kinds of pipes ("flows") including feedback between concurrent components.

If you are going to optimize anything, it should be the concurrency primitives between components. I've done a lot of thinking about this, see bittarvydas.wordpress.com.

OTOH, maybe FBP is like machine learning - now that machines are faster, ML is feasible and maybe straight-forward, unoptimized, FBP is fine...

pt

[Paul Morrison]

Paul T, I totally agree with your second para! 

Didn't quite get the 4th one, though!  Assuming ML is Machine Learning, are we talking about some kind of AI?  How would you tie that in with FBP - although I could see some kind of self-tuning implementation which uses the number of cores on the machine... ?  What is optimized FBP?  What about CppFBP - IMO C[++] is about as close to the hardware as it is practical to go!

Regards,

Paul M

pt

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[paul tarvydas]

On Jul 17, 2017, at 8:42 PM, Paul Morrison <jpau...@gmail.com> wrote:

Paul T, I totally agree with your second para! 

Didn't quite get the 4th one, though!  Assuming ML is Machine Learning, are we talking about some kind of AI?  How would you tie that in with FBP - although I could see some kind of self-tuning implementation which uses the number of cores on the machine... ?  What is optimized FBP?  What about CppFBP - IMO C[++] is about as close to the hardware as it is practical to go!

Nope, we’re not talking about AI.

The reason that AI is taking hold is that the hardware can (finally) handle the requirements.

Hardware advancements might make FBP practical (without optimization), similar to AI.  Similar to Prolog.

I think of FBP as a “language”.  Threads and processes, to me, seem inefficient - at a “language” level.  So, I’ve been trying to find ways to improve the efficiency of such a “language”.

I tend to think of FBP “all the way down”, to the statement level.  Concurrency all the way down.

The problems (real-time) I face want to be solved as concurrent components.  I want to use flow diagrams all the way down.

On the surface, I tend to think that processes (threads) are too inefficient to use.  You don’t think so, your problems are larger grained and can be expressed as processes (threads).

My 4th paragraph is a note-to-self, my intuition might be wrong.  Maybe I can use processes (threads) all the way down.

I currently use Prolog for things (such as back-tracking parsing) in ways that were unimaginable decades ago.

pt

[toivo...@gmail.com]

Hi Paul,

No problem, thank you for comments.

Yeah, VisualCode is different.

But its not meant to invalidate FBP, or replace or compete with FBP.

Sometimes just call-return is preferred.

I’ve done software development many years and lot of code is hard to understand, hard to debug, hard to add features, find bugs, etc.

I try to improve how we do create software.

A lot of legacy code are call-return methods.

VisualCode allows to reuse such code without modifications.

Also for business code developers call-return principle is familiar and it's easy to understand.

So code blocks are easy to create.

And they can focus on business domain.

At the same time code blocks are connected visually and dataflow like.

Flow picture is easier to understand and debug, also modifications can be easily done.

Thanks

Toivo

[Sam Watkins]

On Mon, Jul 17, 2017 at 07:24:34PM -0400, Paul Tarvydas wrote:
> OTOH, maybe FBP is like machine learning - now that machines are faster, ML is feasible and maybe straight-forward, unoptimized, FBP is fine...

Simon Tatham's "Couroutines in C" are very efficient for fast switching;
but even unix processes and pipes can be fairly efficient if the data is in large batches.

[paul tarvydas]

> On Jul 21, 2017, at 12:52 PM, Sam Watkins <s...@nipl.net> wrote:
> ...but even unix processes and pipes can be fairly efficient if the data is in large batches.
>

I totally agree. And, you’ve put your finger on why I have a prejudice against full-blown processes - I tend to think of messages as small “events” (bytes, ints) instead of as large batches of data. Thanks for making that clear.

pt

[Paul Morrison]

Somewhere in the middle! 😉   We originally called the FBP data chunks "entities" - but the term was changed to "information packets" (IPs) to avoid confusion with Relational databases...

pt