On Fri, 9 Jul 2004 07:38:52 +0900, Sean O'Dell <sean / celsoft.com> wrote:
> 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,

out of curiousity, why?
or perhaps, how do you define "application"?  (not to be pedantic, i'm
seriously questioning the concept of a monolithic application versus
combinations of utilities in the small single-purpose combined by IPC
unix sense.)

> 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).

procedural programming defines top-down execution of _arbitrary_
instructions, and has little to do with modules/classes (which are OO
concepts).

>  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.

by how you are thinking of this, i could as well argue that functional
style is procedural because it follows the inputs and outputs of
functions.

the actual difference, however, is that both functional style and data
flow provide _context_ for when they operate and why.  functional
style and data flow contain both sensors and effectors (as defined by
Cybernetics / Norbert Wiener); procedural style only provides
effectors and expects the omnicient programmer to design code like
deterministic clockwork.  (Richard Dawkins probably deserves a mention
here as well.)

i suspect this is the heart of the issue behind the interest in
referential transparency and no side-effects.  basically, the computer
should always know _why_ it's doing something and whether it worked
without depending on the programmer to know for it, unnecessarily.

> 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 agree.  this is why i advocate codifying flow-based programming as a
_style_ or "pattern language" of programming in ruby.

> 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.

this is a fine line.  i loathe C++ precisely because stroustrup favors
multi-paradim "freedom", whereas i find that multi-paradigm amounts to
NO paradigm, and integrating different people's code takes more
_programmer_ (human creativity) resources than writing from scratch. 
this is bad.

for now i feel ruby walks this line very well.  particularly with ruby
dividing defined chunks of procedural code into "blocks" and
discouraging count-looping with closures and functions like .each for
number objects.

thorough and intuitive thought such as this gives me sincere
appreciation for matz's design skills.

> 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.

you sound like stroustrup.
imho, creating a unique tool for every job prevents the crafter from
learning to use any set of tools very well.

>         Sean O'Dell
> 
> 

-z