[ruby-talk:8815] Re: Modules and mixins

Clemens Hintze <[e-mail]> wrote:
>
>On  8 Jan, Ben Tilly wrote:
> > Clemens Hintze <[e-mail]> wrote:
>
>(...)
>
> >>The three paradigms, Ruby supports and I want to mention, are:
> >                                     ^^^^^^^^^^^^^^^^^^^^^
> > It supports more of course. :-)
>
>Of course. But because the original post was about modules, I have only
>mentioned those paradigms that have anything to do with modules.

Ah, yes. :-)

>But it is nice from you that you have mentioned the functional paradigm
>too. Especially as I am still not familiar with that paradigm yet. I
>begin to learn it right now. Using Hope, Haskell and perhaps Ocaml :-))

I recommend reading "Structure and Interpretation of Computer
Programs" by Sussman and Sussman if you want to learn it
better. :-)

Not that I understand it as well as I want. :-(

>(...)
>
> > Ruby also supports functional techniques.  You call proc()
> > to produce a procedure, and then call it many times.  The
>
>I was not 100% sure that Ruby supports functional paradigm, though. From
>what I have seen, the short time I learned functional programming now, I
>got the impression that functional programming does not only mean to
>have first class functions but also to write down function/formulas and
>let the interpreter to chose the right one to be executed right now.
>Like this:
>
>   dec fib : num -> num;
>   --- fib(n) <= fib(n-1) + fib(n-2);
>   --- fib(1) <= 1;
>   --- fib(2) <= 1;
>
>If I understood this example right, all equations are equal. If I ask
>the interpreter for fib(12), it should decide on its own what formula or
>function equation it has to chose to solve my question.

Not all functional languages will be able to do that.

Just like there are concepts that show up naturally in
object oriented programming that may or may not be
supported in a given object-oriented language, there
are concepts that show up in functional languages which
may or may not show up in any given one.

>But, OTOH, I may be totally false here. Perhaps you could enlight me,
>what functional programming mean, and whether Ruby really supports that
>paradigm well?
>
A good summary and description of what is necessary to use
functional techniques appears in MJD's description of the
book that he is writing:

http://perl.plover.com/book/

The key elements he lists are first class function values
(Ruby goes farther than necessary here with the ability
to turn functions into blocks and blocks into functions),
dynamic construction of anonoymous functions (through
either Proc.new or proc), variables with lexically closed
scope (Ruby does this, though it could do with better ways
to declare that this variable should really be private),
and automatic garbage collection (which Ruby of course
supports).

So the basic functional techniques work in Ruby.

> > following quick hack shows what those techniques look like,
> > though it is a port of a quick example I did in Perl and I
> > don't know if it is how you would want to solve this problem
> > in Ruby:
>
>(... really impressing 'hack' deleted ...)
>
>Ehrm ... whoa! I would first have to look how your example is doing what
>it does ... :-/

OO programming is hard for procedural programmers because it
is a form of indirection.  Functional is a different form of
indirection.  My impression is that OO imposes a structure on
how you think about the problem.  Functional leaves you with
more flexibility about how to approach problems, and likewise
with more

>Impressing ... indeed! I will save it for further usage. And to answer
>your question, I really do not know, how I would solve that problem
>equally elegant as you've done right now! :-)
>
I would wonder if there isn't a more natural solution using
iterators.  I have not played with them in Ruby.  I am used
to creating an anonymous function that returns the values in
order and then iterating over that:

  # Sorry for the name, this is what I usually call them
  def ret_fib_iter ()
    old, fib = 1, 0
    proc { ||
      old, fib = fib, fib + old
      fib
    }
  end

  fn = ret_fib_iter

  for i in 1..50 do
    puts "Fib(#{i}) is #{fn[]}"
  end

I still don't have a good sense how using the native
iterator construct compares to this approach.
>
> > Functional as well. :-)
>
>It would be nice if that is true.
>
It is true. :-)

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com