On Fri, 9 Jul 2004 10:16:17 +0900, Sean O'Dell <sean / celsoft.com> wrote:
> 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?

the sensors in functional programming would be the lack of stateful
variables, that how values are generated may be traced back up the
function chain.  the same applies for "data flow" in flow-based
programming.  unlike procedural code where memory values are
"mysteriously" overwritten with new values without any linking
rationale other than "the programmer told me to".  effectors are the
"doing", the evaluation.

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

i find tail recursion and optimization as over-hyped, because
essentially they're a design detail of the interpreter, not the
language itself, as was already said by not me.

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

not for me.  corba, and to a much lesser extent xml-rpc, seem complex
for complexity sake, to satisfy "enterprise level job security" or
something.  find me a person who can implement corba themselves and
i'll concede this argument.  even gnome only implements a subset of
corba for their orbs.

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

if you concede "approved design patterns", then i'm not sure why we're arguing.
i happen to feel that actor / flow-based style would be a positive
evolution in the "approved design patterns" of ruby.

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

which then essentially is my argument.  by moving forward with "one
pretty good way", more people will be able to achive more real
productivity with less work.  aka "less is more".

>         Sean O'Dell
> 
> 

-z