An HTML 5 FBP interface?

[Justin Bozonier]

Hey everyone!

I'm talking with a friend about making a visual designer for a
programming language to make it readily accessible by beginners. The
first thing that came to my mind then was abandoning the c-style
languages and moving to an FBP style language that wants so badly to
have a nice UI.

So FBP it is, but is there already an OSS editor? I'd like something
canvas or SVG based. Any good frameworks you would use if you had to
build it yourself? I'm thinking RaphaelJS looks pretty awesome.

Thanks!

[Ron Lewis]

I think that rather than an FBP visual designer, the FBP Language itself would be a graphical language. Paul Morrison's DrawFBP is already a good start there because you can design a flow network pictorially and then generate the network as Java or C Language output.

If the FBP language is graphic instead of text, then the output could be Java, JavaScript, C, Pascal, or even assembly code or machine code! "Coding in the FBP graphical language would be something like using DrawFBP. It would also be something like using the Visual Studio user interface designer for Visual Basic, C#, and C++.

What I think DrawFBP does not do is let you graphically design the IPs. Like Visual Studio, you would drag and drop controls. In VS you drag and drop the controls onto a form. For the FBP Graphical language you would drag and drop components onto a canvas. (Maybe it is the same thing except for FBP, the terms might be components and canvas instead of controls and forms.

FBP seems to me to be on two different levels, and would be nice for the FBP Graphical language to handle both. One level is intra-program and the other level is inter-program. If you are working intra-program, the output would be an executable (.exe) file. If you are working inter-program, then the output might be something that splices several executables together. 

You could create new executables on the intra-program level that you could then include on the inter-program level. Underneath the FBP Graphical Language would be database type files, some textual code or scripts, and an engine. 

I would think that ultimately the FBP programmer would never have to see textual code. 

The programmer can extend FBP Graphical language on the inter-program level by (1) coding an executable in some other language such as C or Java, (2) using the FBP Graphical language on the intra-level to create an executable.

The programmer can extend FBP Graphical language on the intra-program level by writing C code or assembler code. (Or if we base FBP Graphical language on some other language like Java or Pearl, then the code would be Java or Pearl instead of C or assembly). -- Etc., etc. -- 

This idea for an FBP Graphical language goes much further than Visual Studio because VS does GUI's and in a very limited way does some other kinds of components. But FBP Graphical language would be a complete language system for creating most any program, even programs that run in the background without a GUI.

So, that is my thinking inspired from Justin Bozonier's post. Will be interesting to read others' inspirations.

[John Cowan]

Ron Lewis scripsit:

> I think that rather than an FBP visual designer, the FBP Language itself
> would be a graphical language.

I hate to rain on the parade, but low-level graphical languages are a
rathole that programming language designers have been going down for at
least 40 years, since research versions of graphics screens first became
available. They *never* work. Even spreadsheets use textual formulae.
I would hate to see the energy behind FBP become dissipated in this way.

--
"The serene chaos that is Courage, and the phenomenon co...@ccil.org
of Unopened Consciousness have been known to the John Cowan
Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
--Kehlog Albran, The Profit http://www.ccil.org/~cowan

[Justin Bozonier]

I'm talking about a beginners programming language and you mention low
level. What does low level mean to you?

Sent from my iPhone

[John Cowan]

Justin Bozonier scripsit:

> I'm talking about a beginners programming language and you mention low
> level. What does low level mean to you?

As in, used to define components or classes or whatever the primitive
unit of organization is. DrawFBP and similar tools work well at higher
levels of organization.

--
At the end of the Metatarsal Age, the dinosaurs John Cowan
abruptly vanished. The theory that a single co...@ccil.org
catastrophic event may have been responsible http://www.ccil.org/~cowan
has been strengthened by the recent discovery of
a worldwide layer of whipped cream marking the
Creosote-Tutelary boundary. --Science Made Stupid

[Ron Lewis]

I have not yet experienced a general purpose graphical programming language (AKA visual programming language) (VPL).

I found some links that could be inspirational towards a Flow Based Programming VPL. When I worked in Greenwood, South Carolina, there was an electronics engineer programming in the Ladder programming language. Links:

http://www.tri-plc.com/trilogi.htm  

http://en.wikipedia.org/wiki/Ladder_logic 

http://xtronics.com/toshiba/Ladder_logic.htm 

http://www.eod.gvsu.edu/~jackh/books/plcs/chapters/plc_function.pdf 

http://xtronics.com/toshiba/llp.pdf 

...maybe just eyeball the links to know more than I do about Ladder Programming.

The Ladder Programming Language is Graphical / Visual. I think it is used for programming Programmable Logic Controllers (PLCs). And that is low level. However, I don't know how you would use the Ladder Programming Language to write a game or a point-of-sale application, etc.

Now, I just ran into this VPL link on Microsoft that looks a lot like what I envisioned.

http://msdn.microsoft.com/en-us/library/bb483088.aspx 

And, wierd! It mentions flow of data and connection points. It seems a lot like the FBP model.

Seems like it is limited to Robotics, sort of PLC-ish. Probably cannot program a complete game, point-of-sale, or word processing application with it. Still, it looks to me kind of like Flow Based Programming.

I wonder whether Paul Morrison would comment on Microsoft's VPL on that link. Is it the same as FBP? Or how  different is it?

[Bob]

Hi Ron,

At first glance VPL does not compete with FBP: at its heart it seems to be simply a graphical representation of a C style language. I think it would be agony to create FBP components in it.

At Codecademy, beginners are using JavaScript. This seems more plausible.

Even better: my grandson found Scratch and taught himself - I gave him no clues.

Interesting idea of yours to define the data (IPs) graphically...
Bob

[Henri Bergius]

Hi,

On Mon, Jan 9, 2012 at 12:03 AM, Justin Bozonier <darkx...@gmail.com> wrote:
> So FBP it is, but is there already an OSS editor? I'd like something
> canvas or SVG based. Any good frameworks you would use if you had to
> build it yourself? I'm thinking RaphaelJS looks pretty awesome.

There is a quite simplistic editor that is part of the NoFlo FBP tool:
https://github.com/bergie/noflo

See also our tracking issue on the UI questions:
https://github.com/bergie/noflo/issues/1
There is a bunch of open source libraries that could be used for the
web based FBP editor mentioned.

NoFlo has been advancing slowly in the past few months as I've been
busy with other projects, but this winter there are again lots of
cases where I should be able to work on it.

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Jabber: henri....@gmail.com
Microblogs: @bergie

[Ralf Westphal]

I´d like to see a graphical designer for FBP (or alike) on iOS.
Think of it: sitting in a café and using your iPad to define FBP
models. Move processes around, zoom in/out, refactor...

But, alas, I think it´s not only about FBP. A true designer needs to
tie in what gonna happen within (!) a FBP process.
And it needs to help define the data that´s flowing through the
network.

Have a look at FlowStone, http://www.dsprobotics.com/
That´s pointing in the right direction, I guess. It allows to put
(Ruby) code behind components (processes).

So what I´m thinking of right now:

-A designer on an iPad to build FBP networks
-A language like Lua or JavaScript to write ad hoc code for FBP nodes
-A way to import at least webservices to let the FBP network
communicate with the environment
-A way to run networks on the iPad
-A way to deploy networks to a runtime on some non iOS computer
-A way to call libraries written in other languages (e.g. C#, Java...)
from FBP nodes at least when deployed to some runtime (until then such
libs could be imported as small webservices maybe)

I just want to be able to touch FBP networks with my hands. Manipulate
them in the truest sense of the word.
And I doubt that until that´s possible they´ll take off.

Just my 2c.

[Paul Morrison]

Hi Bob,

Scratch is neat! I'll have to get *my* grandson started on it!

I mention VPL in my book as one of Microsoft's efforts that seem to be
vaguely "FBP-like", along with Comega and .Net Rx, and I seem to
remember that a number of such systems have appeared in the robotics
area (as also in the music area!) - however I don't know enough about
it to really comment. I do like Ron's idea of drawing data IPs
graphically though.

[Paul Morrison]

On Jan 10, 1:36 pm, Ralf Westphal <ralf...@googlemail.com> wrote:
>
> Have a look at FlowStone,http://www.dsprobotics.com/

> That´s pointing in the right direction, I guess. It allows to put
> (Ruby) code behind components (processes).
>
> So what I´m thinking of right now:
>
> -A designer on an iPad to build FBP networks
> -A language like Lua or JavaScript to write ad hoc code for FBP nodes
> -A way to import at least webservices to let the FBP network
> communicate with the environment
> -A way to run networks on the iPad
> -A way to deploy networks to a runtime on some non iOS computer
> -A way to call libraries written in other languages (e.g. C#, Java...)
> from FBP nodes at least when deployed to some runtime (until then such
> libs could be imported as small webservices maybe)
>

>.....

Absolutely! Sounds like we are pretty close to doing that right now!
Flowstone is neat too - and so for that matter is Ladder. Do we have
consensus that we *don't* want to build Ralf's dreamworld in Java or
C#?! Because, if Java and/or C# are allowed, I'd like to remind
people that both of those FBP implementations are on
SourceForge... :-)

[Ralf Westphal]

Unfortunately the choices for programming or the iPad are pretty
limited.
C++ for sure is not among them.

Choose Objective-C or - sorry to say - C# for writing an iOS FBP
Designer.
And I can tell, the choice would be clear for me :-)

The language such a designer and runtime is written in does not
mattet, though.
Ad hoc processes would be codef in some scripting language.
And webservices are running remotel anyway.

[Paul Morrison]

On Jan 13, 5:39 pm, Ralf Westphal <ralf...@googlemail.com> wrote:

> Choose Objective-C or - sorry to say - C# for writing an iOS FBP
> Designer.
> And I can tell, the choice would be clear for me :-)

