Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #2674
| 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 |
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 | Next — Previous in thread | Find similar
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