Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #2633

Re: Refactoring discovery

Followups directed to: comp.lang.java.programmer

Show all headers | View raw

In message <RCkjp.2728$%f5.828@newsfe08.iad>, Arved Sandstrom wrote:

> On 11-03-25 11:39 PM, Lawrence D'Oliveiro wrote:
>
>> In message <Vv7jp.1732$in3.386@newsfe17.iad>, Arved Sandstrom wrote:
>> 
>>> If you want to do dataflow then the best way to do it is using a
>>> dataflow language. I've used a few of them, including LabVIEW and
>>> Prograph CPX (which latter was pretty awesome actually).
>> 
>> You mean graphical languages? I’m not sure how well they scale. Also
>> there’s the problem that standard source manipulations like diff/patch
>> and merge are lacking.
> 
> Plenty of others have textual source. Oz for example.

So what does the language processor operate on: the graphical presentation, 
or the underlying source?

> Also, I'm not sure what you mean by "scale" in this context.

As in “deal with very complex programs”.

>>> And one can argue that stitching together UNIX tools with tees and pipes
>>> and redirects is a form of dataflow.
>> 
>> That can express fan-out, but I don’t think it can express subsequent
>> fan-in from that fan-out.
> 
> In many cases you could do it in a shell but you'd have to get quite
> creative. I'm not claiming in any case that UNIX system and shell offers
> a full, high-powered dataflow environment.

There is always the option of bringing in named pipes (mkfifo or mknod p) to 
tie disparate ends together.

>> The standard solution to this is to introduce names for the connections
>> somewhere. Which basically brings us right back to functional
>> programming.
> 
> The "names" are single-assignment (logic) dataflow variables, that are
> either unbound or bound. Computations express their dependency on
> inputs; specifying the connections is a matter of indicating that
> certain inputs are outputs of another computation.
> 
> It's not so much that _this_ is functional programming, but more that
> many functional programming languages allow you to program in such a way
> that it resembles dataflow.

Seems like every attempt at dataflow has to resort to using names as an 
alternative to topology at some point.

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar

Thread

Re: Refactoring discovery Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-03-31 18:50 +1300
  Re: Refactoring discovery Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-03-31 20:51 -0300

csiph-web