Sorry, which? I didn't realize Objective-C was still alive and
kicking... :-)

>
> The language such a designer and runtime is written in does not
> mattet, though.
> Ad hoc processes would  be codef in some scripting language.
> And webservices are running remotel anyway.

But surely the language in which the multi-threading is written *does*
matter. I felt it should be as close to machine language as one can
get... which is why I originally suggested C[++]...

[Ralf Westphal]

On 14 Jan., 01:45, Paul Morrison <paul.morri...@rogers.com> wrote:
> On Jan 13, 5:39 pm, Ralf Westphal <ralf...@googlemail.com> wrote:
>
> > Choose Objective-C or - sorry to say - C# for writing an iOS FBP
> > Designer.
> > And I can tell, the choice would be clear for me :-)
>
> Sorry, which?  I didn't realize Objective-C was still alive and
> kicking... :-)

have a look at the tiobe index. objective-c is on the rise. but it's
not required anymote for iOS development anymore.

> > The language such a designer and runtime is written in does not
> > mattet, though.
> > Ad hoc processes would  be codef in some scripting language.
> > And webservices are running remotel anyway.
>
> But surely the language in which the multi-threading is written *does*
> matter.  I felt it should be as close to machine language as one can
> get...  which is why I originally suggested C[++]...

this, i'd say, would be premature optimization. the point is, today
raw processing speed is much less needed than 20 years ago. in cases
where devs complain about a lack of performance, mostly the one to
blame is the the design - or the lack of it.

