Other Software > Developer's Corner

Flow oriented programming

(1/1)

housetier:
Most Debian-people are smart people, some come close to being brilliant, others the world were a nicer place without... This sets the skeptical mindset I have when I read Planet Debian in my RSS reader of the week.

The other day a certain headline caught my attention. "Flow oriented programming": I've been preparing on my exam on programming and modeling languages. The usual classification of imperative, functional, oop and logic programming is kind of inconsequent, since there are e.g. functional oop languages.

To me, oop is more of a software engineering thing, usually applied to imperative programming with a load of syntactic sugar.
-http://blog.drinsama.de/erich/en/2006071801-flow-programming
--- End quote ---

This made me curios and I read on. The article doesn't go very deep into this topic but it hints at a few new (for me at least) ideas/paradigms. I'll try to get my hands on Mr. Schuberts exam on this topic, I find this interesting.

What are your thoughts, could FOP be the new holy grail? Or is it just another hype after OOP+UML an XP?

(Should this go into the programmer's corner instead?)

mouser:
interesting comments -
i don't think it's the holy grail, but i think his points are good about the usefullness of dataflow-centric thinking for some problems.  in some ways i think this is what UML is after, but i tend to agree with him that i don't find it particularly compelling for me personally.

there are of course toolkits very much based on dataflow structures - namely things like QT which work with slots and fillers and message passing.

i also think he has a good point that OOP could be used as part of functional, imperative, logic, etc. so it's probably not the best way to classify a language.

ps. yep this is best moved to developer section - moving it.

rkarman:
i don't want to be annoying or anything but in my oppinion there is no holy grail of programming. if you make software it is always more complex then you hoped/thought it would be. if you draw a picture with an arrow and some blocks you always loose detail (did the arrow mean an invocation? was it dynamic? or was it static?) if you try to catch it all (like uml) then the drawing goes as complex as the code is and the idea of making it understandable with an piture is lost somehwere in the hundreds of printouts of beautiful uml images.

sure it's not all bad, oop offers some extra ways to structure your code for instance. but don't be fooled, it wil never bring you the gold that was prommised to be at the end of the rainbow.

i think that it doesn't matter as much which design/way you choose to organize your code as it matters that you stick with the choice you made and keep everything consistent.

having said that i think that there are a few things that are great, one of them is your own mind (of course, lol) and the other would be refactoring tools. they can really help you keep your code from going in decay, and add structure to it later on.


so the moral is: there is no holy grail, just some handy tools maybe ;) i hope you can proof me wrong though!

Navigation

[0] Message Index