@Ronald: Yes, LabVIEW comes to mind when talking about flows and "components". And BPMN. And FBP. And UML Activity Diagrams. But still I think it´s benefical to not jump on their bandwaggons.
What we need is a method to design software, just any software. And we need to come there. LabVIEW has its roots elsewhere, BPMN too. UML is not code driven. And FBP is throwing in concurrency right away. All that to me seems a hindrance if Joe Developer is to accept a level of abstraction for designing software above his beloved 3GL like C# or Java. FD is pragmatic to the bones. Only what stands the test of daily usage to produce code, and can be easily taught in short trainings is in there. It´s not designing with your head in the clouds, no ivory tower. It´s down to earth whiteboard ready. That´s also the reason why I emphasized, that Flow-Designs are synchronous by default. Because switching from OO thinking to flow thinking is a big step enough for Joe Developer. To also require switching from sync to async would make it unnecessarily more difficult. Also asynchronicity can easily be introduced at any time. Have a look at this article in my blog: http://bit.ly/9s3bBV - and this is only one way to do it. Another one would be "pimp" the wires and make them asynchronous. (By the way, using "pimped" wires would also make it terribly easy to switch on/off tracing of messages flowing through a system. I also ran tests of slowing down a software system to be able to watch what´s happening in slow motion. :-) You mused about "how to glue [components] together"? Have a look at my latest post; or wait until I finsish it ;-) "Glueing" is easily done with events. No dependencies anymore. DSLs on the other hand I deem to complicated. If average developers today don´t manage to write maintainable code on a day to day basis, if average programmers still don´t know about C# yield... then how can we expect them to come up with their own languages for their problem domains? A simple and universal DSL like the Flow-Design notation, though, could help. A single language to learn to make it easier to design just any application. And it scales! By doing functional decomposition using true nesting large systems can be broken down into manageable chunks. Add to that component orientation and you arrive at designs that can be efficiently implemented by a team where all programmers are working on the same feature simultaneously to keep WIP small. Enough said for today ;-) FD is not altogether new, it borrows heavily from several sources. But in the end the result to me seems different enough. It´s simple, pragmatic, working every single day for me and others. Recently I met a guy who´s using it in a 12 person team; he never ever asked a question in a forum. It´s just working for him. On another day we can talk about DDD fits into the FD picture. For now I can tell you: it fits nicely ;-) And FD even makes clear why Jimmy Nielsons depiction of DDD is - sorry to say - wrong. (Or at least not workable in larger scenarios.) -Ralf -- 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.
