Clemens Hintze <c.hintze / gmx.net> wrote: > >On 8 Jan, Ben Tilly wrote: > > Clemens Hintze <c.hintze / gmx.net> 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