GC was too slow for most apps 25 years ago - but today we dont want to
live without it.

so dont worry about C or C++ at the beginning. using them wont
increase the FBP fan base by much - if this would entail any slow down
of development of a designer/runtime or less usability or less
platform reach.

[Paul Morrison]

I am still not clear whether you were advocating C# or Objective-C...

Also, I was suggesting C, not for processing speed, but because it
seems to me that you need a multiprocessing or multithreading engine,
and IMO the nearer you get to the machine language, the more languages
you can support in the components. How would you address this?

[Ron Lewis]

I don't know anything about developing applications for iPod, However, I found a couple of links that I think say that besides Objective C, that C and C++ are languages for iPod application development:

http://www.engadget.com/2010/04/08/apples-iphone-lockdown-apps-must-be-written-in-one-of-three-la/ 

http://stackoverflow.com/questions/3949995/what-programming-languages-can-one-use-to-develop-iphone-ipod-touch-and-ipad-i 

Any comments?

[Paul Tarvydas]

> I am still not clear whether you were advocating C# or Objective-C...

Objective C, like C++, is just C with a pre-processor in front of it.

It is claimed that Java is now faster than C, because Java (6?) implements adaptive optimization (dynamic recompilation).

http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization

pt

[Paul Morrison]

Hi Ralf,

The tiobe index is pretty interesting! While Objective-C seems to be
gaining (and Python is dropping) it is still only at 7%, compared with
17% for Java. I was surprised that C# is so far below Java (although
it is rising). These figures suggest to me that C is still a good
base for building a general tool.

I guess I am having trouble understanding why people on this group
don't seem to answer my concern about what tool to use as a
multithreading "base", so I am wondering if it is because of a
perception that no special engine is needed. However, my experience
is that, to get the whole power of FBP, you need both long-running
processes ("loopers" in FBP terminology) and "subroutine-like"
processes ("non-loopers"). While all FBP processes can be written as
loopers, not all processes can be written as non-loopers without
having to use static data to maintain context, which IMO makes
component-sharing problematic. An application built from multiple
loopers IMO must have some mechanism for multithreading the various
processes. Is such a mechanism available in the various languages
people have been talking about in this group? If not, what language
will you use to provide it? Am I missing something obvious?!

[Paul Tarvydas]

...

> I guess I am having trouble understanding why people on this group

...

IIUC, the most recent part of this conversation has been about putting FBP onto iOS (iPad, etc).

Until recently, it was contractually *illegal* to put a REPL (read eval print loop - i.e. a programming language) on an iOS device, i.e. apps could only be built on workstations, then downloaded - through iTunes ($$$!) - to iOS.

That's Apple marketing policy to control cash-flow and skim. Note that Flash is not supported on iOS for this reason (Flash isn't owned by Apple).

HTML and javascript kind-of thwart that strategy, so Apple has loosened up a bit. (Google for "HTML5 replace Flash").

Go to iTunes and see what "languages" are currently available on iOS. Lua is one of them ($9.99 - very expensive :-). A non-jail-broken iPad can only download apps from iTunes, hence, that is the place to look for iPad "languages".

> don't seem to answer my concern about what tool to use as a
> multithreading "base", so I am wondering if it is because of a
> perception that no special engine is needed. However, my experience

...

> will you use to provide it? Am I missing something obvious?!

The workstation languages all have "native" api's and "direct" access to underlying O/S processes. If the engine really wants to use processes, then any language can request them from the O/S.

For example, Clojure does exactly that.

Clojure's "compiler" emits java bytecodes.

Clojure's support library is written in Java (or was).

Clojure's support library uses Java's "Thread" class to implement "invisible" concurrency.

