On Fri, 9 Jul 2004 14:07:53 +0900, David Morton <mortonda / dgrmm.net> wrote:
> Sean O'Dell wrote:
> 
> > 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
> >
> 
> Well said.  Anyone that says OO|Functional|Flow-Based|Procedural  is the
> "One True Way(tm)" probably needs to get out more and try to actually
> use the paradigm in other fields.  Academic discussions can be fun
> sometimes, but the practical side of me knows that the real world isn't
> so black and white. :)
> 
> I happen to like the way Ruby *can* handle being a simple procedural
> language, but has *much* more power using other paradigms - use them
> when appropriate.  I personally use a hammer to pound nails, but I use a
> screwdriver on screws.  Use the right tool.
> 
> -
> David Morton


but some ways are better than others, and no code is an island unto itself.
the problem with stroustrup and C++ is that it tries to be everything
to everybody, and in the process does nothing to guide programmers
away from bad design.  (like television programming which attempts to
appeal to every demographic, and so appeals to nobody because it's so
banal.)  or in the real world, everybody tends to write C++ code their
own way, either at the personal level, or certainly at the
organization (corporate) level.  the cost of path-dependency compounds
very quickly.

hammers for nails and screwdriver for screws, sure...  but 95% of the
time a screw is better than a nail, and 99% of the time a philips-head
(+) is better than a flat-head (-).  i don't need a "One True Way" for
100% of programming tasks, but so far no real "One Good Way" exists
for 90% of the programming people want -- and that's the processing of
lifestyle information, the data people struggle to keep track of in
their lives everyday.  questions like "what's going on my computer?",
"how can i grab video from my webcam, compress it with mpeg-4, and
stream it to my friends, who i keep track of with a contact list, that
can also track their online status?", "how do i keep track of all of
my random brainstorms in a way that i can find them usefully later?"
(wiki has started to cover that one, long with everything2/tangle, and
some applied beyes).  as i said, end-user programming -- what richard
m. stallman talked about when secretaries use emacs, or what alan kay
worked so hard on with squeak/smalltalk.  the issue isn't to hide the
complexity of computers from people, but to refine it to be elegant so
that curious users can figure it out.  (see Ted Nelson's 'Computer Lib
/ Dream Machines'.)

if you need to organize diverse software developers (themselves ad-hoc
and perpetually dropping in and out) around an evolving codebase,
where new developers can easily look at existing code and figure out
how to extend rapidly, it really helps to codify a style that
optimizes elegance, flexibility, readability, and intuition.  (richard
stallman also discussed this problem with apprenticing new
programmers.)

in the real world, the amount of code written needs to decrease and
the number of people who can author code must increase.  improvements
in language syntax and encouraged style, as ruby has taken amazingly
progressive steps forward with, make this happen.  largely this is
ascribed to "the principle of least surprise", though i think it can
be enumerated by the blend of smalltalk, lisp, and perl design
principles.  (some people also throw eiffel into that mix.)

programming is the expression of an idea into practice, and the gap
between how easy it is to think of an idea and how difficult it is to
articulate it in code needs to close.  some days i feel like ruby cut
that distance in half.  i think the actor / flow-based programming
style can cut that distance in half again.

leave obscure scientific programming in the rare position that
computing resources are more expensive than programmer thinking
resources to the few people really working on that.  don't suffer
everyday programmers to write ten times the volume of code because
they *might* want to do something like that (they won't).  (such
programming isn't sustainable anyway; mostly it's a one-off.)

i think we agree "use the right tool", but in designing a hammer we
don't worry that it'll suck at being a saw.

-z