Stream of consciousness, so no guarantees of any real message or conclusion.

My first thought is LabVIEW from National Instruments... 
http://www.ni.com/labview/whatis/graphical-programming/

>From the examples, I think goals are very different from OO. It seems very 
programmer oriented as modular decomposition of delegated domain 
understanding and the flow charts that I started with in the late 70s and 
80s. OO as traditionally framed (as opposed to commonly practiced) has been 
some notion of domain simulation and abstraction, ala Domain Driven Design, 
such that it helps develop requirements and benefits in itself. I guess I 
see Domain Specific Languages as really an embodiment of the outcome of this 
understanding. 

A more pragmatic view of mainstream OO might be component based development 
and design. I draw the analogy in processor design where I come from, it 
started with manual layout (or spaghetti code), to modular design of 
building blocks like register files, to modular blocks of entire compute 
engines. The tools within a decade went from simple circuit layout and logic 
description to sophisticated CAD systems primarily focused on System on a 
Chip designs. I think this is an interesting analogy (not only because I 
lived the transition in a prior life) but it was driven by Moore's law and 
designers inability to manage the complexity with previous tooling and 
methodology in such an obvious manner.

Once we get to component based design/development, then how do we model the 
interaction between components and how to glue them together? VB was all 
about this back in the day... At some level SOA, MOMs (Message Oriented 
Middleware), queuing theory all seek to address this. Flow based design 
seems to be another permutation of these. Not sure why synchronous by 
default is an important characteristic to draw out...

IBM Research proposed document based process modeling a decade or two ago as 
an extension or alternative approach to business process modeling, building 
systems and interfaces on the basis of the traditional interchange and 
transformation of documents between organizations and their side effects 
(i.e. actually manufacturing or shipping a product). I don't think this went 
anywhere, but I did think it interesting at the time.

Ron

-- 
You received this message because you are subscribed to the Google Groups 
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/altnetseattle?hl=en.

Reply via email to