ser / germane-software.com (Sean Russell) writes:

> Mikael Brockman <phubuh / phubuh.org> wrote in message
> news:<87d634enff.fsf / phubuh.org>...
>> So I'd say Ruby is a mostly-object-but-also-functional language.  But
>> if one wants to write Scheme code in Ruby, one is unstoppable.  One
>> can even make it look mostly like regular Ruby code, as long as one
>> *thinks* functionally.
>
> I still don't see how you come to this conclusion.  Ruby makes heavy
> use of side effects, and I'd still suggest that it would be difficult
> to program functionally in Ruby, using either NIST's or
> comp.lang.functional's definition of a functional programming
> language.

I agree that it's difficult to program functionally in Ruby according to
those definitions.  I also think it's difficult to do so with Scheme.
The only people I know that actually program purely functionally are my
Haskell friends, and even they resort to unsafePerformIO occasionally.

Scheme has some features to make it easier, like tail call optimization,
but I don't think using tail recursion instead of looping matters much
in the large scale of things.  In fact, I don't think it matters much at
all.  When I write tail-recursive loops in functional languages, the
paradigm in my head tends to be imperative.

> Out of curiosity, have you programmed functionally in Ruby, or are we
> discussing abstracts here?  I've written a lot of what could be
> classified as functional programs in Ruby, but they've exclusively
> been one-liners from the command line, where I'd normally have used
> sed or awk.  Any Ruby program I've ever written that grew to more than
> a couple of lines (and even many of the one-liners) introduced
> side-effects -- accumulators, etc -- which violate the functional
> programming paradigm.  I'm just curious if you've done much of this.

Nope, I haven't.  I try to follow the grain of the language as much as
possible, so with Ruby, I tend to write imperative object-oriented
programs.  Of course, many habits from my functional experience follow
me: defining new control structures, using heavy abstraction, etc.

>> > They're operations on a primitive: a list.  A list isn't an object in
>> > the OO sense.  You can call it an object, but it has no behavior, and
>> > it knows nothing about car and cdr.
>> 
>> It does have behavior.  When I car it, it gives me its first element;
>
> The list doesn't give you its first element.  car discovers the first
> element of the list.  Saying that a list gives you the first element
> when you car it is like saying that a painting gives me meaning when I
> look at it.  The painting is ignorant about whether or not it is being
> observed.  And if you take this discussion in a metaphysical
> direction, then I'm not playing any more. :-)

That's only true if you think of the data and its operations as
completely separate entities.  Doing so isn't easily justifiable in
Ruby, since they're defined in their own little indented scope.

If I were to design in Scheme, say, a library for mutable queues, I
would think of the data and its operations as an object, just like I do
when I'm programming in an object-oriented language.  Real functional
hackers probably think differently.

  mikael