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

I think of an application as the point at which a group of related 
functionality resides and is presented to the user or an external client 
application through some interface, GUI or programmatic.

I didn't mean you can't compartmentalize all of your application components 
into classes, modules and objects, just that it's not effective to connect 
everything together through an OO structure.  When objects interdepend too 
much by trying to call each other for every possible task, I feel it breaks 
the readability and maintainability of an application.  It's usually more 
effective, for me anyway, to keep the program objects more primitive, and to 
use entry points (program load, event handlers, etc.) to do the actual work 
of the application.  I find it easier to find and fix code that way, and that 
I write more reusable objects.

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

Not modules and classes per se, you're right; but procedural programming uses 
a concept of units which contain the scope of its variables.  I meant modules 
and classes as variable scope boundaries.

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

Functional programming doesn't allow stateful variables, which procedural 
would at various levels of scope.

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

What are sensors and effectors in this context?

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

I think people interested in functional language development are also 
interested in tail recursion optimization and currying.  Understanding what a 
function does allows a language to morph the function itself, and the minimal 
nature of functional programming makes it a good target for such features.  
But I personally think when you're talking about this sort of thing, you're 
talking about implementation candy, not really properties of the language 
itself.  You can have a functional language that doesn't optimize that way.  
It's still a functional language.

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

Aren't there already interfaces for CORBA and so on?  I do this sort of 
programming sometimes using stdio, believe it or not, and often remotely over 
SSH.  It would be a shame to design it in Ruby such that you couldn't take 
advantage of non-Ruby components.  Something universal like CORBA, or 
XML-RPC, is good enough for me.

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

I think the freedom isn't the only culprit; it's the sheer length of time C++ 
has been around, and how many programmers it attracted early on when 
programming itself as a discipline was still a very mystic activity.  
Nowadays, there are loads of design patterns to use as examples, so when a 
bunch of new programmers jumps on a new language, like Ruby, it's a lot 
easier to get them all cohesively communicating and using "approved" design 
patterns.

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

I actually think Ruby gives you the ability to use MORE paradigms than C++ 
can, at least effectively.  I felt far more boxed in with C++ than with Ruby.

	Sean O'Dell