Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe22.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Refactoring discovery References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 56 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Thu, 31 Mar 2011 23:51:15 UTC Organization: Public Usenet Newsgroup Access Date: Thu, 31 Mar 2011 20:51:14 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2674 On 11-03-31 02:50 AM, Lawrence D'Oliveiro wrote: > In message , Arved Sandstrom wrote: > >> On 11-03-25 11:39 PM, Lawrence D'Oliveiro wrote: >> >>> In message , 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