Java's Thread class is written to take "full" advantage of multi-core.

Clojure gets multi-core "for free".

Clojure is compiled to machine code "for free" by Java's jit engine - the thing that compiles java bytecodes to machine code (before the first use of the class), yet another technique stolen from Lisp :-).

My Common-Lisp based engine uses the supplied multi-processing library to get multi-core "for free", and I even argue it down to one process per core - for efficiency.

You might even consider writing FBP in Clojure or Scala :-).

Or, take the Clojure and Clojure-CLR approach. Learn the JVM and CLR bytecodes (they both have documented classes to help one construct .jars and assemblies) and write FBP in bytecode (which then gets jit'ed to machine code and gets multi-core "for free"). (Or, of course, write a FBP-to-bytecode compiler in FBP).

...

> processes ("non-loopers"). While all FBP processes can be written as
> loopers, not all processes can be written as non-loopers without
> having to use static data to maintain context, which IMO makes
> component-sharing problematic. An application built from multiple

...

That's essentially an orthogonal argument. (!)

I maintain that everything should be a non-looper and that you write the engine for bare metal (no O/S). Then, use O/S features if you're feeling lazy and wish to add inefficiency.

And, to write a looper, you simply send your(non-looper)self "do it again" events.

But, my attitude comes from working in the embedded space, not the data processing space. I can see that, if one's attitude is that "records" or "streams of characters" are the primary concern, one might think in terms of loopers.

[Why does static data make component-sharing problematic? All loaders support the concept. If you use PIC (position independent code), then you don't even need an MMU.]

----

It seems to me that textual languages must truly suck on iPads. Keyboard languages grafted onto a decidedly non-keyboard device.

FBP could win big by us developing a way to create programs using iPad-friendly gestures.

That might be the killer app for FBP. And, we've already done the research on how to break programs up to make them draw-able.

Jonathan Edwards thinks this way, also, http://alarmingdevelopment.org/?p=662 but, I'm not sure he believes in the power of FBP.

pt

[Tom Young]

On Mon, Jan 16, 2012 at 3:15 PM, Paul Morrison <paul.m...@rogers.com> wrote:

  These figures suggest to me that C is still a good
base for building a general tool.

As I wrote the DFD in C, I must agree. 

I guess I am having trouble understanding why people on this group
don't seem to answer my concern about what tool to use as a
multithreading "base",

BNFC can generate C, C++, C#, F#, Haskell, Java, and OCaml code, so personally, I would look no further than these.     BNFC enables one to make
NDL(Network Definition Language) changes easily (and understandably) and then generate a corresponding interpreter in a few seconds.    I will never consider expanding the DFD/NDL to define components; the language to define their connections is quite complex already and is getting more so as different enhancements are included (ex. persistent IP message queues).

so I am wondering if it is because of a
perception that no special engine is needed.  

 The DFD uses executables as components, and so is multi-processing rather than multi-threading.     I have little problem getting my quad-core system to run 4x100%.     DFD programs run very nicely as fast CGI in Apache, also.

However, my experience
is that, to get the whole power of FBP, you need both long-running
processes ("loopers" in FBP terminology) and "subroutine-like"
processes ("non-loopers").  

Absolutely.
 

An application built from multiple
loopers IMO must have some mechanism for multithreading the various
processes.  Is such a mechanism available in the various languages
people have been talking about in this group?  If not, what language
will you use to provide it?  Am I missing something obvious?!

The difficulties with language choice and multi-threading implementation are some of the reasons I prefer multi-processing over multi-threading.   

So I don't foresee any version of the DFD running on IOS;  it might well be used to run an HTML5/Ajax/... web service, though.

             -twy

--
"...the shell syntax required to initiate a coprocess and connect its input and output to other processes is quite contorted..."
W. Richard Stevens [Advanced Programming in the Unix Environment, p441]

[Ralf Westphal]

Sorry, Paul, I don´t understand your focus on highest performance for
a FBP engine.

The very reason I´d use FBP is to easily use concurrency for my own
functional units.
So the benefit of FBP lies in:

-ease of use
-concurrency of my code

Why should your FBP runtime code be particularily fast? It´s may code
running 98% of the time - hopefully ;-)

And getting it to run on different threads is most easy in any of the
major platforms.
No need even for higher level threading libraries like Microsoft´s
TPL. The very FBP paradigm is replacing them.

This is one side of my opinion on performance. No need to going low
level.

The other side is: yes, an FBP runtime needs to be fast. But not in
terms of multithreading. That´s done well by the framework of the
language you´re using. But an FBP runtime can do stuff besides
managing threads. To make it most flexible and easily add meta-
programming features (e.g. automatically logging IPs or pausing the
whole processing for some component replacement) it needs to
"interpret" the FBP network. That´s taking some time. That needs to be
minimized.

But still: for a start I´d say "Don´t worry!". Ease of use and raw
functionality are much more important.
The "FBP movement" is not suffering from a performance problem. There
isn´t anybody saying "Wow, FBP is cool - but unfortunately too slow
for practical use."

No, the "FBP movement" is suffering from there being nobody at all
giving any feedback. It´s suffering from a lack of visibility.
And that´s rooted in a lack of communication about FBP in trade media.
And it´s also caused by discussions about the perfect platform for
highest performance - instead of whipping together just about anything
true to the spirit of FBP and putting it on public display on one of
the major OSS hubs like github, sourceforge, or codeplex with cool
samples showing off the major benefit of FBP: ease of use.

PS: "Component sharing" is always platform specific. Thinking "We´ve
written the FBP engine in C so it should be very easy for people using
Java, C#, C++, Ruby, Clojure to use it." is wrong. (Sorry, I don´t
want to be rude, but that to me is the state of programming technology
as well as culture. As a C# guy I do not want to interface with C
DLLs. I can, but I don´t want to. Whether Ruby devs can do it, I don´t
know. I think there are very good reasons for the existence of ports
of major frameworks like Spring or Esper to other platforms like .NET.
And there are good reasons why they were not writtin in C++ in the
first place. This is the 201*, not 198*. The preoccupation with memory
and performance is over. A telling sign of this is, there are no more
compiler comparisons around. We are in the age of usability.)

