On Thursday 08 July 2004 14:29, zuzu wrote: > > however, the spectrum and natural opposite of "functional programming > _style_" is not object-orientation but _procedural_ programming. i > find procedural programming a bane on humanity (those with computers > anyway) and an artifact of von neumann architecture. > > functional style and object-orientation are orthogonal to each other. Procedural programming is a style, which a language may or may not support. Ruby, C, Pascal, Java, etc. can all support procedural programming. I don't believe it's effective to develop a purely OO application, only OO components that tie together using other design patterns, such as procedural, event-driven, etc. > i believe a very important step in improving the defacto style or > "pattern language" in which ruby (and all) software is written, would > be to adopt a functional style and eschew procedural programming. > (but pure OO rocks the house!) for me, a more ideal style that > unifies these into object-functional is the actor or flow-based > programming (FBP) style. (sometimes simply "data flow" programming.) > http://www.jpaulmorrison.com/fbp/index.shtml > http://cliki.tunes.org/Actor > http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion Unless I'm mistaken, procedural programming simply means top-down execution of an application which consists of modules/classes which contain methods which have scope and can hide variables from other levels of scope (like static or lexical scope). Even flow-based applications will probably become procedural when components are invoked,and components probably start out procedural until they fall into a "wait state" waiting for the next event to invoke them. Flow-based programming seems like more of an application design pattern than a language pattern. Ruby could offer interfaces to make it easier (to promote it), though. I don't think you can restrict a language to just one of these paradigms without narrowly restricting that for which the language can be used. Ruby allows OO, functional, procedural, imperative and other paradigms because they all have their uses at some point or other. It's up to the developer to say "this application needs X% of this paradigm here, X% of this paradigm there," etc. It's up to the developer to learn what to use and when, and when to not. A person restricting themselves to one set of concepts is a sign that they don't fully understand their alternatives very well. Even globals and goto have their use, but a lot of programmers don't fully understand them so they write horrible spaghetti code with them, or disdain them completely out of fear. It's better to have all possible tools at-hand and to learn how to use them, than to shun the ones you haven't learned to use effectively. Sean O'Dell