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


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

Re: Refactoring discovery

From Arved Sandstrom <asandstrom3minus1@eastlink.ca>
Newsgroups comp.lang.java.programmer
Subject Re: Refactoring discovery
References (1 earlier) <imi4cd$6q6$3@lust.ihug.co.nz> <Vv7jp.1732$in3.386@newsfe17.iad> <imjjk9$21r$1@lust.ihug.co.nz> <RCkjp.2728$%f5.828@newsfe08.iad> <in14mq$t8i$3@lust.ihug.co.nz>
Message-ID <Tr8lp.619$sy5.383@newsfe22.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2011-03-31 20:51 -0300

Show all headers | View raw


On 11-03-31 02:50 AM, Lawrence D'Oliveiro wrote:
> 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?

AFAIK the graphics are just graphics; I can't speak for every graphical
language out there. LabVIEW has used a compiler since version 2.0
(version 1.0 was an interpreter on Motorola 68000). Prograph started out
in its earliest incarnations written in Prolog but moved to C early on -
I wrote new Prograph primitives for the hell of it, for matrix
operations, in C back around 20 years ago.

Generally speaking the primitives in such a graphical language are going
to be compiled bits in a library, and the program is a description of
how they stitch together, as well as storage of the layout information.

Also typically there is no underlying source - what you see *is* the source.

When I said "plenty of others" I meant _non-graphical_ dataflow
languages, incidentally. Like Oz.

>> Also, I'm not sure what you mean by "scale" in this context.
> 
> As in “deal with very complex programs”.

You're not going to have worse problems with a dataflow language than
any other. It depends on the problem. Odds are you'll do better at
managing complexity with dataflow then you will with a general purpose
OOP language, for the multitude of problems that lend themselves to
dataflow.

[ SNIP ]

AHS

-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

Back to comp.lang.java.programmer | Previous | NextPrevious 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