[Dan]

Quote from Ralf Westphal:

"The preoccupation with memory and performance is over. A telling sign of this is, there are no more compiler comparisons around. We are in the age of usability.)"

I agree with the fact that we are in the age of usability but fully disagree that the preoccupation with memory and performance is over. Lack of preoccupation for the memory and performance hides sever logical problems. Memory and performance are physical aspects but they influence a lot the logic, unfortunately.

With FBP we want to let the programmer free to focus on the logic of the program but we cannot make abstraction of the physical aspects. The program from the source code to the bytecode should be a "liquid transformation". This transformation is the "compiler" that could be just another FBP program by itself. Having another platform / language between FBP source code and byte code (e.g. C, C++ etc.) is just another von Neumann bottleneck, it is no difference. That is why the virtual machines are von Neumann bottlenecks too, they replace the physical microprocessors with virtual microprocessors that do not change the physical aspect but add other restrictions.

The optimization (e.g. reuse of code, memory) is not just a physical aspects but it is part of the logic too. As long as the FBP components are a simulation of a physical / virtual reality they are governed by the same "physical" rules.

A good product is the result of a natural evolution. If you think that is something in our body that is not fully optimized at micro level than you are wrong. It is exactly the opposite: the body is an image at macro level of all that exist at micro level. Not taking care about the physical aspects it is like trying to walk on the water.

Another rule (or better said the result) of the natural evolution is the fact many benefits are coming for free. It's the result of reusing the same physical components in different places with different roles in different combinations. Micro level (physical in nature) is the only one that supports everything else above.

[Tom Young]

On Wed, Jan 18, 2012 at 6:51 AM, Dan <dpol...@gmail.com> wrote:

Quote from Ralf Westphal:

"The preoccupation with memory and performance is over. A telling sign of this is, there are no more compiler comparisons around. We are in the age of usability.)"

I agree with the fact that we are in the age of usability but fully disagree that the preoccupation with memory and performance is over. Lack of preoccupation for the memory and performance hides sever logical problems. Memory and performance are physical aspects but they influence a lot the logic, unfortunately.

The performance discussion is not over; the context has shifted from 'How fast can my program run on my processor' to 'How can I get all available processors to run my program'.   FBP is the best, simplest, most effective answer to this question, however we cobble the runtime together.

          -Tom 

[Paul Morrison]

On Jan 18, 4:31 am, Ralf Westphal <ralf...@googlemail.com> wrote:
> Sorry, Paul, I don´t understand your focus on highest performance for
> a FBP engine.
>

That's the funny thing, Ralf - I don't think I am hung up on
performance! If anything I am hung up on allowing application
builders to use whatever language seems most appropriate for a
particular function, rather than having to write the whole thing in
one language because you want to write one part in that language. To
allow C# and Java to coexist, you can actually write part of your app
in C#FBP and the other part in JavaFBP, and have the parts communicate
via sockets (I've done it) - but that feels rather coarse-grained to
me.. So I wanted to get down to a finer grain.

Further down you say

>And it´s also caused by discussions about the perfect platform for

>highest performance [ I might stop at the words "perfect platform"!] - instead of whipping together just about anything

>true to the spirit of FBP and putting it on public display on one of
>the major OSS hubs like github, sourceforge, or codeplex with cool
>samples showing off the major benefit of FBP: ease of use.

Hey, sounds great! Let's do it! And I honestly don't care what
language we do the demonstration in - as long as the onlookers realize
that it actually is language-agnostic :-) So let's move on to the
next stage!

[Ralf Westphal]

On 18 Jan., 21:29, Paul Morrison <paul.morri...@rogers.com> wrote:
> performance!  If anything I am hung up on allowing application
> builders to use whatever language seems most appropriate for a
> particular function, rather than having to write the whole thing in

I agree if you mean FBP should be available on all platforms. A Ruby
guy like a Java or C# guy should be able to do FBP.

I disagree, though, if you mean the same (meaning "the exact same
binary") FBP "library" or "host" should be used by devs for different
languages to do FBP.

The FBP programming model (API, if you like) should be the identical
on all platforms (with minor adjustments to their differing cultures).
So what I´m thinking of are FBP "ports" like there are Spring or Esper
or JUnit ports to other platforms/languages.

> Hey, sounds great!  Let's do it!  And I honestly don't care what
> language we do the demonstration in - as long as the onlookers realize
> that it actually is language-agnostic :-)  So let's move on to the
> next stage!

So why don´t you set up a different thread to compile a list of
essentials for such an undertaking.

And by the way: what´s also needed are examples of how to do FBP in
"business scenarios". Have a look at the exercises mentioned here:
http://geekswithblogs.net/theArchitectsNapkin/archive/2011/06/25/appkata---enter-the-next-level-of-programming-exercises.aspx

A more complete list of links to the iterations of those Application
Katas you find here:
http://clean-code-advisors.com/ressourcen/application-katas
(Don´t despair: Even though the page is in German the exercises are in
English.)

I´d like to see FBP solutions to these problems.

[Paul Morrison]

Hi Bob,

I showed Scratch to my grandson on Tuesday, and he got pretty
excited! He hardly noticed when we tiptoed out!

So the obvious next question is: since you can (I believe) put
multiple Scratch structures in the drawing area, can you run multiple
Scratch structures concurrently? And then of course, can the Scratch
people give us ports and connections?! It would be a fantastic
learning tool!

[Paul Morrison]

Turns out you can get "broadcast x" and "when I receive x" to form a
connection between what are essentially coroutines! I have a simple
app with 3 processes working!

Here is the picture (hope you can read it):
http://www.jpaulmorrison.com/graphicsstuff/Scratch_network.png

[Paul Morrison]

On Jan 19, 4:56 am, Ralf Westphal <ralf...@googlemail.com> wrote:
> On 18 Jan., 21:29, Paul Morrison <paul.morri...@rogers.com> wrote:
>
> > performance!  If anything I am hung up on allowing application
> > builders to use whatever language seems most appropriate for a
> > particular function, rather than having to write the whole thing in
>
> I agree if you mean FBP should be available on all platforms. A Ruby
> guy like a Java or C# guy should be able to do FBP.
>
> I disagree, though, if you mean the same (meaning "the exact same
> binary") FBP "library" or "host" should be used by devs for different
> languages to do FBP.
>
> The FBP programming model (API, if you like) should be the identical
> on all platforms (with minor adjustments to their differing cultures).
> So what I´m thinking of are FBP "ports" like there are Spring or Esper
> or JUnit ports to other platforms/languages.

As I said above, I do feel it is important to be able to "mix and
match" languages. I once wrote an app which combined mainframe
Assembler (for the FBP infrastructure), REXX (to do some fairly
complex math), and PGF, which is/was an IBM graphical package for
doing bar-graphs in pretty colours. Each of these was *IMO* the best
tool to do the particular part of the task that needed doing! It
wouldn't have been as much *fun* if I had been forced to do all of
this in one language - or as maintainable.

>
> > Hey, sounds great!  Let's do it!  And I honestly don't care what
> > language we do the demonstration in - as long as the onlookers realize
> > that it actually is language-agnostic :-)  So let's move on to the
> > next stage!
>
> So why don´t you set up a different thread to compile a list of
> essentials for such an undertaking.

Here, I think I will wait for someone else to step up to this... I am
too close to FBP to do a good job - besides I want to see what other
people consider the essentials.

>
> And by the way: what´s also needed are examples of how to do FBP in

> "business scenarios". Have a look at the exercises mentioned here:http://geekswithblogs.net/theArchitectsNapkin/archive/2011/06/25/appk...

>
> A more complete list of links to the iterations of those Application
> Katas you find here:http://clean-code-advisors.com/ressourcen/application-katas
> (Don´t despair: Even though the page is in German the exercises are in
> English.)

This looks like a fantastic idea! The CSV viewer is interesting, as
Bob Corrick has already written (or is shortly going to write?) a
sizable chunk of that. But Iteration 2, is interactive, so the output
function has to change to handle input as well as output.
Interestingly, in the old days you often found that Iteration 1 and
Iteration 2 had to use entirely different software, so you would
practically have to start over from scratch for Iteration 2, whereas
in FBP these is really no difference between batch and interactive -
just different network topologies... and some different I/O
components.

> I´d like to see FBP solutions to these problems.

Anyone?!

[Ralf Westphal]

On 19 Jan., 21:18, Paul Morrison <paul.morri...@rogers.com> wrote:
> This looks like a fantastic idea!  The CSV viewer is interesting, as
> Bob Corrick has already written (or is shortly going to write?) a
> sizable chunk of that.  But Iteration 2, is interactive, so the output

Already iteration 1 of the CSV Viewer is interactive. You can page
through the CSV file.
Iteration 2 just adds an interaction (jump to page).

The true challenge is moving from iteration 2 to 3. But please don´t
look ahead. Try to solve it iteration by iteration without knowing what
´s coming next. Otherwise a lot of "fun" is taken out of the exercise.

I don´t expect any performance benefits from using FBP to solve this
problem.
But maybe FBP shines in other ways... ;-)

[Paul Morrison]

On Jan 20, 12:42 pm, Ralf Westphal <ralf...@googlemail.com> wrote:

>
> Already iteration 1 of the CSV Viewer is interactive. You can page
> through the CSV file.
> Iteration 2 just adds an interaction (jump to page).

You're right - I read it too fast! Actually they could have specified
a batch implementation (Iteration 0)!

>
> I don´t expect any performance benefits from using FBP to solve this
> problem.
> But maybe FBP shines in other ways... ;-)

It certainly does! FBP's Lego characteristics will really shine as
you move through the iterations - you can just keep unplugging
components, and plugging in new ones. I have been saying all along
that language designers pay too little attention to maintenance - for
a variety of reasons. FBP's big strength is in how it improves
maintainability - and when you consider that over 80% of what business
programmers do is maintenance, rather than producing new code, this
becomes extremely important. The big FBP system at a Canadian bank
has been running for over 40 years, undergoing continuous maintenance,
often by people who were weak on the concept! We are now talking
about literally a second generation of programmers!

For those who feel like addressing the AppKatas using JavaFBP or
C#FBP, I should point out that they already have a number of
generalized components which will prove useful - long term, we really
need to think about designing some kind of FBP tool-chest (for each
component: name, function description, ports, input and output data
stream descriptions).

[Ralf Westphal]

On 20 Jan., 19:37, Paul Morrison <paul.morri...@rogers.com> wrote:
> You're right - I read it too fast!  Actually they could have specified
> a batch implementation (Iteration 0)!

Well, you can do your personal "iteration 0" while working on
iteration 1.
I call that "feature slicing". see my articles on "spinning" in my
english blog for more on cutting requirements apart:
http://geekswithblogs.net/theArchitectsNapkin/archive/2011/12/23/get-into-the-flow-with-spinning.aspx

> It certainly does!  FBP's Lego characteristics will really shine as
> you move through the iterations - you can just keep unplugging
> components, and plugging in new ones.

that´s what I expect, too :-)
interestingly this has not to do with parallel processing...

>I have been saying all along
> that language designers pay too little attention to maintenance - for

true. but i´d replace "maintenance" with "evolvability", because
"maintenance" is a term from the realm of matter and machines.
doing maintenance work keeps a machine in order; it only sees to that
existing functionality can be used.
what we do with software over the years, though, is very different.
software does not break. (except in operations maybe.)
either software is buggy or it´s not. either it has certain
functionality or it hasn´t. the functionality present does not erode
just by using the software.
so what we call maintenance is more like continuous pimping :-)

since language is shaping our thinking (and the other way around) i
recommend to not use "maintenance" when talking about software.
this term carries all sorts of wrong connotations and images. each
time we´re using this term we´re anchoring software deeper in the
world of hard to form matter. but it´s so hugely different... thus we
better use terms expressing and emphasizing these differences.

[Bob]

Ralf,

Your Spinning post reminded me of this :-)

http://www.youtube.com/watch?v=qniwI2hNhDs

Have a look from about 1:30

And It agree that evolving is a far better analogy than maintenance, as it implies incremental development as well as iterative development.

[Ralf Westphal]

Thx a lot for the link. What an idea... Very cool!

And it reminds me of sth I did a couple of years ago to explain
component orientation:
http://weblogs.asp.net/ralfw/archive/2008/03/02/component-orientation-explained-modern-software-development-viewed-from-a-musical-perspective.aspx

Enjoy!

On 22 Jan., 10:48, Bob <bobcorr...@hotmail.com> wrote:
> Ralf,
>

> Your Spinning post reminded me of this :-)http://www.youtube.com/watch?v=qniwI2hNhDs

[Paul Morrison]

On Jan 22, 2:16 pm, Ralf Westphal <ralf...@googlemail.com> wrote:
> Thx a lot for the link. What an idea... Very cool!
>
> And it reminds me of sth I did a couple of years ago to explain

> component orientation:http://weblogs.asp.net/ralfw/archive/2008/03/02/component-orientation...
>
> Enjoy!
>
Google translates "sudelbuch" as "waste book" - doesn't seem very
appropriate.

I like your point about evolvability vs. maintainability, but I have
to say that in business application development, using English, we
have been using the term "maintenance" for years - maintenance can be
due to changing requirements, changing hardware and software
environments, changing legal requirements (e.g. Sarbanes-Oxley), and
so on and on... I am not sure management would be as comfortable with
our telling them that their application had to be "evolved" to change
from e.g. 32-bit to 64-bit :-)

Your stuff about componentry is very good, but I would like to add to
it that designing reusable components is a bit of a black art! There
is a whole chapter (Chap. 4) about this in my book (relatively
unchanged in the 2nd edition): http://www.jpaulmorrison.com/fbp/reuse.shtml
. As Wayne Stevens recommended, you shouldn't attempt to design a
generalized component until you find yourself doing the same job 3
times! When you have a collection of fairly stable components,
development becomes a mix of top-down and bottom-up - also right-to-
left, and center-out (both described in my book)!

By the way, the JavaFBP jar file contains a version of Jingle Bells in
4-part harmony! Here's the description in the 2nd edition:

My first prototype music component was called PlayTune – it accepted a
stream of packets, each one containing an 2-element integer array,
where the first element in the array is a frequency, and the second is
a duration in milliseconds. PlayTune played these “note” packets, one
at a time, with a 25-millisecond gap at the end of each one, by
sampling a sine wave of the specified frequency, and the samples were
played using classes from the javax.sound.sampled package. Oddly
enough, the PlayTune component was much simpler to write in C#FBP, as
C# has a System.beep() method, whose parameters are frequency and
duration.

To take advantage of the configurability of FBP, PlayTune was then
split into two asynchronous components: GenSamples, and SoundMixer,
and the original component deprecated. The former takes note/duration
pairs and generates a stream of 1-second samples, while the latter
takes these samples and feeds them to the Java SourceDataLine.
Splitting the original PlayTune component in this way means that we
now have a component that can accept 1-second samples created by a
variety of different components.

The new SoundMixer component initially accepted a single stream of
samples, but I realized that it could be converted to use an array
input port, where the 1-second samples from each input port element
were simply added together. This component therefore became a true
mixer, where each element of the input port represents a separate
“voice”. With the addition of gain controls, SoundMixer can now be
used to do real musical work.

[John Cowan]

Paul Morrison scripsit:

> Google translates "sudelbuch" as "waste book" - doesn't seem very
> appropriate.

The English equivalent is "commonplace book", a blank book where
you write down your random thoughts, things you read, or things that
other people say that you want to keep track of. Sometimes they are
organized by subject headings, sometimes not. The best ones are then
often transferred to some more formal medium.

The term and idea dates to the 16th century, but apparently they are more
of a living tradition in the German-speaking lands than in Anglophonia.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
Be yourself. Especially do not feign a working knowledge of RDF where
no such knowledge exists. Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass. --DeXiderata, Sean McGrath

[Paul Morrison]

Just saw a response on the Scratch forum to my comment about using
Scratch to teach FBP:

"Lightnin (Scratch Team member) was kind enough to call this post to
my attention. You might be interested in BYOB (Build Your Own
Blocks), an extension to Scratch that allows users to create new
blocks (procedures) that take inputs and optionally report outputs.
It also has anonymous procedures (lambda) so you can even do
continuation passing style programming. It's at http://byob.berkeley.edu.
"

Sounds interesting!

[Sam Watkins]

On Sun, Jan 22, 2012 at 04:56:04PM -0500, John Cowan wrote:
> Paul Morrison scripsit:
>
> > Google translates "sudelbuch" as "waste book" - doesn't seem very
> > appropriate.
>
> The English equivalent is "commonplace book"

This sounds similar to note book, scrap book, visual diary...
I think many authors carry a note book for this purpose,
so they can write down good ideas before forgetting them!

It's a good idea to carry such a note book, if I had a note book I would
jot it down but there is some problem with recursion here!

Well really I have more of a problem with too many different note books
and ideas scattered around in real and cyber space, not well organized.
I started using 'vim outliner' the other day, an outliner is a very
useful tool.

Here's an article about outlining, by the guy who recommended it to me.

http://www.troubleshooters.com/tpromag/199911/199911.htm

Sam

[Dan]

Scratch is very nice and useful to teach programming for kids and not only but it is not FBP. Scratch is a graphical imperative language. It has all the issues that imperative and functional programming have. Because Scratch is so graphical is so deceiving but for sure is not FBP by no means.

[Paul Morrison]

On Jan 23, 6:06 am, Dan <dpolo...@gmail.com> wrote:
> Scratch is very nice and useful to teach programming for kids and not only

> but it is not FBP. Scratch is a graphical *imperative *language. It has all

> the issues that imperative and functional programming have. Because Scratch
> is so graphical is so deceiving but for sure is not FBP by no means.

Obviously Scratch is imperative, but it is a nice teaching tool, and
is turning kids (and adults) on to programming who were never
interested before! The human factors are quite impressive!

Now, assuming that multiple structures on the Scratch design area will
all run asynchronously, my suggestion to the Scratch people was that
we add a send and receive function, and ideally an icon for
connections (although we could probably manage without that), and you
might have a very productive method of getting people hooked on FBP
early in life :-) Someone responded with the BYOB idea from
Berkeley, so it seems well worth investigating this. It seems to be
generally true in programming that the first language you are exposed
to tends to influence you for life, so it would be great if we could
expose kids to non-von Neumann thinking early - before von Neumann
thinking rots their brains :-)